kaniko Before v1.25.20 Can Send Azure Entra ID Tokens to Lookalike Registry Hosts (CVE-2026-105769); Go Database Lists No Upstream Fix

Overview

The GitHub Advisory Database entry GHSA-5q7h-w9jf-cx97, which carries the identifier CVE-2026-105769, says that 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.” The advisory lists the vulnerable range as versions below 1.25.20 and the first patched version as 1.25.20. It also lists a CVSS v3.1 score of 9.3 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N and a critical severity rating.

How the Flaw Works

According to the advisory, a Dockerfile that references an image on a lookalike host, such as FROM x.azurecr.io.attacker.com/img, is enough, and the build needs no RUN instruction and never has to push. The flaw sits in an Azure Container Registry (ACR) credential helper, the Go module github.com/chrismellard/docker-credential-acr-env, which kaniko links into its executor and warmer and also builds as a standalone docker-credential-acr-env binary. The advisory says the helper decides whether a host is an ACR registry with an unanchored regular expression, so any hostname that contains .azurecr.io (or .azurecr.cn, .azurecr.de or .azurecr.us) passes.

The advisory names three kinds of Azure identity the helper can pick up: service principal credentials in environment variables, a federated workload identity token such as the one injected by AKS workload identity, and a managed identity reached through the Azure Instance Metadata Service or MSI_ENDPOINT. It adds that a user does not need to use ACR to be affected, because kaniko consults the built-in helper for any registry that has no credentials in the Docker config and is not a Google or Amazon ECR registry. The advisory says this covers base images in FROM lines and images in COPY --from=<image>.

Per the advisory, the attacker receives a live access token for Azure Resource Manager, usable until it expires with the identity’s role assignments, and can also exchange it at the /oauth2/exchange endpoint of a real ACR registry the identity can access. If the identity has AcrPush or higher, the advisory says, the attacker can push images to the victim’s registries.

The Fix and Workarounds

The v1.25.20 release page was published on 2026-10-27 and lists “Fix GO-2026-6225: carry a patched docker-credential-acr-env inside the kaniko module” by @8none1 in pull request 495. The advisory says 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, and that from v1.25.20 kaniko no longer depends on the upstream module. It also says the repository publishes no binaries or images, so users must rebuild the executor, the warmer and the helper binary from v1.25.20 or later.

For users who cannot upgrade, the advisory recommends removing Azure credentials, federated tokens, MSI_ENDPOINT and MSI_SECRET from the build environment and blocking build pods from the Instance Metadata Service address 169.254.169.254. It also suggests setting AZURE_ENVIRONMENT to a value that names no Azure cloud, such as AZURE_ENVIRONMENT=none, for users who do not rely on kaniko’s built-in ACR authentication. It advises that anyone who built untrusted Dockerfiles with an Azure identity available should treat tokens issued to that identity during those builds as compromised, and notes that a leaked token stays valid until it expires and that rotating the identity’s credentials does not revoke it. The advisory credits Martin Zihlmann of osscontainertools as the reporter.

Timeline of the Underlying Helper Flaw

The helper flaw was public months before the kaniko advisory. The Go vulnerability database entry GO-2026-6225 shows a published date of Aug 18, 2026 and lists all versions of github.com/chrismellard/docker-credential-acr-env as affected, with no known fixed version. It credits Martin Zihlmann.

An issue on the helper’s own repository, opened by the GitHub user mzihlmann on 2026-08-13, describes the unanchored acrRE pattern and says everything up to and including 0.7.0 is affected. The issue’s author also writes that a new fork was started under osscontainertools/docker-credential-acr and that the fix was released under v0.8.0. As of this writing the issue shows no comments.

On 2026-08-20 a user opened a Kyverno issue reporting that govulncheck flagged GO-2026-6225 in Kyverno 1.18.0 (main branch) through the same helper module, and asking for the dependency to be replaced or patched.

In a Go vulnerability database issue, a commenter named stevebeattie wrote on 2026-11-02 that Chainguard’s kaniko fork depended on the module, that “we published GHSA-5q7h-w9jf-cx97” and the CVE through the Chainguard CNA that day, and that both cover github.com/chainguard-dev/kaniko before v1.25.20 only. The comment adds that CVE-2026-105769 does not cover the upstream helper module itself and that the upstream module still had no CVE.

What Is Not Known

• The Go database entry lists no known fixed version of the upstream helper, while the helper issue’s author describes a v0.8.0 release in a separate fork. The Herald did not check which other projects use either one. The Kyverno issue was still open when the Herald checked.
• The reporter wrote in the Go database issue that consumers inherit the module through go-containerregistry code paths. The Herald has not independently checked which projects are affected.
• None of the cited sources reports that the flaw has been exploited.
• None of the cited sources is a news outlet.