CVE-2026-92543

What it actually does

Docker Engine's insecure registry classification uses an any-match DNS resolution against default loopback CIDRs; a hostname resolving to both a loopback address and an attacker-controlled address causes isCIDRMatch to flag the registry as insecure, disabling TLS verification and allowing HTTP fallback on subsequent connections that re-dial the original hostname.

Why it matters to the business

Attackers can intercept or tamper with container image pulls from what appear to be trusted registries, enabling supply-chain compromise of production workloads and downstream deployments.

How an attack unfolds

An attacker poisons DNS responses for a registry hostname so that one address falls inside the default loopback CIDRs while another belongs to the attacker; when the engine resolves the name during image pull, the any-match logic marks the registry insecure, certificate checks are skipped, and the transport connects over plaintext HTTP to the attacker's endpoint.

How to fix it

Upgrade to a patched Docker Engine release that performs secure registry classification without relying on any-match DNS against loopback CIDRs; until fixed, explicitly configure only trusted registries and avoid public DNS resolution for internal registry hostnames.

How to confirm the fix worked

Confirm the engine version is newer than the vulnerable release, review daemon.json for explicit insecure-registries entries, and test that mixed loopback-plus-external DNS responses no longer disable TLS for a known registry hostname.

Typical attack path

1. Attacker gains control of DNS responses for a target registry hostname
2. DNS reply contains at least one loopback IP and one attacker-controlled IP
3. Docker Engine calls loadInsecureRegistries and isCIDRMatch during registry interaction
4. Any-match succeeds, registry is treated as insecure
5. TLS verification disabled and HTTP fallback enabled on re-dial
6. Attacker serves malicious images or intercepts traffic

How to detect it

Search container host logs and auditd or sysmon events for registry hostnames resolved to multiple addresses where one is loopback; inspect Docker daemon logs for insecure-registry classification decisions and subsequent HTTP connections to registry endpoints.

What your security team should do

• Prioritize upgrade of all Docker Engine instances once a fixed version is released
• Harden DNS resolution paths used by container hosts to prevent mixed-address replies
• Audit existing daemon.json insecure-registries settings and remove unnecessary entries
• Monitor for unexpected HTTP registry connections in network logs