// 4 CVE · 2 EXPLOIT · 1 ADVISORY NELLE ULTIME 24H
Un container con codice a basso privilegio può causare VM panic in Docker Desktop tramite ricorsione non controllata nel modulo grpcfuse. Il fix arriva con la

Scopri anche

CVE-2026-8936: Docker Desktop, VM panic via grpcfuse

Il 3 giugno 2026 Zero Day Initiative ha pubblicato l'advisory ZDI-26-327 su una vulnerabilità nel modulo kernel grpcfuse di Docker Desktop, catalogata come CVE-2026-8936. Un container con codice a basso privilegio può causare VM panic per denial-of-service tramite ricorsione non controllata, attivabile creando directory profondamente annidate su una cartella host bind-mounted e innescando un evento di invalidazione dentry. Il problema è stato risolto in Docker Desktop 4.76.0.

Punti chiave
  • La vulnerabilità CVE-2026-8936 risiede nel modulo kernel grpcfuse di Docker Desktop
  • Un attaccante con codice a basso privilegio in un container può causare VM panic per denial-of-service
  • Il meccanismo sfrutta ricorsione non controllata: directory profondamente annidate su bind mount host, seguite da dentry invalidation
  • Il fix è disponibile in Docker Desktop 4.76.0; disclosure coordinata il 3 giugno 2026 dopo report al vendor del 30 aprile 2026
  • Non è confermato se la vulnerabilità sia stata sfruttata in-the-wild prima del fix

Il meccanismo: come un container innesca il crash della VM

Il modulo grpcfuse implementa un filesystem in userspace per la condivisione di file tra host e container in Docker Desktop. Secondo l'advisory ZDI-26-327, "the specific flaw exists within the grpcfuse kernel module. The issue results from the lack of proper validation of user-supplied data, which can result in unbounded recursion".

Il CVE Record specifica il dettaglio operativo del trigger: la ricorsione non controllata si innesca quando un container crea "deeply nested directories on a bind-mounted host folder and triggered a dentry invalidation event". La mancata validazione dei dati utente nel modulo kernel permette che lo stack di chiamate cresca indefinitamente, causando VM panic.

Non si tratta di un container escape nel senso classico del termine: l'attaccante non ottiene esecuzione di codice al di fuori del container né eleva privilegi sul sistema host. L'impatto è esclusivamente sulla disponibilità: la macchina virtuale Docker cade, interrompendo tutti i container in esecuzione e richiedendo riavvio.

Condizioni di attacco e superficie esposta

L'advisory ZDI specifica chiaramente i prerequisiti: "an attacker must first obtain the ability to execute low-privileged code within a container on the target system in order to exploit this vulnerability". Non è richiesto accesso root nel container né compromissione preliminare dell'host.

La vulnerabilità richiede una configurazione specifica: un bind mount verso una cartella host con directory profondamente annidate, seguito da un evento di invalidazione dentry. Il dossier non specifica il numero esatto di directory annidate necessarie per innescare la condizione.

Non è chiaro se altri componenti o versioni precedenti di Docker Desktop siano affetti. Non è verificabile se il modulo grpcfuse sia impiegato in configurazioni Docker Engine standalone, al di fuori di Docker Desktop.

CVSS: due punteggi per due standard

La falla è classificata 6.5 (Medium) in CVSS v3.1 e 8.2 (High) in CVSS v4.0, riflettendo diverse versioni dello standard di scoring. Secondo ZDI-26-327, il vettore CVSS v3.1 è AV:L/AC:L/PR:L/UI:N/S:C/C:N/I:N/A:H, che il calcolatore NVD conferma a 6.5. Il CVE Record riporta per CVSS v4.0 il vettore CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/R:U con punteggio 8.2.

Entrambi i punteggi sono validi per le rispettive versioni dello standard. Non è un conflitto reale. Il dossier non indica quale versione dello standard Docker o i tool di vulnerability management adottino per la propria classificazione interna.

Dato chiave

CVSS v3.1: 6.5 (Medium) — CVSS v4.0: 8.2 (High). La stessa vulnerabilità, due standard di scoring.

Cosa fare adesso

  • Aggiornare Docker Desktop alla versione 4.76.0, che secondo le release notes ufficiali di Docker "addressed CVE-2026-8936, a VM panic caused by unbounded recursion in the grpcfuse kernel module when a container created deeply nested directories on a bind-mounted host folder and triggered a dentry invalidation event"
  • Verificare se gli ambienti in uso eseguono container da fonti non verificate su bind mount verso directory host con directory profondamente annidate
  • Controllare la versione installata di Docker Desktop tramite il menu About o il comando docker version e pianificare l'aggiornamento nei cicli di manutenzione
  • Valutare la rimozione di bind mount non necessari verso filesystem host in ambienti multi-tenant o con container da fonti esterne

Il dossier non documenta ulteriori azioni operative specifiche. Non è nota alcuna mitigazione temporanea oltre all'aggiornamento.

Contesto e limiti noti

La vulnerabilità è stata scoperta da Nitesh Surana di TrendAI Research, che ha segnalato la falla al vendor il 30 aprile 2026. La disclosure coordinata è avvenuta il 3 giugno 2026.

Il brief riporta limiti significativi: non è confermato se la vulnerabilità sia stata sfruttata in-the-wild prima del fix; non è chiaro se altri componenti o versioni precedenti di Docker Desktop siano affetti; non è documentato se esistano mitigazioni temporanee; non è verificabile se il modulo grpcfuse sia usato in Docker Engine standalone.

Questi limiti vanno tenuti presenti nella valutazione del rischio. La vulnerabilità resta un problema specifico con condizioni precise e fix disponibile, non una minaccia sistemica generalizzata.

Chiusura editoriale

CVE-2026-8936 conferma un pattern ricorrente nella sicurezza dei container: i filesystem condivisi tra host e guest restano una superficie d'attacco sensibile anche quando l'isolamento appare robusto. Il modulo grpcfuse, progettato per comodità di sviluppo, ha mostrato qui il limite di una validazione insufficiente su input controllabile dall'utente.

La differenza tra i punteggi CVSS v3.1 e v4.0—6.5 contro 8.2—non è un errore ma un segnale: le nuove metriche enfatizzano l'impatto sulla disponibilità del sistema e la semplicità di attacco. Per i team di sicurezza, questo significa che la priorità di patching può variare significativamente a seconda dello strumento di valutazione adottato.

L'aggiornamento a Docker Desktop 4.76.0 rimane l'unica contromisura documentata. In assenza di mitigazioni alternative, la velocità di deployment del patch diventa il fattore determinante per la riduzione del rischio.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti


Fonti e riferimenti
  1. zerodayinitiative.com
  2. cve.org
  3. docs.docker.com
  4. nvd.nist.gov
  5. docker.com