CVE-2026-78122

The CVSS 7.4 rating for CVE-2026-78122 likely understates the actual risk because this vulnerability represents a security tool failing to deliver its stated defensive function—creating a false trust condition that may have been architecturally relied upon in production deployments. Docker-socket-proxy is not a general-purpose application with a security weakness; it is a deliberate access-control layer whose entire purpose is to restrict the Docker API surface. When read endpoints like /archive and /export remain accessible under the CONTAINERS gate, the tool isn't partially failing—it is providing a security theater artifact that operators may have built dependent systems around. The /export endpoint alone allows downloading the complete filesystem of any container as a tar archive, which functionally equates to container escape and arbitrary data exfiltration. The /archive endpoint compounds this by potentially allowing reads outside the container's filesystem boundaries. The critical question is deployment context. This vulnerability carries vastly different weight depending on whether docker-socket-proxy is running as a sidecar with full socket access in a multi-tenant cluster versus a single-tenant environment. In the former case, an attacker who compromises any workload in the namespace gains filesystem extraction capability across all containers—far exceeding what a 7.4 would suggest. The CVSS metric likely treats this as a straightforward access-control bypass rather than accounting for the trust architecture this tool sits within. The semantic trap created by the CONTAINERS gate name deserves emphasis. When operators see CONTAINERS and read documentation stating it restricts container operations, they form a mental model of protection that doesn't match the implementation. The /export and /archive endpoints weren't hidden or obscure—they are well-documented Docker endpoints. This suggests the maintainers either didn't map the full CONTAINERS namespace intentionally or the variable was designed as a coarse gate that was never meant to be exhaustive. The /export endpoint is particularly severe because it functions as a credential harvesting mechanism. Container filesystems contain secrets, tokens, and keys placed there under the implicit assumption of isolation. Extraction enables lateral movement to any service those credentials authenticate to. Each step in that chain was gated by security assumptions that docker-socket-proxy was explicitly deployed to enforce. Determine whether this represents a regression from previously correct behavior or if the CONTAINERS gate never properly restricted these endpoints in any release. If it never worked, every production deployment built on this tool is operating under a structural misrepresentation—no safe version exists to point to. If it's a regression, you can identify a known-good state and a blast radius window. That distinction fundamentally changes your remediation behavior.

Reviewed through automated stages and approved by a human before publication.