OpenHands, danmu_api, MacCMS : trois failles critiques sans authentification dans l'open source auto-hébergé

Le 26 octobre 2026, VulnCheck (CNA) a déposé dans NVD trois CVE critiques visant trois projets open source que l'on installe soi-même : le SDK d'agents d'OpenHands, l'API danmu_api et le CMS vidéo MacCMS v10. Trois produits sans rapport entre eux, mais une même conséquence : un attaquant non authentifié prend la main, sur une machine dans un cas, sur une configuration ou des comptes dans les deux autres.

La plus sérieuse pour une équipe technique est celle d'OpenHands : elle touche un outil d'agent IA de développement, souvent lancé sur un poste ou un serveur de build avec des secrets à portée de main.

VulnCheck publie aussi un score CVSS 4.0 de 9.3 pour chacune. NVD n'a encore analysé aucune de ces entrées et n'y attache aucune configuration CPE. Aucune n'est au catalogue CISA KEV à la date de rédaction.

OpenHands Software Agent SDK — CVE-2026-112346

Vecteur : AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8)

OpenHands exécute ses agents dans un bac à sable : un conteneur Docker ou Apptainer dans lequel tourne un serveur d'agent qui reçoit les ordres (commandes shell, accès aux fichiers). Selon la description NVD, les lanceurs DockerWorkspace et Apptainer du SDK, dans les versions antérieures à 1.52.0 :

• lient ce serveur à toutes les interfaces réseau (0.0.0.0) ;
• avec une liste session_api_keys vide, ce qui désactive l'authentification par défaut.

Quiconque peut joindre le port publié du conteneur peut alors envoyer des requêtes HTTP et WebSocket sans authentification et :

• exécuter des commandes shell en root dans le bac à sable ;
• accéder au workspace monté, c'est-à-dire le code sur lequel l'agent travaille ;
• lire en clair les secrets du magasin de secrets.

Le bac à sable limite la casse sur l'hôte, mais pas sur ce qui compte : le code source et les secrets confiés à l'agent (jetons d'API, identifiants de dépôt…) sont précisément ce qui est exposé. Sur un poste de développeur connecté à un Wi-Fi partagé ou sur une VM cloud avec des ports ouverts, la surface est réelle.

La correction est dans la version 1.52.0 (pull request 5209), citée par les références NVD avec l'advisory VulnCheck.

C'est le même défaut que celui relevé la semaine dernière dans cinq plateformes d'agents IA auto-hébergées : un service qui exécute des commandes, ouvert au réseau, sans authentification par défaut.

danmu_api — CVE-2026-116485

Vecteur : AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8)

Avant la 1.21.7, quand le TOKEN par défaut est conservé et que ADMIN_TOKEN n'est pas défini, les routes /api/env/set, /api/env/add et /api/env/del acceptent des requêtes POST sans authentification réelle. D'après la description NVD, un attaquant peut :

• définir lui-même ADMIN_TOKEN et verrouiller les opérateurs hors de leur propre service ;
• rediriger OTHER_SERVER ou PROXY_URL vers une adresse de son choix, ce qui ouvre une SSRF ;
• déclencher un redéploiement.

MacCMS v10 — CVE-2026-116214

Vecteur : AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N (9.1)

Le parcours « mot de passe oublié » de MacCMS envoie un code de récupération, puis vérifie ce code avant de réinitialiser le mot de passe. Le défaut, selon la description : la fonction check_msg() ne compare jamais le destinataire (msg_to) du code avec le compte visé. L'attaque :

1. demander un code de récupération vers sa propre boîte via user/findpass_msg ;
2. le soumettre à user/findpass_reset avec l'email ou le téléphone de la victime ;
3. le mot de passe de la victime est réinitialisé : prise de contrôle du compte.

La description parle de « n'importe quel membre ». Elle ne dit pas explicitement si les comptes d'administration passent par le même parcours : vérifie-le sur ton instance avant d'écarter ce scénario.

Versions affectées

Ces bornes viennent des descriptions publiées par VulnCheck, pas d'une analyse NIST. La première version hors plage est celle où le correctif est apparu ; installe de préférence la dernière version disponible du projet.

Détection

• OpenHands : lister les conteneurs du bac à sable (docker ps) et regarder sur quelles adresses leurs ports sont publiés. Un port lié à 0.0.0.0 sur une machine joignable depuis un autre réseau est à traiter tout de suite. Vérifier la version du SDK dans les dépendances Python des projets qui l'utilisent.
• danmu_api : vérifier que TOKEN n'a pas sa valeur par défaut et que ADMIN_TOKEN est défini. Rechercher dans les journaux des POST sur /api/env/ et contrôler que OTHER_SERVER et PROXY_URL pointent bien là où tu les as configurés.
• MacCMS : rechercher des appels à user/findpass_reset dont le code a été demandé pour une autre adresse, et des réinitialisations de mot de passe que les membres n'ont pas demandées.

Mitigation

1. Mettre à jour les trois projets au moins jusqu'à la première version hors plage.
2. OpenHands, en attendant : ne publier le port du serveur d'agent que sur 127.0.0.1, filtrer ce port au pare-feu, et faire tourner les secrets confiés à un agent qui a été exposé.
3. danmu_api : remplacer le TOKEN par défaut et définir un ADMIN_TOKEN fort, puis relire toute la configuration d'environnement.
4. MacCMS : après mise à jour, forcer la réinitialisation des mots de passe des comptes d'administration si des réinitialisations suspectes apparaissent.

Pourquoi surveiller en continu tes outils auto-hébergés

Ces projets ne passent ni par un éditeur, ni par une console de mises à jour centralisée : ce sont des dépendances installées un jour par un développeur, puis oubliées. Et comme NVD ne les a pas analysées, une veille fondée sur les seules correspondances CPE ne les verra pas.

Avec cveo.tech, ajoute à ton parc les outils open source que tu fais tourner, avec leur version, et reçois une alerte dès qu'une CVE les cite, même quand NVD ne l'a pas encore analysée.