Docker Compose versions prior to 2.40.2 contain a high-severity path traversal vulnerability that allows arbitrary file overwrite and remote code execution on the host system. CVE-2025-62725 carries a CVSS score of 8.9, but the exploitation vector is worse than the score suggests. Attackers can trigger it through commands that operators assume are safe and read-only, like docker compose ps or docker compose config. The vulnerability becomes exploitable when your environment consumes remote OCI-based compose artifacts from registries, internal catalogs, or upstream templates. That includes CI pipelines, developer laptops, and cloud dev workspaces.

Production CI runners, engineer workstations, and staging infrastructure are exposed right now if they run Compose builds below 2.40.2 and touch remote compose definitions. The attack surface is wherever you pull compose configuration from anywhere other than verified local files.

Root cause: trusted annotations become attack primitives

Docker Compose supports remote OCI compose artifacts as an alternative to local compose.yaml files. Instead of storing compose definitions on disk, teams can reference them as OCI artifacts in container registries. The artifact format uses OCI annotations to specify metadata: com.docker.compose.file for the compose file path, com.docker.compose.envfile for environment file paths, and com.docker.compose.extends for extends references.

Vulnerable Compose versions trust these annotation values without path validation. When resolving a remote OCI artifact, Compose extracts the path from the annotation, joins it with the local cache directory, and writes artifact content to that computed location. An attacker crafts annotations containing path traversal sequences like ../../../, causing Compose to escape the cache boundary and overwrite arbitrary files within the permissions of the invoking user. The trust model assumption was that OCI artifact metadata is safe because it comes from a registry you control. That assumption breaks when registries are compromised, when you pull from public catalogs without verification, or when supply chain poisoning occurs upstream.

Exploitation chain: file write to full system access

Arbitrary file write becomes remote code execution through standard post-exploitation techniques. Overwriting ~/.ssh/authorized_keys grants persistent SSH access by injecting attacker-controlled public keys. Shell configuration files like ~/.bashrc, ~/.profile, or ~/.zshrc execute malicious commands on next login or shell spawn. Systemd user units and cron jobs provide scheduled or boot-time code execution.

On systems where Compose runs with elevated privileges, attackers can overwrite system binaries, Docker daemon configuration, or the Compose binary itself. Replacing docker-compose with a trojanized wrapper maintains functionality while executing hidden payloads. Production nodes face this risk, but higher-probability targets are developer workstations, CI runners, and cloud dev environments that routinely pull remote compose artifacts from internal catalogs, public templates, or shared infrastructure repositories. CI runners are particularly valuable because they often have write access to code repositories, artifact registries, and deployment credentials.

Attack surface: CI pipelines and supply chain poisoning

Exploitation is a supply-chain issue, not a perimeter breach. Attackers position malicious OCI compose artifacts where victim systems consume them. A compromised internal registry serving artifacts to CI pipelines allows artifact replacement or injection. Pipelines referencing these artifacts by tag or digest pull the poisoned version. The pipeline runs docker compose config or docker compose up as part of its build or test workflow, triggering the path traversal and compromising the CI runner. From there, the attacker has access to build artifacts, deployment credentials, and potentially the ability to inject malicious code into production deployments.

Public templates and starter projects amplify reach. Developers copy-paste docker compose commands from blogs, documentation, and GitHub repositories. Commands like docker compose --file oci://example.com/starter/webapp:latest config appear to perform read-only inspection but download and process malicious artifacts, overwriting files on developer workstations. The user believes they are inspecting a compose file. Instead, Compose downloads the artifact, processes the malicious annotations, and overwrites files on their workstation.

Internal infrastructure-as-code repositories containing a single malicious OCI reference expose every downstream team. Many organizations maintain internal repositories of compose files, terraform modules, and deployment templates that teams consume as building blocks. If a malicious OCI compose artifact reference is committed to one of these repositories, every team pulling from it becomes exposed. This is particularly dangerous in organizations with automated pull mechanisms or CI jobs that periodically refresh template dependencies.

Scope: all platforms, all distribution channels

All Docker Compose versions before 2.40.2 are vulnerable across Linux, macOS, and Windows. This includes standalone binaries, Compose bundled with Docker Desktop, and Compose installed via system package managers. The vulnerability exists in the Compose codebase itself, so distribution method does not matter.

Downstream Linux distributions may not have adopted 2.40.2 yet. Systems reporting "up to date" via apt, yum, or dnf do not guarantee patched versions. Verify actual version with docker compose version and confirm output shows 2.40.2 or higher. Containerized CI runners using older base images remain vulnerable independent of host Compose version. Hardened container images and minimal base images often lag behind upstream releases, so container-based CI runners using older images remain vulnerable even if the host Compose binary is patched. Docker Desktop users must upgrade to releases bundling Compose 2.40.2 or later.

Detection: version inventory and file integrity monitoring

Start with version inventory. Identify every location where Docker Compose is installed: developer workstations, CI/CD runners, staging servers, production nodes, and any containerized build environments. Query the installed version with docker compose version and flag anything reporting less than 2.40.2. Do not rely on package manager metadata; check the actual binary version.

For containerized environments, inspect base images and build containers. Many CI systems use Docker-in-Docker or bind-mount the host Docker socket. These containers may have their own Compose installations that are independent of the host version. Extract the Compose binary from running containers or image layers and verify its version.

Review CI pipeline definitions, compose files, and infrastructure repositories for remote OCI artifact references. Search for oci:// URI schemes, registry URLs in compose contexts, and workflows pulling definitions from external sources. Identify registry trust levels: public registries and those with weak access controls represent higher risk.

Monitor file modifications on high-value targets: ~/.ssh/authorized_keys, shell RC files, systemd units, cron jobs, Docker and Compose binaries. Correlate modification timestamps with Compose invocations in shell history, CI logs, and system audit trails. File changes shortly after Compose commands resolving remote artifacts indicate potential exploitation. Check Docker and Compose cache directories for unexpected content. Compose stores downloaded OCI artifacts in its cache, typically under ~/.docker/compose or similar paths depending on the platform. Traversal exploitation may leave artifacts or temporary files in unexpected locations outside the cache directory.

Remediation: patch, restrict, monitor

The primary fix is upgrading Docker Compose to version 2.40.2 or later. This release includes path validation logic that prevents traversal sequences from escaping the cache directory. Download the fixed version from Docker's official release page or upgrade Docker Desktop to a build that includes Compose 2.40.2 or higher. Verify the upgrade with docker compose version after installation.

For environments where immediate upgrade is not feasible, operational mitigations reduce exposure while patching is in progress. The most effective mitigation is disabling or restricting the use of remote OCI compose artifacts. If your workflows do not require OCI-based compose definitions, remove or comment out any references to oci:// URIs and external registries from compose files and CI pipeline definitions. This eliminates the attack surface entirely.

If remote OCI compose artifacts are necessary, enforce a whitelist of trusted registries. Configure network policies, firewall rules, or Compose-level restrictions to prevent resolution of artifacts from untrusted sources. Internal registries with strong access controls and audit logging are preferable to public registries. Implement integrity verification for OCI artifacts using cryptographic signatures or digest pinning to ensure artifacts have not been tampered with.

Run Docker Compose as a non-privileged user. Many CI pipelines and automation workflows run Compose as root or with unnecessary elevated privileges. Restrict Compose execution to dedicated service accounts with minimal file system permissions. This limits the scope of file overwrites an attacker can achieve even if exploitation succeeds. On developer workstations, avoid running Compose with sudo unless absolutely required.

Add monitoring and alerting around critical files. Implement file integrity monitoring for authorized_keys, shell RC files, systemd units, cron jobs, and Docker or Compose binaries. Configure alerts to trigger when these files are modified, especially if modifications occur outside of scheduled maintenance or deployment windows. Correlate alerts with Compose invocation logs to identify potential exploitation attempts.

For organizations with large-scale infrastructure, automated patching and configuration management are necessary. Use tools like Ansible, Chef, or Puppet to push Compose 2.40.2 or higher to all managed nodes. Update base container images used in CI pipelines to include the patched Compose version. Schedule scans to verify installed versions and flag systems that fall out of compliance.

  • Inventory: Locate every place where Docker Compose runs, including developer machines, CI runners, and production hosts. Record the installed version using docker compose version and flag any installation reporting less than 2.40.2 as vulnerable.
  • Patch: Upgrade Docker Compose to 2.40.2 or later on all systems. Update Docker Desktop to the latest version on macOS and Windows to receive the bundled Compose fix. Verify the upgrade was successful by checking the version output.
  • Restrict: Disable or restrict the use of remote OCI compose artifacts from untrusted registries. Enforce a whitelist of trusted internal registries for compose sources. Codify these restrictions in platform guardrails, CI pipeline templates, and internal documentation to prevent reintroduction of vulnerable patterns.
  • Monitor: Implement file integrity monitoring on SSH keys, shell configurations, systemd units, and binaries. Configure alerts for unexpected modifications and correlate them with Compose execution logs to detect exploitation attempts.

If you run mission-critical container workloads and need vulnerability remediation executed as controlled operational changes with validation and documented rollback paths, ENGINYRING Virtual Servers include expert-level configuration and hardening as managed service.

Source & Attribution

This article is based on original data belonging to ENGINYRING.COM blog. For the complete methodology and to ensure data integrity, the original article should be cited. The canonical source is available at: CVE-2025-62725: How a 'Read-Only' Docker Compose Command Can Compromise Your Host.