RCE non authentifiée dans la sandbox du OpenHands Software Agent SDK (CVE-2026-112346)

Résumé (TL;DR)

• OpenHands Software Agent SDK exécute un agent dans un espace de travail. Son serveur d’agent est le service HTTP et WebSocket qui exécute les commandes et les opérations sur les fichiers ; un lanceur d’espace de travail, DockerWorkspace ou ApptainerWorkspace, démarre ce service. Le lanceur Docker du SDK OpenHands Software Agent publie le port du serveur d'agent de la sandbox sur toutes les interfaces de l'hôte, et son lanceur Apptainer lie le serveur à 0.0.0.0 directement sur l'hôte. Une liste vide de clés d'API de session désactive l'authentification par défaut. Tout hôte capable d'atteindre le port peut envoyer des requêtes HTTP ou WebSocket non authentifiées qui exécutent des commandes shell arbitraires en root dans la sandbox. Cela inclut un conteneur sur un réseau Docker partagé, une machine du réseau local ou un client sur Internet lorsque l'hôte est exposé.
• Toutes les versions d'openhands-sdk antérieures à 1.52.0 sont concernées. Au moment de la rédaction, le paquet comptait 604 050 téléchargements sur PyPI au cours de la dernière semaine.
• VulnCheck, qui a attribué et publié la CVE, la classe Critique, avec un score CVSS v3.1 de 9,8 et CVSS v4.0 de 9,3, CWE-1327 (liaison à une adresse IP sans restriction), et crédite mil4n. Aucune exploitation n'est connue et aucune preuve de concept publique n'existe.
• Pour Docker, mettez à jour vers openhands-sdk 1.52.0 ou une version ultérieure, publiée le 5 octobre 2026, recréez chaque conteneur de sandbox et vérifiez que le port n'est plus publié que sur 127.0.0.1. Pour les déploiements plus anciens, bloquez l'accès réseau au port.
• La version 1.52.0 ne change rien pour Apptainer, qui se lie toujours à 0.0.0.0 : définissez SESSION_API_KEY (laissez OH_SESSION_API_KEYS_0 non définie, ou donnez la même valeur aux deux) et gardez le port hors des réseaux non fiables. Sur Docker avant 1.52.0, définir une clé protège le serveur mais casse la session du SDK ; mettez à jour pour rétablir un usage authentifié.

Suis-je concerné ?

Vous êtes concerné si vous utilisez openhands-sdk avec le lanceur DockerWorkspace dans une version antérieure à 1.52.0 ou avec le lanceur ApptainerWorkspace, si aucune clé d'API de session n'est définie et si le port de la sandbox est accessible depuis un réseau auquel vous ne faites pas entièrement confiance. La plage de versions de l'avis s'arrête avant 1.52.0, mais le lanceur Apptainer se lie toujours à 0.0.0.0 en 1.52.0. Les trois conditions doivent être réunies :

• Votre code ou votre plateforme utilise le SDK OpenHands Software Agent, paquet openhands-sdk, et le pilote avec le lanceur DockerWorkspace dans une version antérieure à 1.52.0, ou avec le lanceur ApptainerWorkspace, que la version 1.52.0 ne modifie pas.
• Aucune clé d'API de session n'est configurée, ce qui est le cas par défaut : ni SESSION_API_KEY ni OH_SESSION_API_KEYS_0 ne sont définies dans l'environnement depuis lequel le SDK est lancé, donc la liste session_api_keys du serveur est vide et l'authentification est désactivée.
• Le port publié est accessible à des acteurs auxquels vous ne faites pas entièrement confiance. Le lanceur antérieur au correctif le publie sur toutes les interfaces de l'hôte, ce qui inclut les autres conteneurs d'un réseau bridge Docker partagé, toute machine du réseau local de l'hôte et Internet si l'hôte a une adresse publique et aucun pare-feu bloquant.

Vérifiez ce que vous exécutez et où le port a été publié :

python -c "from importlib.metadata import version; print(version('openhands-sdk'))" 2>/dev/null || echo 'openhands-sdk not installed in this interpreter'
docker ps --format '{{.Names}}  {{.Ports}}' | grep -E 'agent-server|->8000/tcp'
# Run where the SDK starts; report presence without printing secret values.
python - <<'PYKEYS'
import os
for name in ("SESSION_API_KEY", "OH_SESSION_API_KEYS_0"):
    print(name + ": " + ("set" if os.environ.get(name) else "unset or empty"))
PYKEYS

Dans la sortie de docker ps, une sandbox antérieure au correctif affiche une ligne de publication comme 0.0.0.0:31245->8000/tcp, c'est-à-dire toutes les interfaces, alors que le lanceur corrigé affiche 127.0.0.1:31245->8000/tcp. La commande Docker run du lanceur nomme chaque conteneur agent-server-<uuid>.

Comment corriger la vulnérabilité ?

DockerWorkspace : mettez à jour le SDK, puis recréez chaque conteneur de sandbox, car le conteneur en cours d'exécution conserve son ancien mappage de port jusqu'à ce qu'il soit recréé :

python -m pip install --upgrade 'openhands-sdk>=1.52.0'

Terminez ensuite chaque session de sandbox en cours et démarrez-en une nouvelle, afin que le lanceur mis à jour crée un nouveau conteneur avec le nouveau mappage de port (un simple docker restart conserve l'ancien mappage), puis vérifiez la nouvelle adresse de publication avec docker ps. Le client du lanceur Docker corrigé lit OH_SESSION_API_KEYS_0 dans l'environnement du processus du SDK, avec SESSION_API_KEY comme valeur de repli. Cela correspond à la sélection de clé du serveur, donc les requêtes du SDK portent la clé configurée.

ApptainerWorkspace : la version 1.52.0 ne modifie pas la liaison du lanceur à 0.0.0.0, donc la mise à jour seule laisse le port exposé. Configurez la clé de session et isolez le port comme décrit ci-dessous.

Si vous ne pouvez pas encore mettre à jour, ou si vous utilisez Apptainer, restreignez l'accès réseau et configurez l'authentification. Les limites propres à chaque lanceur sont les suivantes :

• Bloquez le port : une règle de pare-feu de l'hôte ou une règle de la chaîne Docker DOCKER-USER qui rejette le trafic non local vers les ports de la sandbox ferme le chemin distant, mais le port reste lié sur toutes les interfaces, et tout processus ou conteneur qui peut encore l'atteindre dispose de l'API complète sans authentification.
• Configurez l'authentification : exécutez export SESSION_API_KEY="$(openssl rand -hex 32)" dans l'environnement à partir duquel le processus du SDK démarre, avant son démarrage ; le lanceur transmet la clé et le serveur l'impose. Une session de sandbox déjà en cours conserve son serveur sans clé, démarrez donc une nouvelle session.
• Apptainer : son client lit SESSION_API_KEY, y compris en v1.52.0. Définissez cette variable et laissez OH_SESSION_API_KEYS_0 non définie, ou donnez la même valeur aux deux, afin que le client et le serveur concordent.
• Docker avant 1.52.0 : le client code sa clé en dur à None. Définir l'une ou l'autre variable de clé protège le serveur mais casse la session du SDK ; utilisez cette mesure comme confinement temporaire et mettez à jour pour rétablir la session.

Quelle est la cause racine ?

Le lanceur publiait le port de la sandbox sur toutes les interfaces de l'hôte sans configurer de clé de session, tout en remplaçant explicitement le comportement par défaut sûr du serveur d'agent, qui se lie à l'interface de loopback lorsqu'aucune clé n'est définie.

Le code vulnérable se trouve dans openhands-workspace/openhands/workspace/docker/workspace.py du SDK en version 1.51.0. Le lanceur construit la commande Docker run qui démarre la sandbox et son serveur d'agent :

ports = ["-p", f"{self.host_port}:8000"]        # line 218
if self.extra_ports:
    ports += [
        "-p",
        f"{self.host_port + 1}:8001",  # VSCode   # line 222
    ]

L'option -p de Docker publie un port du conteneur sur l'hôte. Sans adresse IP d'hôte dans la spécification, comme ici, l'adresse de publication est 0.0.0.0 : toutes les interfaces de l'hôte. Lorsque extra_ports est activé, ce qui n'est pas le cas par défaut, le lanceur publiait aussi le port VS Code 8001 sur host_port + 1 sans adresse IP d'hôte, si bien que ce second port se trouvait lui aussi sur toutes les interfaces. Plus loin dans la même commande run, le lanceur transmet explicitement au serveur d'agent son adresse d'écoute :

run_cmd = [
    "docker", "run", "-d", "--platform", self.platform, "--rm",
    ...
    image,
    "--host",
    "0.0.0.0",                                    # line 248-250
    "--port",
    "8000",
]

À l'intérieur du conteneur, la liaison à 0.0.0.0 est nécessaire à la redirection de port. L'exposition dépend de l'endroit où atterrit la publication côté hôte, et il s'agit de toutes les interfaces. L'authentification constitue la seconde moitié du problème. Une fois le conteneur démarré, le lanceur configure le propre client du SDK pour le workspace :

if not self.host:
    object.__setattr__(self, "host", f"http://127.0.0.1:{self.host_port}")
object.__setattr__(self, "api_key", None)          # line 272

Clé du client : la clé du client Docker est codée en dur à None. Par ailleurs, le lanceur transmet au conteneur les éventuelles variables d'environnement de clé de session, que seul le serveur lit ; le client du SDK lui-même ne récupère jamais la clé.

Configuration transmise : la description du champ forward_env du lanceur Docker lui-même explique que ces variables permettent au serveur d'authentifier les requêtes lorsqu'il écoute sur 0.0.0.0.

Comportement par défaut du serveur : sans variable de clé configurée, la liste session_api_keys du serveur est vide. L'enregistrement CVE identifie ce comportement par défaut comme désactivant l'authentification.

Le comportement par défaut sûr du serveur d'agent a été introduit en juillet 2026 : la pull request #4180, « fix(agent-server): default bind host to loopback without a session API key », a fait en sorte qu'un serveur sans clé se lie à l'interface de loopback. Le --host 0.0.0.0 explicite du lanceur remplace ce comportement par défaut, ce qui explique pourquoi le correctif a dû modifier le lanceur plutôt que le serveur.

Comment la vulnérabilité est-elle exploitée ?

Tout client qui atteint le port peut exécuter des commandes shell en root dans la sandbox avec de simples requêtes d'API non authentifiées. Aucun code d'exploit n'est public. Pour tester l'exposition sans payload, exécutez curl -s -o /dev/null -w '%{http_code}\n' http://<sandbox-host>:<port>/api/conversations/count depuis la position réseau que vous voulez vérifier : 200 signifie que l'API répond sans clé, 401 qu'une clé de session est imposée, et 000 que le port n'est pas joignable depuis cette position. Le chemin d'attaque tiré de l'enregistrement CVE et du code source comporte quatre étapes :

1. L'attaquant peut atteindre l'hôte sur le port publié : par exemple un conteneur sur le même réseau bridge Docker que l'hôte de la sandbox, une machine du réseau local, ou n'importe quel hôte sur Internet si la machine est exposée et non filtrée.
2. L'attaquant envoie une requête HTTP ou WebSocket à l'API du serveur d'agent. Aucune clé n'est requise, car le serveur a été démarré avec une liste session_api_keys vide.
3. Le serveur exécute la commande shell demandée en root dans le conteneur de la sandbox et renvoie tout ce que la commande affiche.
4. Au-delà de l'exécution de commandes, la même API donne accès au répertoire du workspace monté et au magasin de secrets, et l'enregistrement CVE indique que les secrets sont lus en clair.

Rien dans la chaîne ne nécessite de vulnérabilité dans la requête elle-même : l'API est celle du SDK, conçue pour être utilisée par l'agent, et elle est simplement à l'écoute de n'importe qui.

Comment se déroule l'attaque ?

Une requête non authentifiée vers un port publié par erreur devient une exécution de commandes en root dans la propre sandbox de l'agent, avec le workspace et le magasin de secrets associés.

Que peut faire un attaquant ?

Le rayon d'impact se limite au conteneur de la sandbox et aux données qui y sont montées. Selon l'enregistrement CVE, un attaquant peut exécuter des commandes shell arbitraires en root dans le conteneur de la sandbox, accéder au workspace monté sur lequel travaille l'agent et lire en clair les secrets du magasin de secrets que le SDK provisionne pour la session. Il s'agit de l'ensemble de travail de l'agent : le dépôt ou le répertoire qu'il modifie, les identifiants de son magasin de secrets et tout ce que la session a monté par ailleurs. Deux conditions doivent être réunies :

• L'accessibilité réseau du port publié, que le lanceur antérieur au correctif ouvre sur toutes les interfaces ; aucune authentification, aucune interaction utilisateur et aucun privilège au-delà d'une position sur le réseau.
• Un déploiement qui n'a jamais configuré de clé de session, ce qui est le comportement par défaut du SDK.

Pourquoi le correctif fonctionne-t-il ?

Le correctif est le commit 7b66584, fusionné via la pull request #5209 (« fix(workspace): publish Docker ports on loopback ») le 3 octobre 2026. Il a été publié dans la v1.52.0 le 5 octobre et traite à la fois l'adresse de publication Docker et la recherche de clé du client :

-        ports = ["-p", f"{self.host_port}:8000"]
+        ports = ["-p", f"127.0.0.1:{self.host_port}:8000"]
         if self.extra_ports:
             ports += [
                 "-p",
-                f"{self.host_port + 1}:8001",  # VSCode
+                f"127.0.0.1:{self.host_port + 1}:8001",  # VSCode

-        object.__setattr__(self, "api_key", None)
+        session_api_key = os.environ.get(
+            "OH_SESSION_API_KEYS_0", os.environ.get("SESSION_API_KEY")
+        )
+        object.__setattr__(self, "api_key", session_api_key)

La publication se fait désormais uniquement sur l'interface de loopback, de sorte qu'aucun autre hôte du réseau ne peut atteindre le port, et le port VS Code suit la même règle. C'est le compromis : un client situé sur une autre machine ne peut plus se connecter directement aux ports publiés. La pull request présente le changement comme un moyen de garder le comportement réseau par défaut local à la machine, puisque le client du SDK se connecte déjà via 127.0.0.1. Le serveur à l'intérieur du conteneur se lie toujours à 0.0.0.0, ce que vérifie le test de non-régression du correctif lui-même : la liaison interne au conteneur est nécessaire à la redirection de Docker, et l'adresse de publication côté hôte constitue la frontière.

Le client résout désormais la même clé que celle acceptée par le serveur, en privilégiant la variable actuelle OH_SESSION_API_KEYS_0 avec l'ancienne SESSION_API_KEY comme valeur de repli, de sorte qu'une clé configurée authentifie les deux sens et pas seulement les vérifications entrantes du serveur.

Le correctif modifie le lanceur Docker, et ses tests couvrent la publication sur loopback et la recherche de clé du client. L'avis de sécurité cite aussi Apptainer, mais son lanceur passe toujours --host 0.0.0.0 en v1.52.0.

Pour Apptainer, le correctif ne change rien : le lanceur exécute le serveur d'agent directement sur l'hôte avec --host 0.0.0.0, en 1.52.0 comme avant, donc le port écoute sur toutes les interfaces. La mesure de confinement est celle de la section sur le correctif : une clé de session et l'isolement réseau. Le serveur écoute sur le host_port de l'espace de travail, un port libre entre 30000 et 39999 si vous n'en fixez pas. Exécutez ss -ltn | grep ':<port> ' sur l'hôte pour voir s'il écoute sur 0.0.0.0, puis nc -vz <host> <port> depuis une machine qui ne devrait pas l'atteindre : si la connexion réussit, le port est exposé et seuls le pare-feu et la clé le protègent.

Comment vérifier si j'ai été compromis ?

Aucun indicateur de compromission n'a été publié pour cette faille et aucune exploitation n'est connue, il n'existe donc pas de liste d'IOC à rechercher. Voici ce que vous pouvez vérifier sur un déploiement qui a exécuté une sandbox antérieure à 1.52.0 avec un port accessible :

• Le mappage de port (docker ps --format '{{.Names}} {{.Ports}}') : une sandbox antérieure au correctif affiche 0.0.0.0: dans la ligne de publication, ce qui confirme que le port était publié sur toutes les interfaces. C'est la moitié de la condition d'exposition : vos règles de pare-feu et votre chemin réseau déterminent si un acteur non fiable pouvait l'atteindre.
• Les journaux du conteneur de la sandbox, à la recherche de requêtes HTTP ou WebSocket qui ne correspondent pas à l'activité de vos sessions d'agent, puisque le serveur d'agent journalise les requêtes qu'il traite.
• Le contenu de votre magasin de secrets, pour tout ce que la sandbox pouvait atteindre : considérez chaque secret provisionné pour une sandbox exposée comme divulgué, renouvelez-le et reconstruisez le conteneur à partir d'une image saine.

Si la condition d'exposition n'a jamais été remplie, parce que le port était bloqué par un pare-feu ou que l'hôte n'avait aucun chemin réseau non fiable, le risque pratique était quasi nul, et appliquer le correctif selon votre calendrier habituel suffit.

Chronologie

• 23 juillet 2026 : le serveur d'agent obtient son comportement par défaut sûr, la liaison à l'interface de loopback lorsqu'aucune clé d'API de session n'est définie, dans la pull request #4180.
• 3 octobre 2026 : la pull request #5209, « fix(workspace): publish Docker ports on loopback », est fusionnée sous le commit 7b66584.
• 5 octobre 2026 : la v1.52.0 est publiée ; son journal des modifications mentionne le correctif par son titre sans le présenter comme un correctif de sécurité, et aucun avis de sécurité n'est publié.
• 26 octobre 2026 : VulnCheck publie la CVE-2026-112346, CVSS v3.1 9,8 et v4.0 9,3, CWE-1327, en créditant mil4n, avec la plage concernée avant 1.52.0.
• 26 octobre 2026 : la base de données d'avis de sécurité de GitHub synchronise l'enregistrement sous GHSA-rp7h-crm7-h5qj.
• 27 octobre 2026 : publication de cet article.

FAQ

La plateforme OpenHands principale partage-t-elle cette faille ?

L'avis de sécurité couvre les lanceurs DockerWorkspace et ApptainerWorkspace du SDK, qu'utilisent les sessions locales du SDK. L'avis n'établit pas si la plateforme OpenHands hébergée ou un autre produit intègre ces lanceurs, les opérateurs de tout déploiement basé sur OpenHands doivent donc effectuer les mêmes vérifications : la version installée du SDK et l'adresse de publication de tout conteneur agent-server. Le motif à rechercher est un conteneur nommé agent-server-* qui publie le port 8000 sur 0.0.0.0.

Pourquoi la v1.52.0 a-t-elle été publiée sans avis de sécurité ?

Le journal des modifications de la v1.52.0 mentionne la pull request par son titre, « fix(workspace): publish Docker ports on loopback », sans la présenter comme un correctif de sécurité, et aucun avis n'a accompagné la publication. C'est pourquoi les scanners de dépendances n'avaient rien à signaler jusqu'à la parution de l'enregistrement CVE de VulnCheck le 26 octobre, et pourquoi les vérifications de version, et pas les seuls flux CVE, constituaient le signal fiable dans l'intervalle.

Une clé de session suffit-elle comme protection ?

Elle ferme le chemin d’exécution de commandes sans authentification : le serveur vérifie la clé de session sur les routes protégées des conversations, de l’exécution de commandes et de l’accès aux fichiers. Les routes publiques d’information sur le serveur ne constituent pas un test fiable de l’authentification. Elle ne déplace pas le port : un lanceur Docker antérieur à 1.52.0 publie toujours sur toutes les interfaces et son propre client ne peut pas envoyer la clé, donc la session est cassée. Un lanceur Apptainer antérieur à 1.52.0 continue de fonctionner avec SESSION_API_KEY définie, puisque son client la lit. Pour Docker, la mise à jour ajoute la publication sur loopback. Pour Apptainer, gardez le port isolé du réseau en plus de l'authentification ; la version 1.52.0 ne modifie pas son adresse de liaison.

Dois-je recréer les conteneurs en cours d'exécution ?

Oui. Le mappage de port est défini à la création du conteneur, donc une sandbox déjà en cours d'exécution conserve sa publication sur 0.0.0.0 même après la mise à jour du SDK sur l'hôte. Arrêtez et recréez chaque sandbox, puis vérifiez le nouveau mappage avec docker ps.

Pourquoi n'y a-t-il eu aucun avis pendant trois semaines après le correctif ?

L'enregistrement CVE, l'entrée GHSA et les correspondances des bases de données datent tous du 26 octobre, trois semaines après la version corrigée. Les déploiements mis à jour rapidement étaient protégés sans savoir pourquoi, et ceux qui figent leurs versions n'avaient aucun avis pour les alerter entre-temps. C'est l'argument classique en faveur d'une bonne hygiène des versions sur l'infrastructure des agents : les composants de sandbox qui se lient à des ports réseau méritent d'être suivis au niveau des versions, et pas seulement au niveau des CVE.

Où openhands-sdk est-il encore antérieur à 1.52.0 ?

Exécutez Ostorlab SCA sur vos dépôts et vos images de conteneurs pour lister tous les projets et toutes les versions publiées qui embarquent encore openhands-sdk dans une version inférieure à 1.52.0.

Références

• Enregistrement CVE-2026-112346, publié le 26 octobre 2026 par VulnCheck en tant que CNA, avec les vecteurs CVSS v3.1 9,8 et v4.0 9,3, CWE-1327, la plage concernée avant 1.52.0 et la description des deux lanceurs : https://www.cve.org/CVERecord?id=CVE-2026-112346 (consulté le 28 octobre 2026)
• GHSA-rp7h-crm7-h5qj, l'entrée de la base de données d'avis de sécurité de GitHub synchronisée à partir de l'enregistrement CVE : https://github.com/advisories/GHSA-rp7h-crm7-h5qj (consulté le 27 octobre 2026)
• Avis de VulnCheck, « OpenHands Software Agent SDK < 1.52.0 Unauthenticated Sandbox Agent Server RCE », sévérité critique, crédit mil4n : https://www.vulncheck.com/advisories/openhands-software-agent-sdk-unauthenticated-sandbox-agent-server-rce (consulté le 27 octobre 2026)
• Pull request du correctif #5209, « fix(workspace): publish Docker ports on loopback », fusionnée le 3 octobre 2026, dont la description justifie la propagation de la clé au client : https://github.com/OpenHands/software-agent-sdk/pull/5209 (consulté le 27 octobre 2026)
• Commit du correctif 7b66584ff8899144eb4ce679c2811861342af9de, le diff de la publication sur loopback et de la résolution de la clé de session : https://github.com/OpenHands/software-agent-sdk/commit/7b66584ff8899144eb4ce679c2811861342af9de (consulté le 27 octobre 2026)
• Version v1.52.0, publiée le 5 octobre 2026, qui mentionne le correctif sans le présenter comme un correctif de sécurité : https://github.com/OpenHands/software-agent-sdk/releases/tag/v1.52.0 (consulté le 27 octobre 2026)
• Code source vulnérable en v1.51.0, openhands-workspace/openhands/workspace/docker/workspace.py, lignes 89 à 95 (forward_env), 218, 222, 248 à 250 et 272 : https://github.com/OpenHands/software-agent-sdk/blob/v1.51.0/openhands-workspace/openhands/workspace/docker/workspace.py (consulté le 27 octobre 2026)
• Comportement par défaut sûr du serveur d'agent, pull request #4180, « fix(agent-server): default bind host to loopback without a session API key », fusionnée le 23 juillet 2026 : https://github.com/OpenHands/software-agent-sdk/pull/4180 (consulté le 27 octobre 2026)
• Statistiques de téléchargement PyPI pour openhands-sdk, 604 050 téléchargements au cours de la semaine consultée : https://pypistats.org/packages/openhands-sdk (consulté le 27 octobre 2026)
• Lanceur Apptainer en v1.52.0, qui conserve la liaison à 0.0.0.0 et la recherche de SESSION_API_KEY par le client : https://github.com/OpenHands/software-agent-sdk/blob/v1.52.0/openhands-workspace/openhands/workspace/apptainer/workspace.py (consulté le 28 octobre 2026)