Loading story…
A security flaw in Tecnativa docker-socket-proxy allows unintended read access to container data when the proxy is configured with CONTAINERS=1, even if POST=0 is set. Public reports and a proof of concept show that the proxy's HAProxy rules broadly permit the Docker API /containers/* namespace, enabling an attacker with access behind the proxy to list containers and reach sensitive GET endpoints that were not meant to be exposed.
The exposed endpoints reportedly include /archive, /export, /logs, and /top, which can be used to read arbitrary files from containers, export full container filesystems, inspect process arguments, and retrieve logs. An open issue states there is no built-in mitigation short of manually editing the HAProxy configuration, while a linked pull request proposes restricting filesystem-related exposure through more granular controls such as ALLOW_ARCHIVE, ALLOW_EXPORT, and ALLOW_LOGS and corresponding HAProxy configuration changes.
See affected versions and whether adversaries are exploiting it.
3 events from the most recent confirmed update back to the earliest known activity.
A pull request titled "Fix: Prevent filesystem exposure when CONTAINERS=1" was opened to remediate the reported exposure in docker-socket-proxy. The proposed changes reference affected paths and introduce mitigation-related configuration controls including ALLOW_ARCHIVE, ALLOW_EXPORT, and ALLOW_LOGS.
A public proof-of-concept showed that a docker-socket-proxy deployment configured with CONTAINERS=1 and POST=0 still exposes dangerous read-only endpoints such as /archive, /export, /top, and /logs. The PoC demonstrated listing containers and reading files, exporting filesystems, viewing process arguments, and retrieving logs using only GET requests.
A security issue was reported in docker-socket-proxy stating that enabling CONTAINERS=1 allows broad access to sensitive GET-only /containers subpaths, enabling arbitrary file reads, filesystem export, process inspection, and log access across containers. The report attributes the flaw to an HAProxy prefix-match rule and proposes adding explicit deny rules and new flags such as ALLOW_EXPORT, ALLOW_ARCHIVE, and ALLOW_LOGS.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
3 references tracked. Mallory keeps watching after this page renders.
gist.github.com
Open sourcegithub.com
Open sourcegithub.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Attackers have been abusing improperly exposed Docker daemon APIs, especially unauthenticated services on port `2375`, to take control of running containers and deploy malware. One documented campaign used the Dofloo (AESDDoS) Trojan to enumerate containers and run malicious payloads with Docker commands, giving operators DDoS capability, host profiling data, and a foothold for follow-on activity such as cryptojacking or broader system compromise. Public tooling has also lowered the barrier to exploiting these weaknesses. The **BOtB** container assessment tool demonstrates how exposed Docker daemons, privileged container configurations, Kubernetes service account exposure, metadata service access, Linux kernel keyring leakage, and even `runc` escape flaw `CVE-2019-5736` can be used to break out of containers or extract secrets in CI/CD and live environments. Docker’s guidance recommends protecting the daemon socket and restricting remote API access to trusted systems, underscoring that exposed or misconfigured container management interfaces can quickly turn a single container issue into host-level compromise.
Aug 15, 2026
Docker disclosed a high-severity Docker Engine vulnerability, **CVE-2026-34040** (`CVSS 8.8`), that allows attackers to bypass authorization plugins and perform actions that should be blocked. The flaw stems from an incomplete fix for **CVE-2024-41110** and is triggered when a specially crafted oversized Docker API request causes the request body to be dropped before inspection by an AuthZ plugin. In affected environments, the plugin may approve container operations it would otherwise deny, opening a path to unauthorized privileged actions and potential host compromise. Researchers said an attacker with Docker API access could exploit the bug by padding a container-creation request beyond **1 MB** to launch a privileged container with access to the host filesystem, exposing sensitive assets such as **AWS credentials**, **SSH keys**, and **Kubernetes configurations**. The issue affects deployments that rely on authorization plugins inspecting request bodies, while environments not using those plugins are not impacted. Docker patched the vulnerability in **Docker Engine 29.3.1** and urged defenders to upgrade, restrict Docker API access, avoid AuthZ plugins that depend on request-body inspection, and use controls such as rootless mode, user namespace remapping, and least-privilege access to reduce risk.
Jul 23, 2026
Palo Alto Networks Unit 42 reported that attackers are actively targeting **unsecured Docker daemons** exposed to the internet, using the Docker API to create and run malicious containers on victim systems. By abusing misconfigured deployments that lack proper access controls, intruders can gain effective control of the underlying host, execute arbitrary workloads, and use compromised infrastructure for follow-on activity such as cryptomining, persistence, and broader cloud or network compromise. The report details attacker tradecraft focused on exposed container management interfaces, where adversaries issue Docker commands remotely to pull attacker-controlled images and launch privileged containers that can interact with the host environment. The activity highlights a recurring cloud security risk: organizations that leave Docker services reachable without authentication can enable rapid compromise of containerized environments and the systems that support them.
Jul 12, 2026