Docker Compose Security in 2026: CVE-2025-62725 (CVSS 8.9), Secrets Exposure & Complete Hardening GuideSécurité Docker Compose en 2026 : CVE-2025-62725 (CVSS 8.9), Exposition des Secrets & Guide de Durcissement Complet

Docker Compose is the de facto tool for multi-container development and staging deployments — yet most teams treat their compose.yml as a convenience file rather than a security surface. In 2026, that assumption is costly. CVE-2025-62725 (CVSS 8.9) demonstrated that a malicious remote OCI artifact can overwrite arbitrary files on your host — including your SSH authorized keys — simply by running docker compose ps. No container needs to be started. No privileged mode required. Meanwhile CVE-2026-34040 (CVSS 8.8) allows a one-request bypass of Docker Engine's entire authorization plugin layer, and 85% of production container images still carry at least one high or critical CVE.

Docker Compose est l'outil standard pour les déploiements multi-conteneurs en développement et en staging — pourtant la plupart des équipes traitent leur compose.yml comme un fichier de commodité plutôt que comme une surface d'attaque. En 2026, cette hypothèse coûte cher. CVE-2025-62725 (CVSS 8.9) a démontré qu'un artefact OCI distant malveillant peut écraser des fichiers arbitraires sur votre hôte — y compris vos clés SSH autorisées — simplement en exécutant docker compose ps. Aucun conteneur n'a besoin d'être démarré. Aucun mode privilégié requis. Pendant ce temps, CVE-2026-34040 (CVSS 8.8) permet de contourner l'intégralité de la couche de plugin d'autorisation de Docker Engine en une seule requête, et 85% des images de conteneurs en production portent encore au moins une CVE haute ou critique.

This guide covers every major Docker Compose CVE published in 2025–2026, the most common misconfigurations that silently expose your infrastructure, and a practical hardening checklist you can apply today.

Ce guide couvre toutes les CVE majeures de Docker Compose publiées en 2025–2026, les mauvaises configurations les plus courantes qui exposent silencieusement votre infrastructure, et une checklist de durcissement pratique applicable dès aujourd'hui.

CVE-2025-62725: The Path Traversal That Triggers on docker compose ps

CVE-2025-62725 : Le Path Traversal qui se déclenche sur docker compose ps

Discovered by Imperva researchers in October 2025 and assigned CVSS 8.9, CVE-2025-62725 is a path traversal vulnerability in Docker Compose's OCI artifact caching layer. When a compose.yml references a remote OCI compose artifact, Compose fetches the artifact and uses annotations embedded in it — specifically com.docker.compose.file and com.docker.compose.envfile — to determine where to write cache files. The critical flaw: Compose performed no canonicalization or path validation on the attacker-supplied annotation values before joining them with the local cache directory path.

Découverte par les chercheurs d'Imperva en octobre 2025 et classée CVSS 8.9, CVE-2025-62725 est une vulnérabilité de path traversal dans la couche de mise en cache des artefacts OCI de Docker Compose. Quand un compose.yml référence un artefact OCI distant, Compose le récupère et utilise des annotations intégrées — spécifiquement com.docker.compose.file et com.docker.compose.envfile — pour déterminer où écrire les fichiers de cache. La faille critique : Compose n'effectuait aucune canonicalisation ni validation de chemin sur les valeurs d'annotation fournies par l'attaquant avant de les joindre au chemin du répertoire de cache local.

The exploit path is particularly alarming because it is triggered by read-only operations. Commands like docker compose ps, docker compose config, and docker compose pull all force Compose to resolve and cache remote OCI artifacts. An attacker who can serve a malicious OCI artifact at any URL referenced by a compose.yml can cause arbitrary file writes on the developer's machine. The proof-of-concept published by Imperva demonstrated injecting an attacker-controlled SSH public key into ~/.ssh/authorized_keys, immediately granting persistent SSH access to the victim's machine.

Le vecteur d'exploitation est particulièrement inquiétant car il est déclenché par des opérations en lecture seule. Des commandes comme docker compose ps, docker compose config et docker compose pull forcent toutes Compose à résoudre et mettre en cache les artefacts OCI distants. Un attaquant capable de servir un artefact OCI malveillant à n'importe quelle URL référencée par un compose.yml peut provoquer des écritures arbitraires de fichiers sur la machine du développeur. Le proof-of-concept publié par Imperva a démontré l'injection d'une clé publique SSH contrôlée par l'attaquant dans ~/.ssh/authorized_keys, accordant immédiatement un accès SSH persistant à la machine de la victime.

Affected versions: Docker Compose 2.34.0 to 2.40.1 (all platforms: Docker Desktop, standalone Linux binary, CI/CD runners, cloud dev environments). Fix: Upgrade to Compose 2.40.2 or later, which implements the validatePathInBase function to reject any annotation value containing path separators or resolving outside the expected cache base directory.

Versions affectées : Docker Compose 2.34.0 à 2.40.1 (toutes plateformes : Docker Desktop, binaire Linux standalone, runners CI/CD, environnements de développement cloud). Correctif : Mettre à jour vers Compose 2.40.2 ou supérieur, qui implémente la fonction validatePathInBase pour rejeter toute valeur d'annotation contenant des séparateurs de chemin ou se résolvant en dehors du répertoire de cache de base attendu.

# Check your Docker Compose version
docker compose version

# Should be >= 2.40.2
# Docker Desktop 4.32+ bundles a safe version
# Standalone: https://github.com/docker/compose/releases

CVE-2026-34040: One Padded Request to Bypass Docker's Entire AuthZ Layer

CVE-2026-34040 : Une Requête Rembourrée pour Contourner Toute la Couche AuthZ de Docker

Discovered by Cyera Research and patched in April 2026, CVE-2026-34040 is a high-severity vulnerability (CVSS 8.8) in Docker Engine itself. The flaw is a recurrence of CVE-2024-41110 (CVSS 10.0), the notorious zero-length body bypass that was supposed to have been patched. The 2026 variant works differently: when an API request body exceeds 1 MB, Docker's authorization middleware silently truncates the body to empty before forwarding it to authorization plugins — but continues to process the full, original request body internally.

Découverte par Cyera Research et corrigée en avril 2026, CVE-2026-34040 est une vulnérabilité de haute sévérité (CVSS 8.8) dans Docker Engine lui-même. La faille est une réoccurrence de CVE-2024-41110 (CVSS 10.0), le tristement célèbre contournement par corps vide qui était censé avoir été corrigé. La variante 2026 fonctionne différemment : lorsqu'un corps de requête API dépasse 1 Mo, le middleware d'autorisation de Docker tronque silencieusement le corps en vide avant de le transmettre aux plugins d'autorisation — mais continue de traiter le corps de la requête original complet en interne.

The practical result: an attacker with any access to the Docker socket (including from a compromised container running in default configuration) can send a single HTTP request padded beyond 1 MB to create a privileged container with full host filesystem access. The exploit bypasses security policies enforced by Docker authorization plugins like Open Policy Agent (OPA), rendering them completely ineffective. The underlying architecture flaw has existed since Docker Engine 1.10 — nearly a decade.

Le résultat pratique : un attaquant ayant n'importe quel accès au socket Docker (y compris depuis un conteneur compromis tournant en configuration par défaut) peut envoyer une seule requête HTTP rembourrée au-delà de 1 Mo pour créer un conteneur privilégié avec un accès complet au système de fichiers de l'hôte. L'exploit contourne les politiques de sécurité appliquées par les plugins d'autorisation Docker comme Open Policy Agent (OPA), les rendant complètement inefficaces. La faille architecturale sous-jacente existe depuis Docker Engine 1.10 — près d'une décennie.

Fix: Upgrade to Docker Engine 29.3.1. The patched version now enforces a hard 4 MiB limit — requests exceeding this boundary are immediately rejected before any interaction with AuthZ plugins, and the daemon returns a hard error. This closes both CVE-2024-41110 and CVE-2026-34040 at the architecture level.

Correctif : Mettre à jour vers Docker Engine 29.3.1. La version corrigée applique maintenant une limite stricte de 4 Mio — les requêtes dépassant cette limite sont immédiatement rejetées avant toute interaction avec les plugins AuthZ, et le daemon retourne une erreur stricte. Cela ferme CVE-2024-41110 et CVE-2026-34040 au niveau de l'architecture.

Other Docker CVEs to Patch in 2026

Autres CVE Docker à Corriger en 2026

Beyond the two headline vulnerabilities, two Docker Desktop CVEs affect developer machines running any platform:

Au-delà des deux vulnérabilités majeures, deux CVE Docker Desktop affectent les machines de développement sur toutes les plateformes :

• CVE-2025-9074 — Docker Desktop containers can reach the Docker Engine API at the hardcoded address 192.168.65.7:2375 without any authentication, regardless of Enhanced Container Isolation (ECI) settings. This means a compromised container could escape ECI and interact with Docker as root. Fixed in Docker Desktop 4.44.3.
• CVE-2025-9074 — Les conteneurs Docker Desktop peuvent atteindre l'API Docker Engine à l'adresse hardcodée 192.168.65.7:2375 sans authentification, quel que soit le paramétrage d'Enhanced Container Isolation (ECI). Un conteneur compromis pouvait ainsi échapper à ECI et interagir avec Docker en tant que root. Corrigé dans Docker Desktop 4.44.3.
• CVE-2026-2664 — Out-of-bounds read in the gRPC-FUSE kernel module present in the Linux VM powering Docker Desktop on Windows, Linux, and macOS. Exploitable from within a container to crash the VM or potentially escalate. Fixed in Docker Desktop 4.62.0.
• CVE-2026-2664 — Lecture hors limites dans le module noyau gRPC-FUSE présent dans la VM Linux propulsant Docker Desktop sur Windows, Linux et macOS. Exploitable depuis un conteneur pour crasher la VM ou potentiellement escalader les privilèges. Corrigé dans Docker Desktop 4.62.0.

# Ensure Docker Desktop is up to date (>= 4.62.0)
docker version

# Check Docker Engine version (>= 29.3.1)
docker info | grep "Server Version"

The Biggest Compose Misconfiguration: Secrets in Environment Variables

La Plus Grande Mauvaise Configuration Compose : Les Secrets dans les Variables d'Environnement

CVEs aside, the most widespread Docker Compose security failure is not a software vulnerability — it is a configuration mistake that developers make every day. Hardcoding API keys, database passwords, and service tokens directly in compose.yml or in a committed .env file exposes those secrets forever in Git history. Attackers actively scan GitHub for compose.yml files using dorks and automated tools, and once a secret lands in a public repo, it must be considered permanently compromised even after deletion.

Les CVE mises à part, la défaillance de sécurité Docker Compose la plus répandue n'est pas une vulnérabilité logicielle — c'est une erreur de configuration que les développeurs commettent quotidiennement. Coder en dur des clés API, des mots de passe de base de données et des tokens de services directement dans compose.yml ou dans un fichier .env versionné expose ces secrets à jamais dans l'historique Git. Les attaquants scannent activement GitHub pour les fichiers compose.yml avec des dorks et des outils automatisés, et une fois qu'un secret atterrit dans un dépôt public, il doit être considéré comme compromis de façon permanente même après suppression.

Additionally, environment variables are globally accessible to every process in a container, appear in docker inspect output, and frequently leak into application logs when errors are printed with context. Docker Compose has built-in secrets support that mounts sensitive values as files in /run/secrets/<name> — only accessible to the specific service that declares them.

De plus, les variables d'environnement sont globalement accessibles à chaque processus d'un conteneur, apparaissent dans la sortie de docker inspect, et fuient fréquemment dans les logs applicatifs lorsque des erreurs sont imprimées avec leur contexte. Docker Compose intègre le support des secrets qui monte les valeurs sensibles sous forme de fichiers dans /run/secrets/<nom> — accessibles uniquement au service spécifique qui les déclare.

# compose.yml — DO NOT do this
services:
  app:
    environment:
      DATABASE_URL: postgres://admin:s3cr3t@db:5432/myapp  # WRONG

# compose.yml — Correct approach with Docker secrets
services:
  app:
    secrets:
      - db_password
    environment:
      DB_HOST: db
      DB_USER: admin
    # In your app: read from /run/secrets/db_password

secrets:
  db_password:
    file: ./secrets/db_password.txt  # excluded from git

# .gitignore — always add these
secrets/
.env
*.env
.env.*
!.env.example

Silent Port Exposure: How Docker Bypasses Your Firewall

Exposition Silencieuse des Ports : Comment Docker Court-Circuite Votre Pare-feu

A frequently misunderstood Docker behavior: when you publish a port in compose.yml, Docker injects iptables rules that open that port to all interfaces and all source addresses — overriding firewall rules configured by ufw, nftables, or cloud security groups that operate at a higher level. This means ports: "5432:5432" on a cloud VM exposes your PostgreSQL database directly to the internet, even if your firewall dashboard says port 5432 is blocked.

Un comportement Docker fréquemment mal compris : lorsque vous publiez un port dans compose.yml, Docker injecte des règles iptables qui ouvrent ce port à toutes les interfaces et toutes les adresses sources — en contournant les règles de pare-feu configurées par ufw, nftables ou les security groups cloud qui opèrent à un niveau supérieur. Cela signifie que ports: "5432:5432" sur une VM cloud expose votre base de données PostgreSQL directement sur internet, même si votre tableau de bord pare-feu indique que le port 5432 est bloqué.

The fix is to bind ports to localhost unless they genuinely need to be public-facing:

Le correctif consiste à lier les ports à localhost sauf s'ils doivent vraiment être accessibles publiquement :

services:
  db:
    image: postgres:16-alpine
    ports:
      - "127.0.0.1:5432:5432"  # Only accessible locally
    # Better: don't publish at all, use internal network
    # expose:
    #   - "5432"

  app:
    image: myapp:latest
    ports:
      - "127.0.0.1:8080:8080"  # Nginx terminates TLS publicly
    depends_on:
      - db

networks:
  default:
    driver: bridge
    internal: false  # app can reach internet
  backend:
    driver: bridge
    internal: true   # db isolated from internet

Reducing Attack Surface: Capabilities, Read-Only Filesystems & No New Privileges

Réduire la Surface d'Attaque : Capabilities, Systèmes de Fichiers en Lecture Seule & No New Privileges

By default, Docker containers run with a set of Linux capabilities that include CAP_NET_BIND_SERVICE, CAP_CHOWN, CAP_DAC_OVERRIDE, and others that most application containers simply do not need. Dropping all capabilities and adding only what is required reduces the blast radius of a container compromise significantly. Combined with read_only: true and no-new-privileges: true, this makes privilege escalation inside a container extremely difficult.

Par défaut, les conteneurs Docker s'exécutent avec un ensemble de capabilities Linux incluant CAP_NET_BIND_SERVICE, CAP_CHOWN, CAP_DAC_OVERRIDE et d'autres dont la plupart des conteneurs d'applications n'ont tout simplement pas besoin. Supprimer toutes les capabilities et n'ajouter que celles qui sont nécessaires réduit considérablement le rayon de blast d'une compromission de conteneur. Combiné à read_only: true et no-new-privileges: true, cela rend l'escalade de privilèges à l'intérieur d'un conteneur extrêmement difficile.

services:
  app:
    image: myapp:1.2.3  # Pinned — never use 'latest'
    user: "1000:1000"   # Non-root user
    read_only: true
    tmpfs:
      - /tmp            # Writable temp dir in memory
      - /var/cache/app
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE  # Only if binding port < 1024
    security_opt:
      - no-new-privileges:true
    deploy:
      resources:
        limits:
          cpus: "0.5"
          memory: 512M

Never Mount docker.sock in Production Containers

Ne Jamais Monter docker.sock dans les Conteneurs de Production

Mounting /var/run/docker.sock inside a container is equivalent to granting root access to the host. Any code running inside that container can use the Docker socket to spawn new containers with arbitrary flags — including --privileged and bind-mounting the host filesystem. This is the standard technique used by container escape exploits. CVE-2026-34040 makes this even more dangerous: with socket access, an attacker can bypass AuthZ plugins entirely with a single padded request.

Monter /var/run/docker.sock dans un conteneur équivaut à accorder un accès root à l'hôte. Tout code s'exécutant dans ce conteneur peut utiliser le socket Docker pour lancer de nouveaux conteneurs avec des flags arbitraires — y compris --privileged et le bind-mount du système de fichiers de l'hôte. Il s'agit de la technique standard utilisée par les exploits d'échappement de conteneur. CVE-2026-34040 rend cela encore plus dangereux : avec un accès au socket, un attaquant peut contourner les plugins AuthZ entièrement avec une seule requête rembourrée.

# WRONG — Never do this in production
services:
  ci-agent:
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock  # Full host compromise

# If you need Docker-in-Docker: use rootless Docker or Kaniko
# For CI builds: use a dedicated build service, not socket mounting

Image Pinning: Why latest Is a Security Risk

Verrouillage des Images : Pourquoi latest Est un Risque de Sécurité

Using image: nginx:latest or image: node:latest in a production compose.yml means your next docker compose pull could silently replace your running image with a new version that contains breaking changes, regressions, or — in a supply chain attack scenario — malicious code. Pinning to a specific version (nginx:1.27.4-alpine) or, better yet, to a digest (nginx@sha256:abc123...) ensures that only the exact image you reviewed runs in production.

Utiliser image: nginx:latest ou image: node:latest dans un compose.yml de production signifie que votre prochain docker compose pull pourrait silencieusement remplacer votre image en cours d'exécution par une nouvelle version contenant des changements rupturants, des régressions ou — dans un scénario d'attaque supply chain — du code malveillant. Verrouiller sur une version spécifique (nginx:1.27.4-alpine) ou, mieux encore, sur un digest (nginx@sha256:abc123...) garantit que seule l'image exacte que vous avez examinée s'exécute en production.

# Get the digest of an image you trust
docker inspect --format='{{index .RepoDigests 0}}' nginx:1.27.4-alpine

# Use digest pinning in compose.yml
# image: nginx@sha256:a45e0e98ac0e9ed3e2b3d2e5b74ac5fcf32849a6e3e9fc1b8c52a8e4fd7d3b9c

# Scan your images for known CVEs before pinning
docker scout cves nginx:1.27.4-alpine

Docker Compose Security Hardening Checklist (2026)

Checklist de Durcissement Sécurité Docker Compose (2026)

Apply these controls to every production compose.yml:

Appliquez ces contrôles à chaque compose.yml de production :

A Secure Docker Compose Template for 2026

Un Template Docker Compose Sécurisé pour 2026

The following example brings all the controls above together into a production-ready template:

L'exemple suivant rassemble tous les contrôles ci-dessus dans un template prêt pour la production :

services:
  app:
    image: myapp:1.2.3-alpine  # Pinned version, no 'latest'
    user: "1000:1000"
    read_only: true
    tmpfs:
      - /tmp:size=64m
      - /var/cache/app:size=128m
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    ports:
      - "127.0.0.1:8080:8080"
    secrets:
      - db_password
      - api_key
    environment:
      DB_HOST: db
      DB_USER: appuser
      # Password comes from /run/secrets/db_password
    networks:
      - frontend
      - backend
    depends_on:
      db:
        condition: service_healthy
    deploy:
      resources:
        limits:
          cpus: "1.0"
          memory: 512M
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/health"]
      interval: 30s
      timeout: 5s
      retries: 3
    restart: unless-stopped

  db:
    image: postgres:16.4-alpine  # Pinned
    user: "999:999"
    read_only: true
    tmpfs:
      - /tmp
      - /var/run/postgresql
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    # No 'ports:' — DB only accessible inside backend network
    expose:
      - "5432"
    secrets:
      - db_password
    environment:
      POSTGRES_USER: appuser
      POSTGRES_DB: myapp
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    networks:
      - backend
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U appuser -d myapp"]
      interval: 10s
      timeout: 3s
      retries: 5
    restart: unless-stopped

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge
    internal: true  # No internet access for DB

volumes:
  db_data:
    driver: local

secrets:
  db_password:
    file: ./secrets/db_password.txt  # In .gitignore
  api_key:
    file: ./secrets/api_key.txt

Frequently Asked Questions

Questions Fréquentes