Docker CVE-2026-34040: dieci anni di bypass AuthZ con una richiesta HTTP padding

Il 25 marzo 2026 Docker ha rilasciato la versione 29.3.1 del motore di containerizzazione, chiudendo una vulnerabilità che ha lasciato scoperti gli utenti di plugin di autorizzazione per oltre dieci anni. CVE-2026-34040, scoperta da Cyera Research Labs, consente di bypassare completamente i controlli di sicurezza con una singola richiesta HTTP il cui corpo supera la soglia di circa un megabyte. Il National Vulnerability Database assegna alla falla un punteggio CVSS 3.1 di 8.8, classificandola come HIGH con vettore AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.

Come funziona il bypass: il demone e il plugin leggono due richieste diverse

Il middleware di autorizzazione di Docker Engine si posiziona tra il client API e il demone, intercettando le richieste prima che queste vengano eseguite. Quando un plugin di autorizzazione è configurato, il middleware dovrebbe inoltrare l'intera richiesta — intestazioni e corpo — per la valutazione della policy. Secondo la ricerca tecnica pubblicata da shattered.io e attribuita a Cyera Research Labs, questo flusso si interrompe quando il corpo della richiesta supera circa 1 MB: il middleware tronca o elimina il payload senza notificare il plugin, che riceve una richiesta vuota o parziale.

Il plugin, vedendo un contenuto inoffensivo o assente, restituisce l'autorizzazione. Il demone Docker, tuttavia, continua a processare la richiesta HTTP originale integra, con tutti i flag e i parametri intatti. Questo disallineamento semantico tra ciò che viene autorizzato e ciò che viene eseguito costituisce il nucleo della vulnerabilità, classificata dal NVD con CWE-288: Authentication Bypass Using an Alternate Path or Channel.

"Il plugin autorizza la richiesta perché non vede nulla da bloccare. Il demone Docker processa la richiesta completa e crea un container privilegiato con accesso root all'host: le tue credenziali AWS, chiavi SSH, configurazioni Kubernetes e tutto il resto sulla macchina. Questo funziona contro ogni plugin AuthZ nell'ecosistema." — Vladimir Tokarev, Cyera Research Labs, via The Hacker News

Una correzione incompleta che ha lasciato vivo il vettore per altri otto mesi

La genesi di CVE-2026-34040 affonda le radici in CVE-2024-41110, una vulnerabilità del luglio 2024 con CVSS 9.9 CRITICAL che permetteva di bypassare l'autorizzazione inviando richieste con corpo a lunghezza zero. Secondo il GitHub Security Advisory GHSA-x744-4wpc-v9h2, la patch applicata nel 2024 ha risolto quella condizione specifica senza affrontare il caso generale delle richieste con corpo eccessivamente grande. La correzione incompleta ha lasciato una variante di confine attiva per ulteriori otto mesi, fino al rilascio della versione 29.3.1.

La ricostruzione di Cyera Research Labs indica che il percorso di codice vulnerabile era presente fin dalla versione 1.10 di Docker Engine, rilasciata nel 2016. Questo determina una finestra di esposizione di circa dieci anni per la variante dimensionale, sovrapposta ai cinque anni di permanenza non rilevata della regressione CVE-2024-41110 nel periodo 2019-2024. Il profilo temporale solleva interrogativi sulla copertura dei test di regressione di sicurezza per le condizioni al contorno del middleware AuthZ, un componente critico per l'isolamento multi-tenant.

Ambito di impatto: chi è effettivamente a rischio

La vulnerabilità non interessa tutte le installazioni Docker. Secondo l'avviso di sicurezza di GitHub, "se non utilizzi plugin AuthZ, non sei interessato". I sistemi vulnerabili sono quelli che hanno configurato plugin di autorizzazione che analizzano il corpo delle richieste API per decidere l'accesso: Open Policy Agent (OPA), Prisma Cloud, Casbin e implementazioni personalizzate rientrano in questa categoria. Containerd e runc, quando utilizzati al di fuori dello strato API di Docker Engine, non sono direttamente coinvolti.

Tuttavia, i nodi Docker Swarm e i cluster Kubernetes che impiegano Docker Engine come runtime container sono potenzialmente esposti se l'autorizzazione API è attiva. Le piattaforme multi-tenant e le pipeline CI/CD con accesso programmatico all'API Docker rappresentano i contesti di rischio più elevato: un utente con permessi limitati di creazione container può, con una sola richiesta opportunamente costruita, elevare i privilegi fino all'accesso al filesystem host.

Cyera Research Labs ha rilanciato una stima secondo cui il 92% delle implementazioni container enterprise utilizza Docker, benché questa cifra non specifici la quota di installazioni che adottano plugin AuthZ con ispezione del corpo. La fonte non è stata verificata indipendentemente nel dossier redazionale.

Cosa fare adesso

Gli amministratori di infrastrutture che utilizzano Docker Engine con plugin di autorizzazione devono verificare la versione in esecuzione e pianificare l'aggiornamento alle release 29.3.1 o successive, oppure a Docker Desktop 4.66.1. La patch modifica il comportamento del middleware da fail-open a fail-closed: le richieste con corpo superiore a 4 MB vengono ora rifiutate con errore esplicito, anziché essere processate con payload silenziosamente troncato.

Per le installazioni che non possono essere aggiornate immediatamente, l'adozione della modalità rootless di Docker Engine riduce la superficie di impatto. Come ha notato Vladimir Tokarev di Cyera in un'intervista a The Hacker News, "in modalità rootless, anche il 'root' di un container privilegiato viene mappato a un UID host non privilegiato. Il raggio di esplosione si riduce da 'compromissione completa dell'host' a 'utente non privilegiato compromesso'".

Gli operatori di piattaforme multi-tenant dovrebbero auditare i log delle chiamate API Docker alla ricerca di richieste di creazione container con corpi di dimensioni insolitamente elevate, benché il dossier non documenti signature di rilevamento specifiche. Le organizzazioni che non utilizzano plugin AuthZ con ispezione del corpo non richiedono azioni correttive specifiche per questa vulnerabilità, ma restano comunque esposte ad altri vettori se non aggiornano regolarmente il runtime.

Non emergono, allo stato attuale, sovrapposizioni infrastrutturali che colleghino CVE-2026-34040 a campagne di sfruttamento documentate in-the-wild, né la falla risulta presente nel catalogo CISA KEV al momento delle fonti esaminate. La natura banale del vettore di attacco — una singola richiesta HTTP con padding aggiuntivo — rende tuttavia la vulnerabilità particolarmente attrattiva per attori con accesso limitato all'API Docker.

Il pattern sistemico che CVE-2026-34040 mette a nudo

La sequenza CVE-2024-41110 / CVE-2026-34040 non è una concatenazione casuale ma rivela un pattern ricorrente nella gestione delle correzioni di sicurezza: la risoluzione punto-punto di un sintomo senza analisi delle condizioni al contorno della stessa classe di difetto. Il middleware AuthZ di Docker, progettato con logica fail-open per garantire la disponibilità del servizio, ha trasformato ogni eccezione nel parsing del corpo della richiesta in un canale di bypass autorizzativo.

La transizione a un comportamento fail-closed nella versione 29.3.1 — il rifiuto esplicito anziché il silenzioso troncamento — rappresenta una correzione architetturale più robusta, sebbene introduca nuovi requisiti di gestione degli errori per i client che legittimamente invocano operazioni con payload di grandi dimensioni. L'analisi del dossier non permette di quantificare l'impatto operativo di questa modifica su workload esistenti.

Fonti

• https://shattered.io/docker-authz-bypass-cve-2026-34040/
• https://thehackernews.com/2026/04/docker-cve-2026-34040-lets-attackers.html
• https://www.cyera.com/blog/cyera-research-discovers-docker-authorization-bypass-that-silently-disables-security-policies
• https://nvd.nist.gov/vuln/detail/CVE-2026-34040
• https://github.com/moby/moby/security/advisories/GHSA-x744-4wpc-v9h2
• https://thehackernews.com/
• https://thehackernews.com/p/upcoming-hacker-news-webinars.html
• https://thehackernews.com/search/label/Threat%20Intelligence
• https://thehackernews.com/search/label/Vulnerability

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

Fonti