Docker Desktop : vulnérabilité use-api-socket et sécurité hôte

Origines et historique

Genèse du composant 'use-api-socket'

Docker Desktop a introduit un mécanisme d'API locale pour permettre aux extensions et aux outils tiers d'interagir plus facilement avec l'environnement de développement. Concrètement, cela se traduit par un socket local - un socket Unix sur macOS/Linux ou un Named Pipe sur Windows - qui expose des endpoints permettant de connaître l'état du service, d'exécuter certaines opérations ou d'accéder au système de fichiers selon la configuration. L'intention est positive : simplifier l'intégration des extensions et rendre l'expérience plus fluide. Mais ce type d'ouverture nécessite des garde-fous stricts. Quand la configuration est trop permissive, le bénéfice se transforme en vecteur d'attaque.

Antécédents et précédentes vulnérabilités

Les composants d'infrastructure présentant des interfaces locales ont déjà servi de vecteurs d'attaque quand l'authentification et les permissions sont insuffisantes. Des sockets exposés et mal restreints ont été exploités dans d'autres produits, et l'incident décrit par Vigilance.fr le 02/02/2026 illustre ce risque appliqué à Docker Desktop¹. Des discussions publiques et des rapports sur GitHub montrent que la communauté s'intéresse à la sécurisation de ces interfaces depuis plusieurs versions² ^³.

Chronologie succincte

02/02/2026 : découverte et démonstration publique par un chercheur, suivies d'alertes et d'analyses immédiates¹.
Réactions rapides dans les médias et parmi les mainteneurs, suivies de propositions de correctifs et de conseils de durcissement de la part de l'écosystème Docker² ^³.

Fonctionnement technique

Architecture et surface d'attaque

Docker Desktop exécute plusieurs services en arrière-plan qui peuvent exposer des interfaces locales via des sockets. L'option 'use-api-socket' interconnecte ces services et ouvre des API accessibles localement. Si aucun mécanisme d'authentification ne vérifie le contexte d'appel, un processus local malveillant peut établir une connexion et invoquer des endpoints autorisant la lecture ou l'écriture sur le système de fichiers. Le périmètre d'attaque tient donc à deux éléments simples : accès au socket et privilèges locaux suffisants.

Vecteurs d'accès possibles

Un processus malveillant démarré par un utilisateur peut utiliser le socket si ses permissions sont trop larges.
Une extension compromise peut appeler le socket pour effectuer des opérations non prévues.
Permissions de socket trop permissives, par exemple un socket accessible à des groupes larges, facilitent l'escalade.

Mécanisme d'exploitation: séquence type

Découverte du socket exposé (chemin sur Unix ou Named Pipe sur Windows).
Connexion et interrogation des endpoints disponibles, par exemple avec curl --unix-socket /path/to/socket.sock http://localhost/endpoint.
Appel d'un endpoint qui autorise la lecture ou l'écriture de fichiers.
Exfiltration de configurations, clés, tokens, ou dépôt d'un artefact pour obtenir une persistance locale.

Exemples concrets de requêtes et d'effets

Un GET /docs transmis via le socket peut retourner le contenu d'un fichier utilisateur, par exemple /Users/alice/.docker/config.json.
Un POST avec un payload bien formé peut écrire un script dans un répertoire utilisé au démarrage, ouvrant une voie de persistance.

Ces exemples ne sont pas théoriques : la capacité à lire/écrire des fichiers via des endpoints locaux est au cœur du signalement rendu public¹.

Limitations techniques et conditions requises pour l'attaque

L'attaquant doit exécuter du code sur la machine ciblée.
Des politiques de confinement telles qu'AppArmor ou SELinux, correctement configurées, réduisent fortement la surface exploitable.

Études de cas

Cas 1: Poste de développement compromis via extension mal signée

Un développeur installe une extension tierce pour l'automatisation. Une mise à jour pirate inclut un composant qui utilise le socket pour créer un script de démarrage. Conséquence : tokens Docker exposés et fuite d'images contenant des configurations sensibles. La remédiation a consisté en suppression de l'extension, rotation des tokens et reconstruction partielle des environnements concernés.

Cas 2: Exécution locale non-privée exploitant permissions de socket permissives

Sur une machine d'ingénieur, le socket était accessible au groupe 'users'. Un processus compromis par une vulnérabilité locale a interrogé le socket, lu des fichiers de configuration et écrit une backdoor. La détection a été retardée car les opérations empruntaient des endpoints légitimes. Mesures prises : correction des permissions du socket et création d'une règle EDR ciblée pour surveiller les accès à ce socket.

Cas 3: Incident signalé et réponse publique

Le rapport relayé par Vigilance.fr a documenté que l'option 'use-api-socket' a permis des accès non autorisés à des fichiers du poste hôte¹. Cette publication a déclenché une évaluation rapide et des propositions de correctifs de la part des mainteneurs Docker, mais elle souligne aussi que des contrôles initiaux plus stricts auraient évité l'exposition.

Perspectives

Mesures de durcissement recommandées

Restreindre l'accès aux sockets au strict nécessaire, par défaut et via des ACL.
Introduire une authentification forte des appels entre extensions et services, par exemple des jetons signés ou une authentification mutuelle.
Centraliser la validation des extensions et exiger des signatures vérifiables pour les mises à jour.

Évolutions de la chaîne d'outils de développement

L'augmentation des intégrations entre IDE, extensions et environnements locaux accroît la surface d'attaque. Les équipes produit doivent trouver un compromis entre ouverture et sécurité. Deux leviers concrets : autorisations fines et contrôles de sécurité automatisés lors des pipelines de livraison.

Recommandations opérationnelles pour les équipes sécurité

Inventaire rapide des postes exécutant Docker Desktop et des extensions installées. Utiliser docker info pour collecter des indicateurs de configuration.
Vérifier et corriger les permissions des sockets sur tous les postes.
Restreindre l'installation d'extensions aux versions signées et connaître la chaîne de distribution.
Déployer des règles EDR pour détecter des accès anormaux au socket et des écritures dans les répertoires de démarrage.
Mettre en place une rotation régulière des tokens et secrets.

Proposition d'action en quatre étapes :

Audit immédiat des permissions des sockets sur l'ensemble des postes impactés.
Blocage des extensions non signées et inventaire via docker plugin ls.
Déploiement d'alertes EDR pour toute activité suspecte liée au socket.
Rotation des secrets et communication aux équipes en cas de compromission suspectée.

Les sockets locaux offrent une intégration efficace, mais sans contrôles d'accès rigoureux ils deviennent une porte d'entrée. Ne laissez pas un composant d'usage quotidien se transformer en vecteur d'intrusion.

Questions fréquentes

Quels systèmes sont concernés par ce type de vulnérabilité ?

Toutes les plateformes supportant Docker Desktop peuvent être concernées, notamment Windows et macOS, car l'exposition d'une API via un socket local est un pattern commun¹.

Une mise à jour de Docker Desktop corrige-t-elle toujours ce risque ?

Une mise à jour peut corriger des vecteurs spécifiques si elle renforce les permissions du socket ou introduit une authentification des appels. Il faut cependant valider la configuration locale et appliquer des contrôles complémentaires².

Quelles preuves de compromission rechercher ?

Rechercher accès anormaux au socket (logs), créations ou modifications de fichiers dans les répertoires utilisateurs, scripts de démarrage altérés et communications réseau inhabituelles vers endpoints externes.

Les environnements CI/CD sont-ils à risque ?

Oui si des runners ou agents partagés ont accès au socket Docker Desktop. Les runners doivent être isolés et les sockets ne doivent pas être exposés entre jobs ou utilisateurs³.