Docker Sandboxes EUVD-2026-95159

Exploitation requires an attacker to execute untrusted code inside an authorized Docker Sandbox that uses the host egress proxy's credential-injection feature (documented at docs.docker.com/ai/sandboxes/configuration/credentials). The targeted upstream service must accept an alternate/secondary authentication header that the egress proxy does not scrub - the proxy only strips credentials whose values match known sentinel values, so an unrecognized credential in another supported auth header passes through. Limiting factors: the attacker must already control code running in the sandbox (local vector), credential injection must be enabled, and only upstream services that honor the attacker-supplied alternate credential are affected; services not supporting such headers are not exploitable, and impact is confined to confidentiality of data contained in the outbound request.

This is a genuine but moderate-severity confidentiality issue, not a drop-everything emergency. The vendor-assigned CVSS 4.0 score of 5.9 (medium) reflects a design that is AV:L (local - the attacker must already execute code inside an authorized Docker Sandbox), AC:L (the sentinel-matching scrub is trivially bypassed by using a different credential value), AT:P (a real precondition exists: the targeted upstream service must support an alternate authentication header that the egress proxy does not strip), PR:N and UI:N, with impact limited to VC:H and no integrity or availability effect (VI:N/VA:N). No EPSS score, KEV listing, or public exploit was provided in the input, so there is no public exploit identified at time of analysis and no evidence of active exploitation - this is a vendor-reported (Docker) hardening fix rather than an in-the-wild threat. The PR:N designation is worth scrutinizing: the attacker is 'untrusted code in an authorized sandbox,' so while the code itself holds no credentials (justifying PR:N), exploitation still presupposes the attacker controls code running in that sandbox, a condition the AV:L and AT:P metrics capture rather than PR. Overall, treat this as a prioritize-when-patching item for teams running Docker Sandboxes with egress-proxy credential injection, not a widespread critical.

An attacker who can run untrusted code inside an authorized Docker Sandbox (for example, AI-generated or third-party code the sandbox is designed to isolate) crafts an outbound request to an upstream service, adding its own credential in a supported-but-alternate authentication header. Because the host egress proxy only removes credentials matching known sentinel values, the attacker's unrecognized credential survives alongside (or in place of) the injected one, causing the upstream service to authenticate the request to an attacker-controlled account and return or log data from the request. No public exploit code was identified at time of analysis; the issue was reported by Docker.