CVE-2026-78122 in docker-socket-proxy
Summary
by MITRE • 08/23/2026
docker-socket-proxy fails to properly gate read endpoints in the /containers Docker API namespace when the CONTAINERS environment variable is set. Attackers can use GET requests to /containers/{id}/archive, /containers/{id}/export, /containers/{id}/logs, and /containers/{id}/top to read arbitrary files and download entire container filesystems as tar archives.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/23/2026
The vulnerability in docker-socket-proxy represents a critical authorization bypass within the Docker API proxy layer, specifically affecting how access controls are enforced for container-related endpoints when specific environment variables are configured. The core technical flaw lies in the logic governing read operations under the /containers namespace of the Docker Remote API. When the CONTAINERS environment variable is set to restrict or define allowed containers, the application fails to properly gate or validate requests against this configuration for several key HTTP GET methods. This misconfiguration allows an attacker who has access to the proxy endpoint to bypass intended restrictions and interact directly with container internals in ways that were not permitted by the security policy defined via environment variables.
The operational impact of this vulnerability is severe, as it enables unauthorized data exfiltration from Docker containers without requiring elevated privileges on the host system itself. By exploiting the lack of proper gating on specific endpoints such as /containers/{id}/archive and /containers/{id}/export, an attacker can download entire container filesystems packaged as tar archives. This provides complete access to all files stored within the container's writable layers and mounted volumes, potentially exposing sensitive configuration files, source code, credentials, or proprietary data. Furthermore, the ability to utilize /containers/{id}/logs allows for the interception of application logs which may contain plaintext passwords, session tokens, or other confidential information generated during runtime operations. The endpoint /containers/{id}/top permits the enumeration and inspection of running processes within a container, aiding in reconnaissance efforts that can facilitate further lateral movement or exploitation attempts against services running inside those containers.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, as it involves a failure to enforce proper restrictions on authenticated users regarding specific API resources. It also maps closely to ATT&CK technique T1005 Data from Local System, specifically the sub-technique of data archival and exfiltration via file system access methods like tar archives. The exploitation vector is typically remote if the docker-socket-proxy is exposed over a network, or local if an attacker has compromised a container with access to the proxy socket. This scenario highlights the risks associated with exposing Docker API proxies without rigorous validation of every endpoint against defined security policies, particularly for read-heavy operations that do not modify state but allow significant data leakage.
Mitigation strategies must focus on immediate remediation and long-term architectural improvements. Administrators should immediately update docker-socket-proxy to a patched version where the access control logic correctly validates all GET requests within the /containers namespace against the CONTAINERS environment variable configuration. If an upgrade is not immediately feasible, network-level controls such as firewall rules or reverse proxy configurations should be implemented to restrict access to these specific endpoints (/archive, /export, /logs, /top) unless explicitly required by application logic. Additionally, organizations should audit their Docker API exposure practices, ensuring that proxies enforce least-privilege principles and validate all input parameters against defined allowlists rather than relying solely on environment variable settings which may have implementation gaps in edge cases. Regular security assessments of container orchestration tools are essential to identify similar authorization bypasses before they can be exploited for data theft or further system compromise.