Entre le 27 et le 31 octobre 2026, VulnCheck (CNA) a déposé dans NVD six CVE critiques visant six projets open source que l'on installe soi-même : l'outil de reporting AJ-Report, la plateforme de déploiement Jpom, le serveur d'inférence LMDeploy, le générateur de documentation OpenDeepWiki, le bot d'administration MuseBot et le CMS REDAXO.
Six produits sans rapport, mais un point commun : un attaquant non authentifié obtient un accès administrateur ou une exécution de code. Et dans la moitié des cas, la cause est la même — un secret connu de tous, livré dans le code source, qui sert à signer les jetons d'accès.
| CVE | Produit | Versions | Mécanisme | CWE | Statut NVD |
|---|---|---|---|---|---|
| CVE-2026-120209 | AJ-Report | jusqu'à 1.7.1 | Secret JWT en dur, puis script Groovy | CWE-321 | Received |
| CVE-2026-120201 | Jpom | 2.10.0 à 2.11.12 | Condition injectée dans l'en-tête de jeton | CWE-943 | Deferred |
| CVE-2026-119706 | InternLM LMDeploy | 0.9.0 à 0.18.0 | Pickle désérialisé sans contrôle | CWE-502 | Deferred |
| CVE-2026-119597 | OpenDeepWiki | jusqu'à 2.0.6 | Clé de signature JWT en dur | CWE-321 | Deferred |
| CVE-2026-119660 | MuseBot | avant 2.0.0 | Clé de session par défaut en dur | CWE-1394 | Deferred |
| CVE-2026-117532 | REDAXO core | 5.3.0 à avant 5.21.4 | Jeton de connexion temporaire prévisible | CWE-287 | Deferred |
Les six ont le même score VulnCheck : 9.8 en CVSS 3.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) et 9.3 en CVSS 4.0. NIST n'a analysé aucune de ces entrées, aucune configuration CPE n'y est attachée, et aucune n'est au catalogue CISA KEV à la date de rédaction.
Les secrets en dur : AJ-Report, OpenDeepWiki, MuseBot
Un jeton signé (JWT, cookie de session) ne vaut que par le secret qui le signe. Si ce secret est écrit dans le dépôt Git du projet, n'importe qui peut fabriquer des jetons valides hors ligne, sans jamais contacter le serveur avant l'attaque.
AJ-Report — CVE-2026-120209
Jusqu'à la 1.7.1, AJ-Report signe ses jetons de partage (Share-Token) avec un secret JWT codé en dur. Selon la description NVD, un attaquant fabrique un jeton portant le reportCode dataSet, ce qui lui ouvre l'endpoint testTransform. Cet endpoint transmet des scripts à GroovyClassLoader : le jeton forgé débouche donc sur une exécution de code à distance sans authentification.
C'est le cas le plus grave du lot. Un outil de reporting est branché, par construction, sur des bases de données métier.
OpenDeepWiki — CVE-2026-119597
Jusqu'à la 2.0.6, la clé Jwt:SecretKey du fichier appsettings.json livré avec le projet est publique. Un attaquant signe des jetons HS256 avec un rôle Admin et accède aux endpoints /api/admin : utilisateurs, rôles, dépôts, paramètres et clés d'API. Ces dernières sont souvent des clés de fournisseurs de modèles de langage, facturées à l'usage.
MuseBot — CVE-2026-119660
Avant la 2.0.0, l'interface d'administration utilise par défaut la clé de session muse_bot_session_key. Un attaquant signe un cookie MuseBot-session contenant un user_id et obtient un accès administrateur complet : empreintes de mots de passe, historiques de conversation, configuration des bots, et la possibilité de les arrêter.
Le schéma n'est pas nouveau : quatre projets open source avaient déjà été épinglés pour des secrets en dur à la mi-octobre.
Jpom — CVE-2026-120201
De la 2.10.0 à la 2.11.12, Jpom lit la valeur de l'en-tête JPOM-USER-TOKEN et l'utilise dans une requête construite avec le parseur Condition de la bibliothèque Hutool. Ce parseur interprète une valeur comme is not null comme un opérateur, pas comme une chaîne à comparer : la condition devient vraie pour n'importe quel utilisateur, et l'attaquant est authentifié en super-administrateur.
Jpom sert à déployer et superviser des applications sur des serveurs. Ses fonctions de scripts permettent ensuite d'exécuter des commandes, ce que la description NVD mentionne explicitement.
LMDeploy — CVE-2026-119706
LMDeploy, le serveur d'inférence de modèles de langage d'InternLM, expose dans les versions 0.9.0 à 0.18.0 un endpoint /update_weights sans authentification. Le champ serialized_named_tensors y attend des données encodées en base64, désérialisées par ForkingPickler.loads sans validation.
Désérialiser du pickle Python provenant du réseau revient à exécuter du code : un pickle forgé lance des commandes système avec les droits du processus api_server. Sur une machine d'inférence, ce processus a typiquement accès aux GPU, aux poids des modèles et souvent à des volumes de données.
REDAXO — CVE-2026-117532
Dans le cœur de REDAXO, de la 5.3.0 jusqu'à la 5.21.4 exclue, le plugin structure/history émet des jetons de connexion temporaires. Selon la description, un attaquant non authentifié peut forcer le secret lié à la session dans un état prévisible, puis forger un jeton pour un compte comme admin. Il obtient alors l'accès au back-office, et une exécution de code lorsque l'instance n'est pas en mode « live ».
L'advisory GitHub du projet (GHSA-px8f-whj8-hrpq) est cité dans les références NVD.
Versions affectées
| Produit | Plage affectée (description NVD) | Première version hors plage |
|---|---|---|
| AJ-Report | jusqu'à 1.7.1 incluse | non indiquée |
| Jpom | 2.10.0 à 2.11.12 incluses | non indiquée |
| LMDeploy | 0.9.0 à 0.18.0 incluses | non indiquée (pull request 4964 citée) |
| OpenDeepWiki | jusqu'à 2.0.6 incluse | non indiquée (commit correctif cité) |
| MuseBot | avant 2.0.0 | 2.0.0 |
| REDAXO core | 5.3.0 à avant 5.21.4 | 5.21.4 |
Ces bornes viennent des descriptions VulnCheck, pas d'une analyse NIST. Quand aucune version corrigée n'est indiquée, suis le dépôt du projet et l'advisory VulnCheck cités dans les références : la version suivante n'est pas forcément corrigée tant que le projet ne l'a pas annoncé.
Détection
- Inventaire : chercher ces projets dans les serveurs, les conteneurs et les images Docker des équipes (les outils d'IA comme LMDeploy et OpenDeepWiki sont souvent installés hors du circuit habituel).
- Secrets par défaut : sur AJ-Report, OpenDeepWiki et MuseBot, vérifier si le secret de signature a été remplacé. S'il ne l'a jamais été, considère que tout jeton émis jusqu'ici a pu être forgé.
- Journaux : appels à
testTransform(AJ-Report), à/api/admin(OpenDeepWiki) ou à/update_weights(LMDeploy) depuis des adresses inattendues ; en-têtesJPOM-USER-TOKENcontenant des mots-clés SQL ou des opérateurs. - Exposition : aucun de ces services ne devrait être joignable depuis Internet sans un reverse proxy authentifiant devant.
Mitigation
- Mettre à jour MuseBot en 2.0.0 et REDAXO en 5.21.4 au minimum ; pour les autres, suivre les correctifs annoncés par les projets.
- Remplacer les secrets de signature par des valeurs aléatoires propres à chaque instance (AJ-Report, OpenDeepWiki, MuseBot), ce qui invalide aussi les jetons existants.
- LMDeploy : ne jamais exposer
api_serverau-delà de127.0.0.1ou d'un réseau de confiance, et filtrer/update_weightsau proxy. - Faire tourner les clés d'API stockées dans OpenDeepWiki et les identifiants manipulés par Jpom si une instance a été exposée.
- Placer une authentification en amont (proxy, VPN, SSO) devant tous ces outils d'administration.
Pourquoi surveiller en continu tes outils auto-hébergés
Ces projets n'ont ni éditeur, ni console de mises à jour centralisée, et NVD n'en a analysé aucun : 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.