Contexte et portée

Le 15 septembre 2026 Docker a publié un avis de sécurité décrivant deux vulnérabilités critiques dans Docker Sandboxes, un composant qui exécute chaque agent de codage IA dans une petite machine virtuelle. La première, CVE‑2026‑77179, affecte les versions 0.28.0 ≤ x < 0.42.0 sur macOS et obtient un score CVSS de 9.4. Elle a été corrigée dans la version 0.42.0, publiée le 7 septembre. La seconde, CVE‑2026‑79994, touche les versions 0.37.0 à 0.41.9, avec un score de 8.7, et a également été résolue dans 0.42.0.

Aucune exploitation n’a été signalée et la CISA ne répertorie pas ces CVE dans son catalogue KEV, ce qui indique que la menace reste théorique tant qu’un code malveillant n’est pas introduit dans le sandbox.

Mécanisme d’évasion

Docker Sandboxes partage le répertoire du projet avec la VM via le serveur virtio‑fs. La faille CVE‑2026‑77179 provient d’une mauvaise gestion des liens symboliques (symlinks) : le serveur host suit un symlink vers un répertoire parent remplacé après la vérification du chemin. Un processus invité peut donc remplacer un répertoire du workspace par un symlink pointant hors du workspace, puis lire ou modifier n’importe quel fichier accessible à l’utilisateur qui exécute le moniteur de VM. Le code s’exécute avec les droits de ce compte hôte, ce qui équivaut à une élévation de privilèges locale.

La deuxième vulnérabilité, CVE‑2026‑79994, exploite le relais de sockets Unix. Le relais vérifie que le chemin du socket se situe dans le workspace, puis établit la connexion. Entre la vérification et la connexion, un processus invité peut remplacer un répertoire par un symlink, forçant le relais à se connecter à un socket AF_UNIX situé en dehors du workspace. Cette redirection peut exposer des données sensibles ou des capacités du système hôte, comme le bus D‑Bus.

Analyse des impacts et limites

Les deux failles reposent sur des conditions de course liées aux symlinks, un vecteur bien connu dans les systèmes de fichiers. Leur gravité provient du fait que le conteneur partage le répertoire du projet en lecture‑écriture par défaut (sbx run), offrant ainsi une surface d’attaque directe. Cependant, l’exploitation nécessite que l’attaquant contrôle le code exécuté à l’intérieur du sandbox – typiquement un agent IA compromis ou un script malveillant installé par l’utilisateur.

Sur macOS, le modèle de permissions de Docker Sandboxes ne fournit pas de séparation de privilèges à l’intérieur de la VM ; la barrière d’isolation repose uniquement sur l’hyperviseur. Ainsi, une fois le contournement de virtio‑fs réalisé, aucune défense supplémentaire ne bloque l’accès aux fichiers du système hôte.

Mesures d’atténuation

Docker recommande de mettre à jour vers la version 0.42.0 ou supérieure (la version 0.43.0 est disponible depuis le 15 septembre). En l’absence de mise à jour, il faut activer le mode clone, qui monte le répertoire du projet en lecture‑seule (/run/sandbox/source) et empêche les écritures, tout en conservant la visibilité en lecture. Le mode clone ne protège pas la lecture de fichiers non suivis comme .env, mais réduit le risque de modification.

sbx run --clone

Enfin, les administrateurs doivent éviter les montages host‑read‑write non nécessaires et surveiller les processus invités pour détecter toute tentative de création de symlinks vers des chemins sensibles.