Docker MCP Plugin: RCE via label OCI, patch…

ZDI-26-363: la label YAML io.docker.server.metadata nel MCP Gateway Docker permette esecuzione remota come root. Il fix isola i campi descrittivi da quelli di runtime.

La Zero Day Initiative ha pubblicato il 24 giugno 2026 l'advisory ZDI-26-363, che documenta una vulnerabilità di esecuzione remota di codice nel Docker MCP Plugin. La falla consente a un attaccante di ottenere esecuzione come root sull'host inducendo la vittima a referenziare un'immagine Docker malevola. Il meccanismo non sfrutta un bug nel runtime, ma nel codice del gateway che prepara il comando docker run, rendendo inefficace il flag --security-opt no-new-privileges applicato dal sistema.

Punti chiave

L'advisory ZDI-26-363 conferma RCE remota su installazioni Docker MCP Plugin con interazione utente: la vittima deve riferire un'immagine via schema URI docker://.
Il vettore è il label OCI io.docker.server.metadata, il cui contenuto YAML viene unmarshalled direttamente in un struct Go che contiene campi di runtime container.
I campi Volumes, User, Command, ExtraHosts vengono appesi come flag docker run senza allowlist, permettendo montaggi arbitrari ed esecuzione come UID 0.
Il fix, documentato nell'advisory GitHub Security GHSA-r2xf-7jw5-pjg6 pubblicato il 16 giugno 2026, restringe il parser ai soli campi descrittivi.

Come il label OCI diventa esecuzione di comando

La falla specifica risiede nella gestione del label OCI io.docker.server.metadata. Secondo l'advisory GitHub Security, questo label viene deserializzato in formato YAML direttamente nel struct catalog.Server, una struttura Go che trasporta metadati descrittivi e campi che plasmano l'esecuzione del container.

Il codice del gateway MCP appella questi campi per costruire la riga di comando docker run. Nessun passaggio filtra o valida il mapping: i valori passano come flag -v, -u, --add-host. Un attaccante che controlla il label di un'immagine OCI può iniettare -v /:/host per montare la root dell'host, -u root per forzare l'UID 0, o -v /var/run/docker.sock:/var/run/docker.sock per esporre il socket Docker.

L'esecuzione avviene come root sulla macchina host. L'advisory GitHub nota che il trust boundary container/host viene bypassato al momento della creazione del container: l'escalation non richiede exploit post-avvio. Il container non deve acquisire privilegi aggiuntivi; li riceve dal gateway alla creazione.

Perché --security-opt no-new-privileges non protegge

Il Docker MCP Gateway applica il flag --security-opt no-new-privileges ai container che avvia. Questa misura impedisce a un processo di acquisire nuove capability tramite execve. Nella catena di attacco di ZDI-26-363, il flag è inefficace perché il compromesso avviene prima che il container esista.

La sicurezza del modello container assume che il trust boundary si stabilisca al momento della creazione: chi controlla i parametri di docker run controlla il container. Quando quei parametri derivano da un label OCI non verificato, il trust boundary collassa sulla fonte dell'immagine. L'advisory GitHub lo formula in originale: "The container/host trust boundary is bypassed at container-creation time, so the --security-opt no-new-privileges flag the gateway applies provides no protection: no in-container privilege escalation is needed."

La disclosure di Jabr Al-Otaibi e il fix del vendor

Jabr Al-Otaibi, ricercatore con handle @DarkCov, ha segnalato la vulnerabilità il 20 maggio 2026 in collaborazione con TrendAI Zero Day Initiative. L'advisory GitHub Security è uscito il 16 giugno 2026; la release coordinata ZDI il 24 giugno 2026.

Il fix modifica il parser del label OCI per popolare solo campi descrittivi, escludendo quelli che controllano il runtime. È una separazione architetturale della superficie di parsing dalla superficie di controllo. Le fonti non specificano commit hash o versione esatta del pacchetto corretto.

"A maliciously crafted OCI image label can inject arbitrary arguments into the docker run command line constructed by the MCP Gateway." — GitHub Security Advisory GHSA-r2xf-7jw5-pjg6

Cosa fare adesso

Le organizzazioni che impiegano Docker MCP Gateway devono applicare il fix ufficiale non appena il vendor ne rende disponibile la versione pacchettizzata. Ogni istanza che processa label OCI da fonti non esplicitamente trustate resta esposta.

Il CVSS 4.0 vector pubblicato da GitHub — AV:L/AC:L/AT:P/PR:N/UI:A/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H — codifica impatto elevato su confidenzialità, integrità e disponibilità. Il punteggio numerico aggregato non è riportato nelle fonti disponibili.

Le operazioni di verifica devono concentrarsi su due punti: confermare che il gateway in uso processi label da immagini con provenienza controllata, e verificare che la versione installata includa il parser restrittivo. Non è documentato nelle fonti alcun workaround alternativo alla patch.

Limiti documentati nelle fonti primarie

Le fonti primarie disponibili presentano limiti espliciti. Il CVE ID non è ancora assegnato o non risulta dalle fonti consultate. Il CVSS numerico non è calcolato o non è pubblicato: resta disponibile solo il vector string. Le versioni specifiche del Docker MCP Plugin affette non sono esplicitate numericamente. Non risulta dalle fonti se esistano exploit in-the-wild, né è stimato il numero di installazioni potenzialmente vulnerabili.

Il pattern architetturale dietro ZDI-26-363

La vulnerabilità ZDI-26-363 illustra un pattern di confine tra dati e codice: un campo concepito per metadati descrittivi viene riutilizzato per parametri di esecuzione. La mancata separazione tra superficie descrittiva e superficie di controllo è il difetto architetturale che rende possibile l'attacco.

Il caso si distingue da altre compromissioni container per la sua temporalità. L'esecuzione avviene al momento della creazione, non durante il runtime. Questo rende inapplicabili contromisure standard post-avvio.

La risposta del vendor — separare nettamente i campi descrittivi da quelli di runtime nel parser — conferma la diagnosi: il problema è strutturale, non implementativo. Il fix non aggiunge validazione sui campi pericolosi; li rimuove dalla superficie di parsing.

Per le organizzazioni, la lezione operativa è nel controllo della provenienza delle immagini. Il gateway MCP non può più essere considerato un livello di indirezione sicuro: se processa label OCI, la catena di trust termina sul costruttore dell'immagine, non sul gateway.

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

Fonti

Fonti e riferimenti