CVE-2026-92543

Executive Summary

CVE-2026-92543 is a TLS certificate-verification bypass in Docker Engine's registry hostname classification logic. loadInsecureRegistries() injects the loopback CIDRs 127.0.0.0/8 and ::1/128 as insecure by default, and isCIDRMatch() treats a registry hostname as insecure if any single address in its DNS answer set falls inside one of those CIDRs. Because the transport layer subsequently re-dials the hostname — not the specific matched address — an attacker who controls or poisons DNS can return a mixed answer set containing both a loopback address and a real attacker-controlled non-loopback address. Docker then disables certificate verification and permits HTTP fallback for that registry connection, exposing image pulls and pushes to man-in-the-middle (MITM) interception and image substitution.

Technical Analysis

Docker Engine supports per-registry configuration that marks certain registries as "insecure," meaning they may be contacted over plaintext HTTP and/or without TLS certificate verification. Per the NVD description, two loopback CIDRs are injected into that insecure set by default: 127.0.0.0/8 and ::1/128. This is intended to allow local registries on loopback to be reached without certificate plumbing.

The classification is performed by isCIDRMatch(), which resolves all addresses for a given registry hostname and returns true if a single address in the resolution result lies within the insecure CIDR list. This is an any-match semantic: the presence of one matching address is sufficient to flag the entire hostname as insecure.

The critical design flaw is a mismatch between the address used for the decision and the address used for the connection. The decision is made against a resolved address inside an insecure CIDR, but the transport "re-dials the hostname rather than the CIDR-matching address." The DNS resolver is free to return multiple A/AAAA records, and the connection path will follow standard resolution/selection behavior. An attacker who can influence DNS (poisoning, a compromised authoritative server, a hostile resolver, or controlled search/forwarder configuration) returns an answer set combining one loopback address and one non-loopback attacker-controlled address. isCIDRMatch() sees the loopback entry, returns true, and the registry is classified insecure. Docker then, per the description, "disables certificate verification and enables HTTP fallback" for that registry connection. The actual TCP connection can then be steered to the attacker address, over HTTP or over TLS with verification off, allowing full interception of credentials and image content.

This is classified as CWE-295 (Improper Certificate Validation). The root cause is a logic error in insecure-hostname classification, not a cryptographic break of TLS itself. It is an implementation/design weakness in how "insecure" status is derived from multi-address DNS answer sets.

No public proof-of-concept, exploit code, or Nuclei template is currently available. No CVSS vector was assigned by the enriching source (N/A); the vector listed above is an analytical estimate reflecting network-reachable, MITM-circumstance exploitation with high confidentiality and integrity impact, and is explicitly not an official score.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred from the vulnerability class and the mechanics stated in the NVD description.

1. Reconnaissance / target identification. The attacker identifies an environment where Docker Engine performs registry pulls/pushes against a hostname that resolves through attacker-influenceable DNS infrastructure (hostile or compromised resolver, poisoned cache, rogue upstream, or a network position allowing DNS spoofing/redirect). Targets of interest are CI/CD build runners, orchestration nodes, and build agents that pull base images automatically.

2. Triggering the flaw class. The attacker manipulates the DNS answer set for the registry hostname so that it contains at least one address within 127.0.0.0/8 or ::1/128 and at least one attacker-controlled non-loopback address. isCIDRMatch() observes the loopback entry and, applying any-match logic, classifies the registry as insecure.

3. Execution method (vulnerability-class level). Because the registry is now classified insecure, Docker disables certificate verification and permits HTTP fallback for the connection, and the transport re-dials the hostname rather than the loopback address that caused the match. The connection is therefore steered to the attacker address with TLS validation suppressed or plaintext HTTP used. This is a man-in-the-middle condition rather than remote code execution — the attacker positions themselves as the registry endpoint.

4. Post-exploitation impact. With certificate verification disabled and/or HTTP fallback active, the attacker can present a rogue registry endpoint, harvest registry credentials/auth tokens in transit, and serve substituted or backdoored image layers that Docker will pull and run without a certificate-validation failure. This yields supply-chain integrity compromise (malicious images executed in the victim environment) and confidentiality loss (registry credentials, image contents).

Impact Assessment

Exploitation gives an attacker in a DNS-interception position the ability to impersonate a Docker registry, capture credentials, and inject images that the engine will accept without certificate validation. The blast radius is any host or pipeline whose Docker Engine resolves a registry hostname through attacker-influenceable DNS and subsequently pulls or pushes images. In containerized CI/CD and orchestration environments, poisoned base images can propagate laterally into workloads, making this a supply-chain integrity concern rather than an isolated host issue.

Confidentiality and integrity impacts are high: credentials and image content can be intercepted, and image content can be altered. Availability impact is limited and is not the primary objective. Exploitation requires the attacker to already control or influence name resolution (MITM positioning), which raises attack complexity and is reflected in the analytical vector (AC:H). The EPSS score is 0.00087 (0.3rd percentile), indicating very low modeled near-term exploitation likelihood; CISA KEV status is NO, and no in-the-wild exploitation evidence is reported. No official CVSS score or vendor severity was provided.

Detection Guidance

The following detections are heuristic and target the observable behavior of the flaw (registry contact over HTTP, TLS verification failures, anomalous Docker daemon/registry activity, and mismatched DNS resolution). Signatures should be tuned to the environment; no official detection content exists for this CVE.

Sigma Rule

title: Docker Registry Contact With Disabled TLS Verification or HTTP Fallback
id: 6f1a9c2e-9254-4c7b-9b3a-000000092543
status: experimental
description: Detects Docker Engine contacting a registry over HTTP or with TLS verification disabled, consistent with CVE-2026-92543 insecure-registry misclassification.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-92543
author: Valters IT Threat Intelligence
date: 2026/01/01
logsource:
  product: linux
  service: docker
detection:
  keywords_daemon:
    - "insecure registry"
    - "http: server gave HTTP response to HTTPS client"
    - "x509: certificate signed by unknown authority"
    - "TLS handshake error"
    - "registry"
  selection_daemon:
    - "dial tcp"
    - "pulling image"
  condition: selection_daemon and keywords_daemon
falsepositives:
  - Legitimate local/private registries intentionally configured as insecure.
level: medium
tags:
  - attack.t1190
  - cve.2026.92543

YARA Rule

rule CVE_2026_92543_Docker_Insecure_Registry_Logic
{
    meta:
        description = "Heuristic detection of Docker Engine insecure-registry classification logic related to CVE-2026-92543"
        author = "Valters IT Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-92543"
        date = "2026-01-01"
    strings:
        $fn1 = "loadInsecureRegistries" ascii
        $fn2 = "isCIDRMatch" ascii
        $cidr1 = "127.0.0.0/8" ascii
        $cidr2 = "::1/128" ascii
    condition:
        (uint32be(0) == 0x7f454c46 or uint32be(0) == 0x464c457f) and
        (
            any of ($fn*) or
            (all of ($cidr*)) or
            ($fn1 and any of ($cidr*)) or
            ($fn2 and any of ($cidr*))
        )
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-92543 Possible Docker Registry MITM - Plaintext Registry Traffic"; flow:established,to_server; http.host; content:"/v2/"; http.uri; content:"/v2/"; classtype:attempted-recon; sid:202692543; rev:1;)

Elastic Detection

sequence by host.id with maxspan=5m
  [ network where network.transport == "tcp" and destination.port in (80, 5000) and process.name == "dockerd" ]
  [ network where network.transport == "tcp" and dns.question.name != null and process.name == "dockerd" ]

Splunk SPL Query

index=linux sourcetype=docker OR sourcetype=syslog
("insecure registry" OR "server gave HTTP response to HTTPS client" OR "x509: certificate signed by unknown authority")
| stats count min(_time) as first_seen max(_time) as last_seen by host, source, message
| where count > 0
| sort - count

Wazuh OSSEC Rule

<group name="docker,cve-2026-92543,">
  <rule id="100925" level="8">
    <decoded_as>json</decoded_as>
    <field name="message">insecure registry</field>
    <description>CVE-2026-92543: Docker Engine treating a registry as insecure (possible DNS-based TLS verification bypass).</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
  <rule id="100926" level="10">
    <decoded_as>json</decoded_as>
    <field name="message">server gave HTTP response to HTTPS client</field>
    <description>CVE-2026-92543: Docker fell back to plaintext HTTP for a registry connection.</description>
    <mitre>
      <id>T1190</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). No vendor fix or workaround was provided in the available data.

1. Immediate mitigations

   • Harden DNS: use DNSSEC-validating resolvers, disable untrusted forwarders, and restrict who can inject A/AAAA records for internal registry hostnames.
   • Force encrypted registry transport for all production registries so certificate verification is not silently downgraded; monitor for any connection that downgrades to HTTP for a registry endpoint.
   • Network-segment build/CI hosts so that registry traffic cannot be redirected to non-corporate addresses; pin registry hostnames to known-good IPs where operationally feasible.
   • Alert on Docker daemon TLS verification failures and HTTP-fallback messages (see Detection Guidance), and investigate any registry hostname that resolves to a mixed loopback/non-loopback answer set.

2. Patch / upgrade steps

   • No patch is currently available from any tracked source. Track the Docker Engine security advisories and release notes; apply the vendor fix as soon as it is published and re-validate the insecure-registry classification behavior in a test environment.

3. Long-term hardening

   • Treat DNS resolution for container registries as a trust boundary and enforce authenticated, integrity-protected resolution.
   • Adopt image signature verification (e.g., content trust / signature verification) so that a rogue registry endpoint cannot serve accepted images even if TLS verification is bypassed.
   • Periodically audit the effective insecure-registry set and ensure loopback defaults cannot cause non-loopback endpoints to be classified insecure.

References

• NVD — CVE-2026-92543: https://nvd.nist.gov/vuln/detail/CVE-2026-92543
• MITRE CWE-295 — Improper Certificate Validation: https://cwe.mitre.org/data/definitions/295.html
• FIRST EPSS — score lookup for CVE-2026-92543: https://api.first.org/data/v1/epss?cve=CVE-2026-92543
• CISA Known Exploited Vulnerabilities Catalog (not listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Docker Engine security advisories and release notes: https://docs.docker.com/engine/release-notes/

No threat actor campaigns or exploit-in-the-wild evidence are reported for CVE-2026-92543 at this time (CISA KEV: NO; EPSS 0.00087).