Une information d'identification codée en dur dans MuseBot, une plateforme de gestion de bots, signifie que tout attaquant non authentifié qui connaît la clé de session par défaut peut fabriquer un cookie signé se réclamant d'un administrateur. Selon l'avis NVD pour CVE-2026-119660, la clé en question est la chaîne littérale muse_bot_session_key, intégrée dans les versions antérieures à 2.0.0. Une fois que vous signez un cookie avec cette clé et définissez un user_id, vous disposez d'un accès administrateur complet. Hachages de mots de passe, journaux de clavardage, configuration du bot, capacité d'arrêter des bots en cours d'exécution, tout y est.

Il s'agit d'un échec classique en gestion des secrets, sans aucune subtilité. Les secrets codés en dur dans la gestion des sessions sont le genre de problème introduit tôt dans la vie d'un projet et jamais renouvelé, parce que personne n'a mis en place de processus de rotation dès le départ. Le correctif existe dans la version 2.0.0, mais la leçon architecturale est plus large : tout système utilisant un secret de signature symétrique pour l'intégrité des sessions doit traiter ce secret de la même façon qu'une clé privée. Généré au moment de l'installation, stocké dans un coffre de secrets, renouvelable sans interruption de service.

L'angle IAM ici concerne ce que ces sessions protègent. Si l'interface d'administration de MuseBot est fédérée dans votre SSO ou se trouve derrière un proxy d'identité, un attaquant capable de forger un cookie de session peut contourner tout cela. La couche d'authentification fournie par votre IdP est sans pertinence si l'application fait confiance à un cookie qu'elle a elle-même signé à l'aide d'une clé bien connue. J'ai vu ce schéma apparaître dans des outils internes et des intégrations tierces plus souvent que je ne voudrais l'admettre. Les équipes supposent que l'application est « derrière le VPN » et s'arrêtent là. Ce n'est pas un contrôle, c'est un espoir.

Si MuseBot se trouve quelque part dans votre environnement, l'action immédiate est claire : mettez à jour vers la version 2.0.0 maintenant, puis vérifiez si des sessions existantes émises sous l'ancienne clé doivent être invalidées. Ne supposez pas que votre magasin de sessions existant est sain simplement parce que vous avez appliqué le correctif au binaire.

Pour tout autre système exécutant un secret de session symétrique, consultez votre inventaire de secrets et posez-vous deux questions : ce secret est-il généré de façon unique par déploiement, et quand a-t-il été renouvelé pour la dernière fois? Si vous ne pouvez pas répondre aux deux, voilà votre audit du lundi matin. Les outils génériques et les bots internes sont là où les secrets codés en dur se cachent le plus longtemps, parce que personne ne les traite comme des systèmes de production jusqu'à ce que quelque chose tourne mal.