Docker Sandboxes EUVD-2026-95157

Requires an attacker to already have code running inside an authorized Docker Sandbox (PR:L) in a deployment that uses Docker Sandboxes credential injection to proxy host-managed OAuth tokens or a derived Anthropic API key. Exploitation specifically depends on triggering the edge condition where a proxied response-body read returns data together with an error, causing affected handlers to fail open (CWE-636) and forward unmasked credential bytes rather than redacting them; this error-plus-data condition is not guaranteed on every request (AT:P), which limits reliability. It does NOT work against sandboxes that do not inject host-managed credentials, and it is not remotely reachable by an unauthenticated external attacker - the attacker must be operating from within the sandbox trust boundary, which is the primary limiting factor on real-world risk.

This is a moderate-severity information-disclosure issue (vendor CVSS 4.0 base 5.9), and the available signals are internally consistent rather than conflicting. The CVSS 4.0 vector (AV:A/AC:L/AT:P/PR:L/UI:N) indicates an attacker must already be running code inside an authorized Docker Sandbox (PR:L) and must catch a specific error-plus-data condition (AT:P - a non-guaranteed attack requirement), which keeps real-world exploitability below what a raw 'credential theft' headline would suggest. The impact is narrow but meaningful: confidentiality only (VC:H), exposing host-managed OAuth access/refresh tokens or a derived Anthropic API key, with no integrity or availability impact (VI:N/VA:N) and no declared scope change to a subsequent system (SC:N). There is NO EPSS score, NO CISA KEV listing, and NO public exploit in the provided data, so there is no public exploit identified at time of analysis and no evidence of active exploitation - this is a design/trust-boundary weakness (CWE-636, failing open) disclosed by the vendor rather than an urgently-exploited flaw. Net: a legitimate fix-it priority for anyone running Docker Sandboxes with credential injection, but not a drop-everything emergency, because exploitation presupposes attacker-controlled code already executing inside the sandbox trust boundary.

An attacker who can run code inside an authorized Docker Sandbox (for example via a malicious or compromised AI agent/tool executing in that sandbox) issues requests through the credential-masking proxy and repeatedly triggers the condition where a response-body read returns data together with an error. Because affected handlers fail open and forward the unmasked bytes in that case, the sandboxed code recovers the host-managed OAuth access and refresh tokens or the derived Anthropic API key that were supposed to stay outside the sandbox. No public exploit code is identified in the provided data.