kaniko Azure token leak to lookalike ACR hosts (CVE-2026-105769)
Severity: critical · Patch status: partial · Since 2026-10-27 · CVE-2026-105769
kaniko before v1.25.20 can leak a Microsoft Entra ID access token for Azure Resource Manager to an attacker-controlled registry host. The flaw is in the ACR credential helper github.com/chrismellard/docker-credential-acr-env, which uses an unanchored regex so any hostname containing .azurecr.io (or .azurecr.cn/.de/.us) is treated as an ACR registry. A Dockerfile like FROM x.azurecr.io.attacker.com/img suffices—no RUN instruction or push needed. The token is sent in both the Authorization header and the /oauth2/exchange form body, letting the attacker act with the identity's role assignments, exchange it for ACR credentials, and push images if the identity has AcrPush. Anyone running untrusted Dockerfiles or build args with service principal, workload identity, or managed identity credentials available is affected, even without using ACR. Fixed in v1.25.20 via a patched vendored helper that only accepts exact ACR hosts.
What to do
- Upgrade kaniko to v1.25.20 or later (latest tag: v1.25.21, 2026-11-03) and rebuild the executor, warmer and docker-credential-acr-env binary; update the Go module if imported
- The archived GoogleContainerTools/kaniko (gcr.io/kaniko-project/executor, last release v1.24.0, 2025-05-23) has no fixed release; use the Chainguard fork or apply the workarounds below
- If you can't upgrade, remove Azure credentials, federated tokens, MSI_ENDPOINT/MSI_SECRET from build environments and block access to 169.254.169.254
- Set AZURE_ENVIRONMENT=none in the kaniko container if you don't rely on built-in ACR auth
- If you set credsStore acr-env, replace it with per-host credHelpers entries
- If untrusted builds ran with an Azure identity available, treat tokens issued during those builds as compromised; review Entra sign-in and Azure activity logs and rotate readable secrets
Fixed versions
Sources
All live incidents on Threat Watch
