SOCLYDE logo
Current languageEN
Cybersecurity newsCybersecuritykaniko

Kaniko can send Azure tokens to a lookalike registry

A kaniko advisory details an Azure token leak to lookalike hosts. Check build identities, rebuild affected tools and review their permissions.

Published on

By Soclyde Team

A developer reviews a build environment in a small software studio

In summary

  • A lookalike registry hostname can cause an Azure access token to be sent away.
  • The affected kaniko fork carries its fix in version 1.25.20.
  • An issued token remains valid until expiry despite credential rotation.

Explore next

Soclyde resources

Article contents

An advisory published on November 2, 2026, in the Chainguard-maintained kaniko fork describes a possible Microsoft Entra ID token leak to an attacker-controlled registry. CVE-2026-105769 affects the Azure credential helper included in the build tools. For a team building container images, the question concerns the identity available during a build, beyond the code executed inside an image.

A hostname check accepted too much

The helper recognised Azure registries using a pattern that also accepted a lookalike hostname. An image reference in a Dockerfile could therefore send a token to the wrong host. The advisory says no RUN instruction or image push is required. The build must still be able to obtain an Azure identity: using kaniko does not automatically mean a token has leaked.

Identify the binary actually running

The fork includes its fix from 1.25.20, but the repository distributes neither binaries nor images. DevOpsness compares forks and distinguishes older unmaintained images from this patched source. Record the provenance and digest of the executor, warmer and standalone helper. A tag resembling a fixed version is not sufficient evidence that the component your pipeline runs contains the patch.

Separate untrusted input from Azure identity

Establish who can change Dockerfiles or build arguments, then identify Azure permissions available to the corresponding runners. The scope includes managed and workload identities, beyond secrets explicitly placed in variables. While preparing a rebuild, follow the advisory’s mitigations to prevent untrusted builds from reaching that identity. Test the legitimate publishing path after changing the environment.

Review what a token could have accessed

Safeguard starts with a runner inventory to locate exposed access. If untrusted builds had an Azure identity available, compare their execution windows with Entra ID and Azure activity logs. Credential rotation does not revoke an already issued token. Review secrets readable under the identity’s permissions and unexpected image publications before declaring the incident contained.

Human pipeline-administration accounts should remain distinct from technical identities used by kaniko. Soclyde helps keep their passwords in an encrypted vault on authorised devices, without scattering them across messages. The vault does not filter registry hostnames or replace Azure permission management and the handling of secrets injected into runners.

Takeaway

Identify the executing component, rebuild from patched source and review build permissions. After possible exposure, also address tokens and reachable secrets. The hacked password response guide provides a method for organising changes to associated human accounts.

Frequently asked questions

Does the Dockerfile need a RUN instruction?

No. The advisory says an image reference to a lookalike host can suffice when the build can obtain an Azure identity.

Is version 1.25.20 a ready-made image?

This repository publishes neither binaries nor images. Rebuild the components from a patched release or verify the precise provenance of your distribution.

Does changing an Azure secret invalidate a stolen token?

No. The advisory says an issued token remains valid until expiry. Review logs and any secrets the identity’s permissions allowed it to read.

References

Sources and references

Need advice?

Design your password strategy with Soclyde

Schedule a dedicated walkthrough with the team to see how local-first security adapts to your stack.

Talk with us

Keep reading