docker-socket-proxy CVE-2026-78122

Exploitation requires that the CONTAINERS environment variable is set to a truthy value in the docker-socket-proxy deployment - this specific configuration flag is the prerequisite that triggers the overly broad access grant. The attacker must additionally have adjacent network access to the TCP port on which the proxy is listening (AV:A), typically within the same Docker bridge network, host network, or reachable subnet. No authentication credentials against the proxy are required (PR:N per the CVSS 4.0 vector). Exploitation is strictly limited to read operations - the four vulnerable endpoints (/containers/{id}/archive, /containers/{id}/export, /containers/{id}/logs, /containers/{id}/top) produce no write, execution, or availability impact. Deployments where CONTAINERS is set to 0 or unset (the documented default) are not affected by this vulnerability. Knowledge of a valid container ID or name is needed to target a specific container, though /containers/json (also permitted under CONTAINERS=1) can be used to enumerate running containers.

The CVSS 4.0 score of 8.3 with AV:A correctly reflects that exploitation requires adjacent network access to the proxy - typically the same Docker bridge network, subnet, or host - which meaningfully constrains the attack surface relative to an internet-exposed service. The VC:H and SC:H ratings are well-justified: any unauthenticated party on the adjacent network can exfiltrate entire container filesystems, a severe confidentiality breach affecting both the proxy system and downstream Docker containers. There is no integrity or availability impact (VI:N, VA:N, SI:N, SA:N). With PR:N and AC:L, exploitation requires no credentials and no special setup beyond an HTTP client and a reachable proxy port. No EPSS score is present in the provided data. No CISA KEV listing confirms active exploitation. The referenced GitHub gist has not been independently confirmed as functional exploit code, so exploitation status is currently 'no public exploit identified at time of analysis.' Despite the absence of KEV, the triviality of exploitation - a plain GET request - and the severity of information exposure make this a genuine remediation priority for any team where the CONTAINERS flag is enabled, not merely a paper-high CVSS score. The AV:A constraint is the primary real-world limiting factor; environments where the proxy port is reachable only from tightly controlled internal services face substantially lower practical risk.

An attacker with access to the Docker network where docker-socket-proxy is listening issues a GET request to /containers/{id}/export using a standard HTTP client such as curl. Because CONTAINERS=1 grants namespace-level access, the proxy forwards the request to the Docker daemon unimpeded and returns the container's full filesystem as a tar archive, exposing application secrets, environment variables, private keys, and configuration files. No credentials, exploit framework, or vulnerability-specific tooling are required.