Una race condition nascosta nel cuore del sandboxing di SnapIl 21 luglio 2026 il Threat Research Unit di Qualys ha reso pubblica CVE-2026-8933, una vulnerabilità di local privilege escalation (LPE) che colpisce snap-confine, il componente che costruisce l’ambiente sandbox per le applicazioni Snap su Ubuntu. Il difetto, classificato come “High” severity, permette a un utente locale non privilegiato di ottenere accesso root completo sulle installazioni di default di Ubuntu Desktop 24.04, 25.10 e 26.04.

La cosa interessante, dal punto di vista di chi amministra sistemi Linux, non è tanto la gravità in sé (le LPE locali sono un classico), quanto come ci si è arrivati: una modifica pensata per aumentare la sicurezza ha introdotto, per effetto collaterale, una finestra di race condition sfruttabile.

Perché snap-confine è cambiatosnap-confine è il binario che Canonical usa per costruire l’ambiente isolato in cui gira ogni applicazione Snap: monta i namespace, applica i profili AppArmor/seccomp e prepara le directory temporanee di lavoro. Storicamente era un binario set-uid-root: partiva già con i privilegi di root e li abbandonava progressivamente.

Per ridurre la superficie d’attacco, Canonical ha migrato snap-confine a un modello basato su set-capabilities: il processo ora gira con l’UID effettivo dell’utente chiamante, ma mantiene comunque delle capability quasi-root (tra cui CAP_SYS_ADMIN e simili) necessarie per completare il setup del sandbox. È un cambiamento in linea con il principio del least privilege, ma ha spostato il problema: durante l’inizializzazione, le directory temporanee sotto /tmp vengono create con proprietario l’utente non privilegiato, e solo in un secondo momento la ownership passa a root. In quella finestra, per quanto stretta, l’attaccante ha ancora pieno controllo sui file.

La catena di exploitIl team Qualys ha ricostruito un attacco che combina due race condition concorrenti:

Bypass del mount namespace via FUSE: l’attaccante monta un filesystem FUSE sopra la directory temporanea di scratch appena creata, prima che snap-confine applichi l’isolamento tramite mount namespace. In questo modo la directory resta accessibile anche dall’esterno del sandbox.

Symlink race su fchown(): l’attaccante sostituisce un file atteso con un symlink verso un target arbitrario. Quando snap-confine tenta di creare un file nel sandbox, la open() segue il symlink e scrive sul target reale. Una seconda race condition permette poi di allargare i permessi a 0666 prima che venga invocata fchown() per trasferire la ownership a root.

Escalation via udev: per aggirare la confinazione AppArmor, l’exploit punta al percorso /run/udev/, che consente accesso in lettura/scrittura. Depositando un file .rules malevolo in /run/udev/rules.d/ e innescando un ciclo di mount/unmount FUSE, l’attaccante costringe il demone systemd-udevd a eseguire comandi arbitrari come root.

Il risultato finale: da semplice accesso locale non privilegiato a controllo completo del sistema, senza bisogno di interazione da parte di altri utenti.

Versioni coinvolte e patch disponibiliSono interessate le release che spediscono di default la variante set-capabilities di snap-confine:

Ubuntu Desktop 26.04

Ubuntu Desktop 25.10

Ubuntu Desktop 24.04 (con pacchetti snapd aggiornati)

Canonical ha rilasciato pacchetti snapd corretti, tra cui 2.76+ubuntu26.04.3 per Ubuntu 26.04, 2.76+ubuntu24.04.1 per Ubuntu 24.04 e 2.76+ubuntu22.04.1 per Ubuntu 22.04. La disclosure è stata coordinata con l’Ubuntu Security Team.

Come verificare se un sistema è vulnerabilePer controllare la versione di snapd installata:

snap version
apt-cache policy snapdSe la versione del pacchetto snapd è precedente a quelle corrette indicate sopra, il sistema va aggiornato immediatamente:

sudo apt update
sudo apt install --only-upgrade snapd
snap versionPer un controllo su larga scala, chi usa strumenti di vulnerability management (Qualys CSAM o equivalenti) può cercare asset con sistema operativo Ubuntu e pacchetto snapd installato, incrociando poi la versione con quella patchata.

Mitigazioni in attesa della patchSe non è possibile applicare l’aggiornamento immediatamente, alcune contromisure temporanee riducono l’esposizione:

Limitare l’accesso a shell locale ai soli utenti fidati, specialmente su workstation condivise o ambienti multi-utente (lab, terminal server, VDI).

Monitorare la creazione di regole udev non autorizzate sotto /run/udev/rules.d/, ad esempio con auditd:

auditctl -w /run/udev/rules.d/ -p wa -k udev_rules_watch

Disabilitare il montaggio FUSE per utenti non privilegiati dove non strettamente necessario, tramite policy su /etc/fuse.conf o restrizioni AppArmor aggiuntive.

Nessuna di queste misure sostituisce la patch ufficiale: sono palliativi utili solo per il tempo strettamente necessario a pianificare l’aggiornamento.

ConclusioneCVE-2026-8933 è un promemoria utile per chi progetta meccanismi di sandboxing e privilege dropping: il passaggio da set-uid a set-capabilities è, sulla carta, una scelta più sicura, ma introduce una superficie temporale (la finestra tra creazione del file e trasferimento della ownership) che va gestita con la stessa attenzione riservata alle race condition classiche nei binari set-uid. Per chi amministra flotte Ubuntu Desktop, la priorità pratica resta semplice: verificare le versioni di snapd installate, applicare la patch e, nel frattempo, restringere l’accesso shell locale dove possibile.

Fonte: Qualys Threat Research Unit – CVE-2026-8933: Local Privilege Escalation in Set-Capabilities snap-confine

Nessun login richiestoIl 17 luglio 2026 il team di sicurezza di WordPress ha rilasciato in silenzio, e con qualche ora di anticipo condiviso solo con i principali fornitori di infrastruttura, la patch per due vulnerabilità che insieme formano una catena di attacco particolarmente pericolosa: una SQL injection e una remote code execution non autenticata. Nessuna delle due richiede che l’attaccante possieda credenziali o interagisca con un utente reale: basta una richiesta HTTP costruita ad arte contro l’endpoint batch della REST API.

Se gestisci anche un solo sito WordPress — e in Italia sono milioni, molti dei quali proprio su blog tecnici o aziendali come questo — questa è una di quelle vulnerabilità da trattare come priorità operativa immediata, non come lettura per il weekend.

Le due CVE, in breveLe vulnerabilità colpiscono punti diversi della catena di elaborazione di una richiesta:

CVE-2026-60137 — SQL injection. Presente da WordPress 6.8 in poi. Un input malformato riesce ad alterare una query verso il database. Severità: Alta.

CVE-2026-63030 — Remote Code Execution non autenticata. Presente da WordPress 6.9 in poi, e collegata direttamente alla SQL injection precedente. Sfrutta l’endpoint batch della REST API quando il sito non utilizza una cache a oggetti persistente (persistent object cache). Severità: Critica.

La combinazione delle due — nella comunità di sicurezza già ribattezzata informalmente “wp2shell” — permette a un attaccante di passare da un parametro malformato a esecuzione di codice arbitrario sul server, senza autenticazione e senza alcuna interazione da parte di amministratori o utenti.

Perché la object cache fa la differenzaIl dettaglio tecnico più interessante per chi amministra WordPress è che la RCE si manifesta specificamente quando manca una cache a oggetti persistente (tipicamente basata su Redis o Memcached). Molte installazioni WordPress “di default” — senza un livello di caching applicativo esterno a PHP — si affidano a una cache in memoria che vive solo per la durata della singola richiesta: è proprio l’assenza di persistenza a lasciare aperta la finestra che l’endpoint batch della REST API sfrutta per concatenare SQL injection ed esecuzione di codice. In altre parole, i siti più “semplici”, senza uno stack di caching avanzato, sono paradossalmente più esposti di quelli con un’infrastruttura più sofisticata.

La risposta di WordPressTrattandosi della classe di severità più alta prevista dal team di sicurezza di WordPress, il rilascio della patch è stato accompagnato da aggiornamento automatico forzato per la maggior parte dei siti, un meccanismo che WordPress riserva solo alle emergenze più critiche. Le versioni corrette sono:

7.0.2 — release principale, corregge entrambe le vulnerabilità

6.9.5 — backport, corregge entrambe le vulnerabilità

6.8.6 — backport, corregge solo la SQL injection (la RCE non è presente su questo ramo)

7.1 Beta 2 — corregge entrambe

Le versioni precedenti alla 6.8 non risultano affette. Anche con l’aggiornamento automatico attivo, è buona norma verificare manualmente la versione installata:

Da riga di comando, con WP-CLI

wp core version

Oppure dalla dashboard: Bacheca → AggiornamentiIl ruolo del WAF: difesa in profondità, non sostituto della patchCloudflare, informata in anticipo dal team WordPress, ha distribuito due regole WAF dedicate alle 17:03 UTC del 17 luglio, attive automaticamente per tutti i clienti — inclusi quelli su piano gratuito — il cui traffico passa attraverso il proxy Cloudflare:

RegolaCVEAzione predefinitaWordPress – SQL InjectionCVE-2026-60137BlockWordPress – Remote Code ExecutionCVE-2026-63030BlockLa prima regola intercetta i valori dei parametri malformati prima che raggiungano WordPress; la seconda blocca le richieste dirette verso il percorso di esecuzione del codice. Insieme coprono due punti distinti della catena di attacco. Cloudflare è però esplicita su un punto che vale la pena ribadire: le regole WAF riducono l’esposizione, non sostituiscono la patch. Chi utilizza Cloudflare su piano Pro, Business o Enterprise dovrebbe verificare che il Managed Ruleset sia attivo e che non vi siano override che trasformano l’azione da “Block” a “Log” — una configurazione non rara in ambienti dove si è voluto in passato ridurre i falsi positivi.

Checklist operativaPer chi amministra siti WordPress, indipendentemente dal fatto che si usi o meno Cloudflare, questi sono i passi concreti da seguire subito:

Verificare la versione di WordPress su tutte le installazioni gestite (non solo quella principale — anche i sotto-siti, gli ambienti di staging e i multisite dimenticati).

Forzare l’aggiornamento a 7.0.2, 6.9.5 o 6.8.6 se l’auto-update non è ancora scattato:
wp core update --version=7.0.2
wp core update-db

Se dietro Cloudflare: controllare in dashboard che le due regole (ID gestito 7dfb2bd4708d4b88b9911dc0550664b6 per la RCE e 1c060d3a371549219ee290d7ed933fcc per la SQLi) siano impostate su Block, e monitorare i Security Events per richieste bloccate su questi ID.

Se non si usa un WAF: valutare regole custom su ModSecurity con OWASP CRS mirate all’endpoint /wp-json/*/batch, oppure disabilitare temporaneamente il batch endpoint tramite un mu-plugin, in attesa che l’aggiornamento venga completato su tutta la flotta: