Kaniko
Monthly
kaniko builds before v1.25.20 can leak the build's Microsoft Entra ID (Azure AD) access token to an attacker-controlled registry host, because the bundled ACR credential helper github.com/chrismellard/docker-credential-acr-env matches ACR hosts with an unanchored regular expression and therefore accepts any name that merely contains '.azurecr.io', '.azurecr.cn', '.azurecr.de' or '.azurecr.us'. A Dockerfile the operator does not fully control needs only a FROM or COPY --from=<image> pointing at a lookalike host such as x.azurecr.io.attacker.com - no RUN instruction and no push - for kaniko to fetch a token from the build's Azure identity (service principal variables, a federated workload identity token, or a managed identity via IMDS/MSI_ENDPOINT) and POST it to https://<host>/oauth2/exchange, where the attacker can reuse it against Azure Resource Manager and exchange it for credentials to any ACR registry the identity can reach. The vector is AV:N/AC:L/PR:N/UI:R/S:C with high confidentiality and integrity impact and no availability impact; exploitation is only possible where an Azure identity is actually reachable from the build environment, and no public exploit code was identified at time of analysis. Vendor-released patch: kaniko v1.25.20.
Path traversal in Kaniko 1.25.4 through 1.25.9 allows attackers to extract tar archives outside the intended destination directory, enabling arbitrary file writes on the build system. When combined with Docker credential helpers in registry authentication scenarios, this vulnerability can be leveraged for code execution within the Kaniko executor process. Docker and Kubernetes environments using the affected Kaniko versions are at risk.
kaniko builds before v1.25.20 can leak the build's Microsoft Entra ID (Azure AD) access token to an attacker-controlled registry host, because the bundled ACR credential helper github.com/chrismellard/docker-credential-acr-env matches ACR hosts with an unanchored regular expression and therefore accepts any name that merely contains '.azurecr.io', '.azurecr.cn', '.azurecr.de' or '.azurecr.us'. A Dockerfile the operator does not fully control needs only a FROM or COPY --from=<image> pointing at a lookalike host such as x.azurecr.io.attacker.com - no RUN instruction and no push - for kaniko to fetch a token from the build's Azure identity (service principal variables, a federated workload identity token, or a managed identity via IMDS/MSI_ENDPOINT) and POST it to https://<host>/oauth2/exchange, where the attacker can reuse it against Azure Resource Manager and exchange it for credentials to any ACR registry the identity can reach. The vector is AV:N/AC:L/PR:N/UI:R/S:C with high confidentiality and integrity impact and no availability impact; exploitation is only possible where an Azure identity is actually reachable from the build environment, and no public exploit code was identified at time of analysis. Vendor-released patch: kaniko v1.25.20.
Path traversal in Kaniko 1.25.4 through 1.25.9 allows attackers to extract tar archives outside the intended destination directory, enabling arbitrary file writes on the build system. When combined with Docker credential helpers in registry authentication scenarios, this vulnerability can be leveraged for code execution within the Kaniko executor process. Docker and Kubernetes environments using the affected Kaniko versions are at risk.