kaniko Patches ACR Credential Helper Flaw That Leaked Azure Entra ID Tokens to Lookalike Registry Hosts

A security advisory published for the kaniko container-build tool (GHSA-5q7h-w9jf-cx97, tracked as CVE-2026-105769) says versions before v1.25.20 could send a Microsoft Entra ID (Azure AD) access token for Azure Resource Manager to an attacker-controlled registry host. According to the advisory, a Dockerfile referencing a lookalike hostname such as x.azurecr.io.attacker.com/img in a FROM or COPY --from= line is enough to trigger the leak. No RUN instruction or image push is required.

The advisory attributes the root cause to kaniko's bundled ACR credential helper (github.com/chrismellard/docker-credential-acr-env). It says the helper decides whether a host is an ACR registry using an unanchored regex, so any hostname that merely contains .azurecr.io (or the .cn, .de, or .us variants) qualifies. The upstream helper module is described as unmaintained with no fixed release. The Go vulnerability database entry is GO-2026-6225.

Why it matters for defenders

Per the advisory, this affects builds using kaniko before v1.25.20 where the build environment has access to an Azure identity. That access can come from service principal credentials, a federated workload identity token (as used by AKS workload identity), or a managed identity reachable through the Instance Metadata Service or MSI_ENDPOINT. Any untrusted Dockerfile or build argument becomes a path to exfiltrate that identity's live Azure Resource Manager token. The advisory notes the attacker's registry does not need to challenge for authentication. If the identity has AcrPush or higher, the attacker could use the exchanged credentials to push images into the victim's own registries.

What defenders should watch for or do now

• Inventory CI/CD and build pipelines using kaniko and confirm the version. The advisory states the fix is in v1.25.20 (PR #495), which validates ACR hostnames exactly rather than via substring match.
• If immediate upgrade is not possible, the advisory recommends removing Azure credentials, federated tokens, and MSI_ENDPOINT/MSI_SECRET from build environments, and blocking build-pod access to the Instance Metadata Service (169.254.169.254).
• The advisory also describes setting AZURE_ENVIRONMENT=none in the kaniko container as a workaround that causes the helper to fail before requesting a token. It recommends replacing a global credsStore: acr-env Docker config with per-host credHelpers entries.
• If untrusted Dockerfiles have been built with an Azure identity present, the advisory urges treating any token issued during that window as compromised. It recommends reviewing Entra ID sign-in logs and Azure activity logs for ACR pushes, role-assignment changes, and key or secret listing activity, since a leaked token stays valid until expiry regardless of credential rotation.
• Hunting angle: review build logs and network egress from build infrastructure for outbound connections to hostnames that contain .azurecr.io, .azurecr.cn, .azurecr.de, or .azurecr.us as a substring rather than a proper suffix. That pattern matches the lookalike-host technique described in the advisory.

The advisory lists a CVSS score of 9.3 and a public proof-of-concept. For the full technical writeup, patch details, and credit to researcher Martin Zihlmann, see the original GHSA advisory.