Le SDK OpenHands liait par défaut le port du bac à sable à toutes les interfaces, offrant une RCE root sans authentification
La CVE-2026-112346, publiée le 26 octobre 2026 et cotée CVSS 9.8, révèle que les lanceurs DockerWorkspace et Apptainer du SDK OpenHands exposaient le serveur du bac à sable sur 0.0.0.0 avec l’authentification désactivée par défaut. Passez à la version 1.52.0, qui confine le port sur la boucle locale, et vérifiez qu’aucun bac à sable n’est resté joignable depuis Internet.
26 octobre 2026. Le NVD publie la CVE-2026-112346, cotée CVSS 9.8, visant le SDK OpenHands — l’un des kits open source les plus utilisés pour construire des agents de développement assistés par IA. 5 octobre 2026. La version 1.52.0 qui corrige le défaut était déjà disponible en téléchargement. 3 octobre 2026. Le correctif, un simple changement de liaison de port, avait été fusionné dans la branche principale. Le point qui compte : pendant au moins trois semaines, toute personne qui lançait le bac à sable DockerWorkspace ou Apptainer sur une machine joignable exposait un shell root sans authentification — et la plupart des outils de suivi de vulnérabilités ne l’ont su qu’à la publication du NVD.
Le défaut : un port publié sur toutes les interfaces, avec l’authentification éteinte par défaut
OpenHands (anciennement OpenDevin) fournit un SDK d’agent logiciel qui permet de construire des agents de codage autonomes. Pour exécuter les commandes de l’agent en toute sécurité, le SDK lance un bac à sable — le plus souvent un conteneur Docker, ou Apptainer — et un serveur d’agent qui dialogue avec lui. C’est ce serveur qui exécute les commandes shell demandées par l’agent, en root, dans l’espace de travail monté.
La CVE-2026-112346 décrit précisément la faille. Les lanceurs DockerWorkspace et Apptainer publiaient le port du serveur d’agent sur 0.0.0.0 — toutes les interfaces réseau de la machine hôte — au lieu de la boucle locale. Pire, la liste session_api_keys était vide par défaut, ce qui désactivait toute authentification. Traduction opérationnelle : n’importe qui capable d’atteindre le port publié pouvait envoyer des requêtes HTTP ou WebSocket non authentifiées, exécuter des commandes shell arbitraires en root dans le bac à sable, accéder à l’espace de travail monté et lire les secrets en clair du magasin de secrets.
Le NVD classe le défaut en CWE-1327, « liaison à une adresse IP non restreinte » — la même famille que les interfaces d’administration de bases de données laissées sur 0.0.0.0. Le vecteur CVSS 3.1 est sans ambiguïté : AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Aucune condition préalable, aucune interaction utilisateur, impact maximal sur la confidentialité, l’intégrité et la disponibilité.
Qui est exposé, et qui ne l’est pas
Le risque dépend d’une seule variable : la portée réseau du port publié. Sur un poste de développeur en réseau local, derrière un NAT, l’exposition reste limitée à la machine et à ses voisins immédiats. Sur un serveur cloud, une VM avec adresse publique, ou un hôte qui publie ses ports dans un cluster partagé, la situation est radicalement différente : le serveur d’agent devient un point d’entrée root joignable depuis Internet.
La cible est d’autant plus intéressante pour un attaquant que l’espace de travail monté contient souvent le code source de l’organisation, et que le magasin de secrets sert justement à fournir à l’agent les clés d’API, jetons et identifiants dont il a besoin pour travailler. Un seul conteneur exposé combine donc exécution de code et fuite de secrets dans le même périmètre.
Le fait que session_api_keys soit vide par défaut aggrave le problème : l’utilisateur qui installe le SDK et suit le chemin « par défaut » ne fait aucun mauvais réglage. La vulnérabilité est livrée d’usine, ce qui la rend silencieuse.
Un correctif simple, fusionné avant la publication de la CVE
Le correctif est pédagogique par sa brièveté. La PR #5209, ouverte par Graham Neubig et fusionnée le 3 octobre 2026, s’intitule sobrement « publier les ports Docker sur la boucle locale ». Le changement fait deux choses : publier le port de l’API DockerWorkspace (et le port VS Code optionnel) sur 127.0.0.1 côté hôte, et propager la clé de session au client du workspace. Le serveur d’agent continue d’écouter sur 0.0.0.0 à l’intérieur du conteneur, car le transfert de port Docker doit pouvoir l’atteindre — mais la restriction de portée est appliquée côté hôte, au niveau du mapping -p.
La version 1.52.0, publiée le 5 octobre 2026, embarque ce correctif avec une couverture de régression ciblée. Le délai entre le correctif et la CVE-2026-112346, publiée le 26 octobre 2026, est le vrai sujet de cet article : pendant trois semaines, les équipes qui suivent leurs dépendances via le NVD ou le KEV n’avaient aucun signal qu’une faille critique venait d’être corrigée dans un composant qu’elles déploient. À ce jour, la CISA ne l’a pas encore inscrite au KEV, et aucun exploit public n’est référencé — mais l’absence de PoC public ne protège pas un port resté ouvert.
Ce qu’il faut faire
Mettez à niveau le SDK. Toute installation OpenHands antérieure à 1.52.0 doit être mise à jour immédiatement si elle utilise DockerWorkspace ou Apptainer. Le correctif est une montée de version, pas une reconfiguration complexe.
Vérifiez les ports publiés. Cherchez les conteneurs lancés avec -p 0.0.0.0:…:8000 ou un mapping sans restriction d’hôte, en particulier les images ghcr.io/openhands/agent-server. Un docker port <conteneur> 8000/tcp qui répond autre chose que 127.0.0.1 est un signal d’alarme.
Tournez les secrets. Si un bac à sable a pu être joint depuis Internet — par exemple sur une VM de build exposée — considérez le magasin de secrets et les clés de l’espace de travail comme compromis, et faites la rotation.
Ne laissez pas les agents exposer des ports par défaut. C’est la leçon transverse : un SDK d’agent qui publie un port sur toutes les interfaces sans authentification par défaut est un anti-pattern. Exigez de vos outils d’agent un bind loopback par défaut et une authentification activée d’office.
Verdict
Si vous déployez des agents OpenHands sur une machine joignable — VM cloud, serveur de build, nœud de cluster — mettez à niveau vers 1.52.0 sans attendre et vérifiez les mappings de ports : c’est le scénario où une RCE root sans authentification était réellement atteignable depuis Internet. Si vous n’utilisez OpenHands qu’en local, derrière un NAT, le risque est contenu mais la mise à niveau reste gratuite et recommandée. La leçon qui dépasse OpenHands est que les SDK d’agents reproduisent en accéléré les erreurs de la décennie des bases de données : liaison sur 0.0.0.0, authentification désactivée par défaut, et un correctif silencieux que les agrégateurs de CVE ne rendent visible qu’avec trois semaines de retard.