CVE-2026-92543 in Docker Engine
Summary
by MITRE • 10/07/2026
Docker Engine classifies a registry hostname as insecure using an any-match DNS check. loadInsecureRegistries() injects 127.0.0.0/8 and ::1/128 as insecure CIDRs by default. isCIDRMatch resolves all of the hostname's addresses and returns true if a single address is in the insecure CIDR list. Because the transport re-dials the hostname rather than the CIDR-matching address, a DNS answer set of one loopback IP plus a non-loopback attacker IP disables certificate verification and enables HTTP fallback for the registry connection.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/07/2026
The vulnerability stems from a fundamental flaw in how Docker Engine handles insecure registry classification during image pulls or pushes. The core issue lies in the interaction between DNS resolution logic, CIDR matching algorithms, and network transport behavior. Specifically, the function loadInsecureRegistries() defaults to treating all addresses within the 127.0.0.0/8 IPv4 range and ::1/128 IPv6 loopback ranges as insecure. This is a reasonable security posture for local development environments where self-signed certificates are common on localhost endpoints. However, the mechanism used to determine if a specific registry hostname falls into these categories relies on an any-match DNS check via the isCIDRMatch function.
The technical flaw occurs when Docker resolves the hostname of the target registry. Instead of checking only the primary or expected IP address against the insecure CIDRs, the system resolves all available addresses associated with that hostname. If even a single resolved IP address falls within one of the designated insecure loopback ranges, the entire connection is flagged as insecure. This design choice assumes that if any part of the DNS response points to localhost, the service should be treated as untrusted in terms of certificate validation. While this might prevent accidental connections to local services without proper certificates, it creates a critical attack vector when combined with specific network configurations or malicious DNS responses.
The operational impact is severe because flagging a registry connection as insecure triggers two major security relaxations: the disabling of TLS certificate verification and the fallback to plain HTTP if HTTPS fails or is deemed unsafe. In a normal scenario, this protects users from man-in-the-middle attacks on local services. However, an attacker who can influence DNS resolution for a target hostname can exploit this logic. By ensuring that the DNS response includes at least one loopback address alongside legitimate public IP addresses, the attacker forces Docker to classify the connection as insecure. Consequently, Docker will skip certificate validation and may downgrade the protocol to HTTP, allowing the attacker to intercept or modify traffic if they control the network path between the client and the non-loopback IPs.
This vulnerability aligns with CWE-295: Improper Certificate Validation, as the system fails to properly validate certificates due to a logic error in determining trust boundaries. It also relates to CWE-787: Out-of-bounds Write or Read if we consider the potential for memory corruption during DNS parsing, though the primary issue is logical. From an ATT&CK perspective, this falls under T1046: Network Service Discovery and potentially T1557: Adversary-in-the-Middle, as it enables credential theft or data exfiltration by bypassing encryption controls through a configuration logic flaw rather than direct exploitation of code execution vulnerabilities.
Mitigation strategies must address both the DNS resolution behavior and the CIDR matching logic. Administrators should avoid using hostnames that resolve to loopback addresses for critical registry operations unless explicitly intended for local development. Docker users can mitigate this by configuring specific insecure registries in their daemon.json file rather than relying on default behaviors, ensuring only known safe localhost endpoints are exempted from certificate checks. Additionally, updating to patched versions of Docker Engine is essential if a fix has been released that restricts the any-match DNS check to only validate against explicitly configured insecure registry patterns or limits loopback CIDR matching to direct local connections rather than all resolved addresses for remote hostnames. Network-level controls such as DNSSEC can also help prevent attackers from injecting malicious IP addresses into DNS responses, thereby reducing the risk of triggering this false positive classification.