CVE-2026-105452

Executive Summary

CVE-2026-105452 affects Docker Sandboxes, a sandboxed execution environment in which untrusted code runs under host-mediated network egress controls. The host egress proxy is supposed to strip client-supplied credentials from outbound requests and replace them with a host-injected credential, but it only removed alternate credential headers whose values matched a fixed set of known sentinel values. Untrusted code inside an authorized sandbox could therefore supply an unrecognized credential in a supported authentication header, causing the proxy to forward that attacker-controlled credential alongside the host-injected one. Against affected upstream services, the request could authenticate as an attacker-controlled account, allowing the attacker to receive and observe data included in the request.

Technical Analysis

The vulnerability is an information-exposure and credential-handling flaw (CWE-200) located in the egress-proxy credential-sanitization logic of Docker Sandboxes. The NVD description establishes the following mechanism without ambiguity, and no further code-level detail is available in the provided data:

• Docker Sandboxes route outbound traffic through a host egress proxy.
• That proxy injects a host-controlled credential into outbound requests on behalf of the sandboxed workload.
• The proxy is designed to remove alternate, client-supplied credentials so that only the host-injected credential survives.
• Removal of alternates was conditional: it occurred only when the alternate credential's value matched a known sentinel value.
• Any credential value not matching a known sentinel was left in place.
• Because multiple authentication headers are supported, untrusted code in an authorized sandbox could place an unrecognized credential into one of those other supported authentication headers.
• The proxy then forwarded both the attacker-supplied credential and the host-injected credential.

The security consequence is a credential-precedence ambiguity at the upstream service. When a request carries more than one authentication credential, the receiving service decides which one to honor. For "affected upstream services" — those that select the attacker-supplied credential rather than the host-injected one — the request authenticates to an attacker-controlled account. The corollary is data exposure: any content the sandboxed workload includes in that request (which the requesting code may believe is going to a trusted, host-authenticated destination) is then delivered to infrastructure controlled by the attacker.

Two properties make this severe. First, the attacker does not need to break out of the sandbox: the flaw is reachable by untrusted code operating entirely within its authorized boundary, which lowers the prerequisite attacker position. Second, the fix pattern implied by the description is a deny-by-default sanitization model (remove all client-supplied credentials in supported authentication headers) rather than the allow/deny-by-sentinel model that was implemented. The sentinel-matching design is inherently incomplete because it enumerates known-bad values instead of enumerating known-good headers.

Note on scope: no affected version range, fixed version, or vendor advisory is published in the supplied data. No CVSS score or vector is published by NVD; the vector shown in METADATA is an analytic estimate based on the described preconditions and impact and must not be treated as an authoritative score. EPSS has not yet scored this CVE.

Exploitation Scenarios

The attack chain is inferred from the NVD description and the vulnerability class. There is no public PoC, no Nuclei template, and no exploit code available. No specific function names, endpoints, or parameters are named in the source data, so the chain is described at the class level.

1. Reconnaissance and target identification. The attacker needs the ability to execute untrusted code inside an authorized Docker Sandbox whose egress traffic is mediated by the host proxy. This is the primary precondition and is a lower bar than a host escape. The attacker also needs at least one upstream service reachable through the sandbox that is "affected" — that is, a service that accepts multiple authentication headers and resolves the conflict in favor of the client-supplied credential.

2. Triggering the flaw class. From within the sandbox, the workload issues an outbound HTTP request to the target upstream service and attaches an authentication credential in a supported authentication header that is not one of the sentinel values the proxy recognizes. Because sanitization is value-matched rather than header-based, the proxy does not remove it.

3. Payload and execution method. The payload is the request itself. The proxy appends/injects the host credential as designed, so the outbound request now carries the attacker's unrecognized credential in one authentication header and the host-injected credential in another. On an affected upstream service, the attacker's credential takes precedence and the request is authenticated against the attacker's account.

4. Post-exploitation impact. Because the request is now bound to the attacker's account, any data the sandboxed workload included in the request — request bodies, parameters, or metadata the workload believed it was sending to a trusted, host-authenticated destination — becomes visible to the attacker. This is a data-exfiltration primitive achieved without credential theft and without sandbox escape: the victim workload cooperates unwittingly by simply making a normal outbound call.

No public exploit exists; the chain above is inferred from the vulnerability class and the described sanitization defect.

Impact Assessment

Business impact concentrates in confidentiality. The flaw provides a channel by which a workload inside an authorized sandbox can be induced to deliver its outbound payloads to an attacker-controlled account, which is an exfiltration path for whatever sensitive content those requests carry — API parameters, tokens embedded in bodies, internal identifiers, or business data. Integrity and availability impacts are not described and are not claimed here.

Blast radius depends on two variables: how many upstream services resolve multi-credential conflicts in favor of the client-supplied credential, and how much sensitive content sandboxed workloads routinely place in outbound requests. Environments that run untrusted or third-party code in Docker Sandboxes and allow egress to third-party APIs have the largest exposure, because both preconditions are met simultaneously.

On scoring: NVD has published no CVSS score or vector for this CVE, and the analytic estimate used in METADATA (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N) reflects a network-reachable, low-complexity attack requiring an authenticated position inside the sandbox, with scope change because the vulnerable component (proxy) and the impacted component (upstream service) differ, and high confidentiality impact only. Treat this as an estimate, not a vendor-confirmed rating. No CISA KEV listing and no EPSS score exist at time of writing, indicating no observed exploitation in the wild and no scoring maturity yet.

Detection Guidance

Sigma Rule

title: Docker Sandbox Egress Proxy Forwarding Multiple Authentication Headers
id: 7f3c1a2e-9b44-4c8d-a1f0-2d6e5b7c9a10
status: experimental
description: Detects outbound requests from Docker Sandbox egress proxies carrying more than one authentication credential header, indicating possible sentinel-bypass credential smuggling (CVE-2026-105452).
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-105452
author: Threat Intelligence
date: 2026/01/01
logsource:
  category: proxy
detection:
  selection_auth_headers:
    cs-header|contains:
      - 'Authorization:'
      - 'Proxy-Authorization:'
      - 'X-Api-Key:'
      - 'X-Auth-Token:'
  selection_multi:
    cs-headers|re: '(?i)(authorization|proxy-authorization|x-api-key|x-auth-token)[^\r\n]*\r?\n[^\r\n]*(authorization|proxy-authorization|x-api-key|x-auth-token)'
  condition: selection_multi
falsepositives:
  - Legitimate clients sending both an API key and a bearer token by design
  - Proxy logs that concatenate request headers from unrelated transactions
level: medium
tags:
  - attack.t1078
  - cve.2026.105452

YARA Rule

rule CVE_2026_105452_Docker_Sandbox_Multi_Auth_Header
{
    meta:
        description = "Detects sandbox payloads emitting multiple authentication headers to bypass Docker egress proxy sentinel sanitization (CVE-2026-105452)"
        author = "Threat Intelligence"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-105452"
        date = "2026-01-01"
        severity = "medium"

    strings:
        $h1 = "Authorization:" ascii nocase
        $h2 = "Proxy-Authorization:" ascii nocase
        $h3 = "X-Api-Key:" ascii nocase
        $h4 = "X-Auth-Token:" ascii nocase
        $crlf = "\r\n" ascii

    condition:
        uint16(0) == 0x4854 or 2 of ($h1, $h2, $h3, $h4)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-105452 Docker Sandbox Egress Proxy Multiple Auth Headers"; flow:established,to_server; http.header; content:"Authorization"; nocase; http.header; content:"X-Api-Key"; nocase; http.header; content:"X-Api-Key"; distance:0; threshold:type limit, track by_src, count 1, seconds 60; reference:cve,2026-105452; classtype:attempted-recon; sid:2026105452; rev:1;)

Elastic Detection

sequence by source.ip with maxspan=5s
  [network where http.request.headers contains "Authorization" and http.request.headers contains "X-Api-Key"]
  [network where destination.port in (443, 80) and http.request.method is not null]

Splunk SPL Query

index=proxy sourcetype=*:proxy*
| eval hdrs=lower(coalesce(http_request_headers, cs_headers, headers, ""))
| eval auth_count = (if(like(hdrs,"%authorization:%"),1,0) + if(like(hdrs,"%proxy-authorization:%"),1,0) + if(like(hdrs,"%x-api-key:%"),1,0) + if(like(hdrs,"%x-auth-token:%"),1,0))
| where auth_count > 1
| stats count values(dest) as destinations by src_ip hdrs
| where count > 0
| sort - count

Wazuh OSSEC Rule

<group name="docker,cve_2026_105452,">
  <rule id="105452" level="8">
    <decoded_as>json</decoded_as>
    <field name="headers">Authorization</field>
    <field name="headers">X-Api-Key</field>
    <description>CVE-2026-105452: Request from sandbox carries multiple authentication headers, possible egress proxy credential bypass</description>
    <mitre>
      <id>T1078</id>
    </mitre>
    <group>cve_2026_105452,credential_access,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).

1. Immediate mitigations.

   • Reduce the trust placed in the egress proxy's sanitization. Treat any outbound request from a sandbox as potentially attacker-influenced and avoid placing high-value secrets or sensitive business data in sandbox-originated request bodies.
   • Where the proxy configuration permits it, restrict sandbox egress to an explicit allowlist of upstream destinations, and require that those destinations use only a single, deterministic authentication scheme.
   • Add detection coverage (see above) for outbound requests carrying more than one authentication header originating from sandbox subnets.
   • Review upstream services you control: enforce single-credential resolution and reject requests presenting conflicting authentication headers rather than silently selecting one.

2. Patch/upgrade steps.

   • No vendor fix, fixed version, or advisory is published. Monitor Docker's security advisory channel and NVD for CVE-2026-105452 for an updated release. Do not assume a patch exists until a vendor-published fixed version is available.
   • When a fix is published, validate that the sanitization logic was changed from value/sentinel matching to unconditional removal of all client-supplied credentials from every supported authentication header, and test that behavior directly before rolling out.

3. Long-term hardening.

   • Adopt deny-by-default header handling in egress proxies: strip all client-supplied authentication headers, then inject only the host credential. Never rely on enumerating known-bad sentinel values.
   • Enforce per-sandbox least-privilege egress policies and mutual separation so that one sandbox's traffic cannot influence credential resolution for another.
   • Instrument proxy and upstream-service logs to alert on credential-precedence conflicts as a standing control, independent of this specific CVE.

References

• NVD — CVE-2026-105452: https://nvd.nist.gov/vuln/detail/CVE-2026-105452
• CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor: https://cwe.mitre.org/data/definitions/200.html
• MITRE ATT&CK T1078 — Valid Accounts: https://attack.mitre.org/techniques/T1078/
• FIRST EPSS (score pending for CVE-2026-105452): https://www.first.org/epss/
• CISA Known Exploited Vulnerabilities Catalog (CVE-2026-105452 not listed): https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• Docker Security Advisories: https://docs.docker.com/security/

Note on exploitation status: no CISA KEV listing, no EPSS score, no public PoC, no Nuclei template, and no exploit code were identified for CVE-2026-105452. No threat actor campaign is known to be associated with this CVE. All attack-chain content above is inferred from the vulnerability class and the NVD description; it is not derived from observed exploitation.