Kaniko's Azure token leak starts with a hostname check
A container build can carry more authority than the application it produces. Kaniko builds run with registry credentials and, on Azure, may also receive an Entra ID identity through a service principal, federated workload identity, or the Azure Instance Metadata Service. CVE-2026-105769 matters because one hostname check can move that Azure Resource Manager token to a host selected by whoever controls the image reference.
The GitHub-reviewed advisory describes the flaw as an origin validation error. It affects kaniko before v1.25.20 and assigns a CVSS v3.1 score of 9.3. The important detail is not the score alone. It is the order of operations: kaniko can ask the Azure credential helper for a token before it has established that the destination is a legitimate Azure Container Registry endpoint.
The trust decision before registry authentication
Kaniko uses docker-credential-acr-env to obtain credentials for Azure Container Registry. The advisory says the helper decided whether a host was an ACR registry with an unanchored regular expression. A hostname such as evil.azurecr.io.attacker.example contains the string .azurecr.io, so it can satisfy that check even though the effective DNS owner is attacker.example.
Kaniko consults the helper for a registry that has no matching entry in its Docker configuration and is not a Google or Amazon ECR endpoint. The advisory says an attacker does not need the build to use ACR or explicitly enable the helper. If an Azure identity is available and the registry hostname falls into the helper path, the token acquisition can occur.
The token is then sent to the registry host. Depending on the request path, it may appear in an Authorization header or a form field. The advisory identifies the token as a Microsoft Entra ID access token for Azure Resource Manager. That scope makes the issue larger than an image-pull failure. A leaked ARM token can expose cloud-resource actions allowed by the workload identity rather than access limited to a container repository.
Who should treat this as an active build-security issue
The exposed population is narrower than every kaniko user. An organization needs three conditions together: a kaniko version before 1.25.20, an Azure identity available to the build process, and a way for an attacker to influence a registry hostname used in the build. That last condition can come from a Dockerfile, a build argument, a CI variable, or a template that accepts an image reference from a less-trusted source.
An attacker does not need to compromise the Azure control plane first. The build supply chain becomes the initial movement path. A malicious pull request that changes a base-image reference may be enough in a repository where untrusted contributors can run a privileged build. A shared pipeline template can spread the problem across many repositories even when each application team believes it controls its own Dockerfile.
This is also a token-lifecycle problem. A successful request creates a credential exposure in the build log, proxy, or attacker service. Rotating the image or rebuilding does not automatically invalidate the token. The incident response question is which Azure identity was available, what the token could do, and whether any ARM activity followed the build.
Detection without pretending every registry request is malicious
Start with build telemetry. Look for registry hostnames that contain an ACR suffix but do not end at an Azure-controlled domain. Review DNS queries, proxy logs, egress firewall records, and any HTTP request metadata that records the registry host. The search should include build arguments and generated Dockerfiles, not only committed source files.
Next, map kaniko versions and identity injection. In AKS, federated workload identity may make a token available without a long-lived secret in the pod. On an Azure VM or node, managed identity may supply it through the metadata service. A build that can reach those identity sources deserves a separate review even if it does not use ACR.
Azure activity logs should be correlated with the build window. Review token issuance where available, resource-management calls, role assignment changes, key or secret access, and attempts to create new identities. A token theft with no follow-on activity is still a credential compromise, but the absence of one log source is not proof that nothing happened.
Remediation and the remaining control problem
Upgrade kaniko to v1.25.20 or later. Then remove the conditions that turned the defect into a credential leak. Pin allowed registry domains at the CI layer, reject image references that resolve outside that allowlist, and avoid giving every build a broad Azure identity. Split deployment authority from build authority so a compromised build cannot create role assignments or alter unrelated subscriptions.
Rotate any identity material that may have been exposed. Review token caches and federated-token trust relationships, not only service-principal secrets. For high-value subscriptions, inspect recent Azure activity from the affected workload identity and revoke sessions or credentials where the provider supports it.
The permanent lesson is that registry allowlisting belongs before credential acquisition. A helper that obtains a token and then discovers the destination was never an ACR endpoint has already crossed the important boundary. Build platforms should make that decision explicit, fail closed, and log the destination host before an identity provider is contacted.
Top comments (0)