Docker Sandboxes EUVD-2026-95156

Requires the Docker Sandboxes managed-credential injection feature to be in use with an OAuth-based provider, AND attacker-controlled (untrusted/malicious) code executing inside the sandbox, AND a user who actively completes the OAuth authorization flow (UI:A). Exploitation is bounded by this mandatory user interaction and by the need for code execution already inside the sandbox (local vector) - a remote, unauthenticated, no-interaction attack is not possible. The core technical trigger is reaching the genuine provider token endpoint via a case-variant hostname that DNS routing resolves but the case-sensitive masking logic fails to match.

This is a genuine but moderate-priority confidentiality issue, not a high-urgency emergency. The vendor-supplied CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:A/VC:H) scores 6.7 (Medium) and is internally consistent with the description: exploitation originates from code already running locally inside a Docker Sandbox (AV:L), requires no privileges (PR:N), but hinges on the victim actively completing an OAuth flow (UI:A), and yields high confidentiality impact (VC:H) with no integrity or availability effect (VI:N/VA:N). No EPSS score, no CISA KEV listing, and no public POC are present in the provided data, so there is no evidence of active or at-scale exploitation - the risk is latent and conditional. The limiting factor is significant: an attacker gains nothing unless a user voluntarily completes the OAuth authorization, so this favors a targeted, opportunistic scenario (malicious or compromised code inside a sandbox waiting for a credential flow) rather than mass automated exploitation. Signals are consistent rather than conflicting; the main caveat is sourcing - the analysis rests solely on Docker's own advisory and documentation links, with no third-party corroboration of affected versions or fix availability.

A developer runs an untrusted or malicious AI-agent workload inside a Docker Sandbox configured for managed credential injection. The malicious code requests the OAuth token endpoint using a case-variant hostname (e.g., altered capitalization) that still routes correctly via case-insensitive DNS but evades the case-sensitive masking check; when the user then completes the OAuth flow, the provider's unmasked access and refresh tokens are handed directly to the sandboxed code. No public exploit code is identified at time of analysis.