CVE-2026-105769: kaniko espone il token Azure a registry fasulli, verifica e patch 1.25.20

Vincenzo Katriel Giuva5 novembre 20267 min di lettura

Se usi kaniko per costruire immagini container in una pipeline che ha accesso a un'identità Azure, la vulnerabilità CVE-2026-105769 ti riguarda: una sola riga FROM in un Dockerfile può far arrivare a un attaccante un access token Entra ID valido per Azure Resource Manager. Il problema è corretto in kaniko v1.25.20. Chi non può aggiornare deve togliere le credenziali Azure dall'ambiente di build o disattivare l'helper ACR integrato.

Cosa è successo: la vulnerabilità CVE-2026-105769 in kaniko

kaniko include un credential helper per Azure Container Registry (ACR), derivato dal modulo Go github.com/chrismellard/docker-credential-acr-env. L'helper decide se un host è un registry ACR con un'espressione regolare non ancorata: basta che il nome contenga la stringa .azurecr.io (o .azurecr.cn, .azurecr.de, .azurecr.us) e il controllo passa. Un host come x.azurecr.io.attacker.com viene quindi trattato come un registry Microsoft.

Quando kaniko incontra quel riferimento in un'istruzione FROM, o in un COPY --from che punta a un'immagine, chiede le credenziali all'helper prima ancora di contattare il registry. L'helper ottiene un token Entra ID per Azure Resource Manager e lo invia con una POST a https://HOST/oauth2/exchange, sia nell'header Authorization Bearer sia nel campo access_token. Il registry dell'attaccante riceve così un token vivo. Il build non ha bisogno di istruzioni RUN e non deve fare alcun push. Il modulo upstream non è mantenuto e non ha una release corretta; il database vulnerabilità di Go lo traccia come GO-2026-6225.

Chi è colpito: versioni vulnerabili di kaniko

Sono vulnerabili tutte le versioni di github.com/chainguard-dev/kaniko precedenti alla v1.25.20, nell'executor, nel warmer e nel binario standalone docker-credential-acr-env. Il rischio è concreto quando si verificano insieme due condizioni:

kaniko costruisce Dockerfile o build argument che non controlli al cento per cento (pull request esterne, repository di terzi, template condivisi);
l'helper può ottenere un'identità Azure: credenziali di service principal nelle variabili AZURE_CLIENT_ID, AZURE_CLIENT_SECRET e AZURE_TENANT_ID; un token federato di workload identity (AZURE_FEDERATED_TOKEN o AZURE_FEDERATED_TOKEN_FILE) come quello iniettato da AKS; una managed identity raggiungibile tramite l'Instance Metadata Service di Azure o MSI_ENDPOINT.

Non serve usare ACR né aver configurato l'helper. kaniko interroga l'helper integrato per qualsiasi registry senza credenziali nel Docker config che non sia Google o Amazon ECR, e ogni host contraffatto rientra in questo insieme. Se il config.json imposta credsStore a acr-env, anche il binario standalone viene consultato per ogni registry; è una configurazione rara perché prima della v1.25.20 rompeva i pull dai registry non ACR.

Quanto è grave: punteggio CVSS e sfruttamento attivo

Il punteggio CVSS 3.1 è 9.3, gravità critica, con vettore AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N. Attacco da rete, bassa complessità, nessun privilegio richiesto, interazione dell'utente necessaria (qualcuno deve avviare il build sul Dockerfile malevolo), impatto che esce dal perimetro del componente vulnerabile. Confidenzialità e integrità sono compromesse in modo alto, la disponibilità no.

Al momento la vulnerabilità non risulta nel catalogo CISA KEV delle falle sfruttate attivamente. Il tipo di impatto è l'esfiltrazione di credenziali: l'attaccante ottiene un token Azure Resource Manager usabile, finché non scade, con i ruoli assegnati all'identità. Può anche scambiarlo all'endpoint /oauth2/exchange di qualsiasi registry ACR reale a cui l'identità ha accesso e ricavare credenziali di registry. Se l'identità ha AcrPush o superiore, può pubblicare immagini nei tuoi registry, con tutto quello che ne segue per la supply chain. Un caso simile di confine tra build e identità l'ho descritto a proposito del container escape in Beta9.

Come capire se sei esposto: verifica versione, esposizione e log

Versione di kaniko in uso

Controlla il tag dell'immagine executor o warmer nei file di pipeline (GitLab CI, GitHub Actions, Tekton, Argo Workflows) e nei Dockerfile da cui ricostruisci kaniko. Tutto ciò che è inferiore a 1.25.20 va considerato vulnerabile.
Se importi kaniko come modulo Go, esegui go list -m github.com/chainguard-dev/kaniko nel progetto e leggi la versione nel go.mod.
Verifica se nel sistema esiste il binario docker-credential-acr-env e se config.json contiene credsStore impostato a acr-env.

Identità Azure raggiungibile dal build

In un pod di build, elenca le variabili d'ambiente (env) e cerca AZURE_, MSI_ENDPOINT e MSI_SECRET.
Verifica se dal pod è raggiungibile l'Instance Metadata Service all'indirizzo 169.254.169.254: se risponde, una managed identity è disponibile all'helper.
Controlla se il namespace o il service account usa AKS workload identity.

Indicatori nei log

Nei log di pipeline e nei repository, cerca istruzioni FROM o COPY --from con host che contengono .azurecr.io seguito da un altro dominio.
Nei sign-in log di Entra ID, verifica le emissioni di token per l'identità di build e gli indirizzi IP di utilizzo.
Nell'Azure activity log, cerca push su ACR, modifiche alle assegnazioni di ruolo e operazioni di listing di chiavi o secret non riconducibili alla pipeline.

Come risolvere la vulnerabilità: patch, aggiornamento e rimedio

L'advisory indica come versione corretta kaniko v1.25.20, introdotta con la pull request #495. Da questa versione kaniko usa una copia corretta dell'helper in third_party/docker-credential-acr-env, condivisa da executor, warmer e binario standalone. L'helper accetta un host solo se corrisponde esattamente a host o host:porta e il nome è mcr.microsoft.com oppure termina in modo ben formato con .azurecr.io, .azurecr.cn, .azurecr.de o .azurecr.us. Per tutti gli altri host risponde che le credenziali non sono state trovate, senza richiedere alcun token.

Attenzione: il repository non pubblica binari né immagini. Devi ricostruire executor, warmer e docker-credential-acr-env dal sorgente v1.25.20 o successivo. Se importi kaniko come modulo Go, aggiorna la dipendenza almeno a quella versione. Dalla v1.25.20 kaniko non dipende più dal modulo upstream, quindi gli scanner smettono di segnalare GO-2026-6225. Se usi immagini kaniko di terze parti, verifica sull'advisory e presso chi le distribuisce che siano state ricostruite dalla versione corretta.

Cosa fare subito: mitigazioni e hardening

Isola i build non fidati dall'identità Azure. Rimuovi credenziali Azure, token federati, MSI_ENDPOINT e MSI_SECRET dall'ambiente di build e blocca l'accesso a 169.254.169.254 dai pod di build con network policy o regole di firewall.
Disattiva l'helper ACR se non ti serve. Imposta AZURE_ENVIRONMENT a un valore che non corrisponde a nessun cloud Azure, per esempio none, nel container kaniko. L'helper fallisce prima di richiedere qualsiasi token.
Sostituisci credsStore acr-env con voci credHelpers per host, limitate ai tuoi registry ACR. Da sola questa misura chiude solo il percorso del binario standalone.
Riduci i privilegi dell'identità di build al minimo: niente ruoli oltre il pull dove basta il pull, niente accesso a Key Vault o storage se non indispensabile.
Limita chi può far partire build su Dockerfile esterni: approvazione manuale per le pull request da fork, revisione delle righe FROM.

Se sospetti una compromissione: incident response e analisi forense

Se hai costruito Dockerfile non fidati con un'identità Azure disponibile, considera compromesso ogni token emesso a quell'identità in quel periodo. Un token rubato resta valido fino alla scadenza e la rotazione delle credenziali dell'identità non lo revoca. In ordine:

Non cancellare i pod né i log di pipeline: esporta i log del CI, gli eventi Kubernetes e i manifest con le variabili d'ambiente.
Esamina i sign-in log di Entra ID e l'Azure activity log del periodo, con attenzione a push su ACR, modifiche di ruolo e letture di chiavi o secret.
Ruota ogni secret che l'identità poteva leggere tramite Azure Resource Manager, come le chiavi degli storage account, e verifica le immagini presenti nei registry confrontando i digest attesi.
Se ci sono dati personali coinvolti, valuta l'obbligo di notifica al Garante entro i termini del GDPR.
Se servirà far valere l'accaduto verso terzi o assicurazioni, le evidenze vanno acquisite con copia forense e catena di custodia.

Per un intervento di incident response il mio listino va da 1.500 a 6.000 € a prezzo fisso; un audit di sicurezza della pipeline e dell'infrastruttura va da 2.000 a 8.000 €.

Fonti ufficiali

Serve una mano con la pipeline di build?

Se non sai quale versione di kaniko gira nei tuoi runner, se l'identità Azure è raggiungibile dai build o se hai trovato riferimenti sospetti nei log, posso fare la verifica con te, da remoto o di persona tra Varese, Como e Milano. Chiedi un preventivo gratuito, rispondo entro 24 ore, oppure scrivimi dalla pagina contatti anche via WhatsApp.

#CVE#CVE-2026-105769#kaniko#Azure Container Registry#container#Entra ID

Condividi l'articolo

LinkedIn Twitter