Docker Compose powers millions of workflows, from CI/CD runners and local development stacks to cloud workspaces and enterprise build pipelines. It’s trusted by developers as the friendly layer above Docker Engine that turns a few YAML lines into a running application.
In early October 2025, while exploring Docker Compose’s new support for OCI-based Compose artifacts, I discovered a high-severity path traversal vulnerability. The flaw allowed attackers to escape Compose’s cache directory and write arbitrary files on the host system, simply by tricking a user into referencing a malicious remote artifact. The issue was patched by the Docker team and assigned CVE-2025-62725, rated High (CVSS 8.9).
We strongly recommend upgrading to Docker version v2.40.2 or later. In this post I unpack the bug, share the proof of concept, and reconstruct how exploitation would have played out in practice.
To make Compose projects more portable, Docker added support for fetching Compose files published as OCI artifacts. This allows developers to host Compose projects in registries and include them via a simple “include:” directive.
Behind the scenes, Compose fetches the OCI manifest, downloads each layer, and reconstructs the local project inside a cache directory.
Each layer can include annotations such as:
com.docker.compose.file
com.docker.compose.envfile
com.docker.compose.extends
These instruct Compose where to write the file and whether it extends the main project definition.
The vulnerable code lived in pkg/remote/oci.go, specifically inside pullComposeFiles, writeComposeFile, and writeEnvFile.
When Compose processed OCI layers it trusted the layer annotations that tell it where to write files. An attacker could set an annotation such as:

Compose then performed a literal join between its local cache directory and that annotation:

No normalization, no canonicalization, no checks that the resulting path stayed inside the cache. Because of that, a crafted annotation could traverse out of the cache directory and cause Compose to write files anywhere the Compose process had permission to write.
Most people know it’s a bad idea to run “docker compose up” on untrusted compose files. What makes this bug subtle and dangerous is that it is triggered during artifact resolution, not only when starting containers. Many seemingly “read only” commands, for example docker compose ps or docker compose config, force Compose to fetch and reconstruct remote OCI artifacts into the cache triggering the vulnerability.
To demonstrate the vulnerability, I created a minimal OCI registry that serves a malicious Compose artifact containing a path traversal layer. The registry is available here.
An attacker could exploit this by convincing a victim to run almost any Compose command, such as “docker compose ps” in a directory that includes a specially crafted docker-compose.yaml file.
Once triggered, the Docker Compose CLI would fetch the remote artifact from the attacker’s registry, inadvertently leaking the server’s IP address. It would then process the artifact’s annotations, blindly writing an additional YAML fragment outside of its cache directory.
In this proof-of-concept the payload targets ~/[.]ssh/authorized_keys, injecting the attacker’s public key and immediately granting them SSH access to the victim’s machine, even though no containers were started and no “write” operation was explicitly invoked by the user.
The Docker team’s patch introduces a validatePathInBase() function that normalizes and validates annotation-derived paths before writing, rejecting any that resolve outside the cache directory or that contain absolute paths.
We strongly recommend upgrading to Docker version v2.40.2 or later.
Docker Compose’s OCI artifact feature was built to make sharing configurations effortless, but as this case shows, any time a tool automatically reconstructs files from untrusted sources, boundaries blur.
The Docker team’s swift response and fix ensured users remain protected, but the broader takeaway for the ecosystem is clear: sanitize every path, even when “it’s just YAML.”
The post CVE-2025-62725: From “docker compose ps” to System Compromise appeared first on Blog.
*** This is a Security Bloggers Network syndicated blog from Blog authored by Ron Masas. Read the original post at: https://www.imperva.com/blog/cve-2025-62725-from-docker-compose-ps-to-system-compromise/