CVE-2026-61500 : clé prévisible de signature de session dans Rejetto HFS

Rejetto HFS 3.0.0–3.2.0 utilisait des valeurs dérivées de Math.random() pour signer les sessions et lors de la connexion. Horizon3 indique que leur exposition permettait de falsifier des sessions ; VulnCheck dit avoir observé une activité d’exploitation à partir du 1er octobre. Passez à la version 3.2.1 ou ultérieure ; aucune victime précise n’est confirmée comme compromise.^{[1], [4], [5]}

💡 Explication en Langage Simple (ELI5)

La signature d’un cookie ressemble au sceau de cire d’un laissez-passer administrateur. HFS fabriquait le secret du sceau à partir d’une suite de nombres prévisible, tandis que la connexion révélait d’autres nombres de la même suite. Si quelqu’un déduit le secret, il peut contrefaire le sceau. Le correctif utilise l’aléatoire cryptographique de Node.js.^{[1], [3]}

Concepts Clés et Termes

Clé de signature de session: Secret utilisé par Koa pour signer les cookies de session et détecter toute altération.^{[1], [3]}
Math.random(): API pseudo-aléatoire généraliste, inadaptée à la création de secrets cryptographiques.^{[6], [4]}
CWE-338: Utilisation d’un générateur pseudo-aléatoire cryptographiquement faible ; c’est la faiblesse indiquée dans la fiche CVE.^{[1], [6]}
État du PRNG: État interne qui détermine les prochaines sorties pseudo-aléatoires. Réutiliser le générateur pour un secret et des valeurs observables peut révéler des liens entre eux.^[4]
Contexte de la découverte: Horizon3 indique que son système de recherche multi-agent assisté par Mythos a repéré et validé cette chaîne de vulnérabilités HFS. Cela décrit le travail des chercheurs ; ce n’est ni une vulnérabilité de Mythos ni la preuve d’une attaque autonome par IA contre une installation réelle.^[4]

Correspondances de référentiels

Référence CWE pour la faiblesse décrite dans ce guide : CWE-338

Analyse de Cause Racine

La fiche CVE concerne HFS 3.0.0 à 3.2.0 et associe le problème à CWE-338. Dans le commit amont 59472e5, le code vulnérable fournissait à Koa [randomId(30)] ; randomId() utilisait Math.random(). Le correctif remplace cette valeur par [randomBytes(32).toString('base64url')], importé de node:crypto. Le même commit remplace aussi Math.random() par randomUUID() pour l’identifiant public de la connexion. Horizon3 indique que les réponses de connexion accessibles sans authentification révélaient suffisamment de sorties liées pour retrouver l’état du PRNG de V8 et déduire la clé de signature des cookies. Une session administrateur contrefaite pouvait ensuite atteindre des fonctions administratives HFS menant à l’exécution de code côté serveur. Cet article décrit la chaîne à haut niveau sans reproduire le solveur, les requêtes ni les charges utiles. VulnCheck indique que Canary Intelligence a commencé à observer une activité d’exploitation le 1er octobre 2026, dans un rapport publié le 2 octobre ; cette télémétrie ne désigne aucune installation HFS compromise.^{[1], [3], [4], [5]}

Déroulement de l'Attaque Étape par Étape

Étape 1

Une version vulnérable de HFS est exposée

La plage concernée va de HFS 3.0.0 à 3.2.0. Les métriques CVSS indiquent un accès réseau sans privilège préalable.^{[1], [2]}

Étape 2

La même suite faible remplit deux rôles

HFS dérivait la clé de signature de Math.random() et la connexion divulguait des sorties liées. Un secret cryptographique ne doit pas provenir d’un PRNG prévisible ou observable.^{[1], [3]}

Étape 3

La faiblesse franchit la frontière de session

Selon Horizon3, les sorties permettaient de retrouver l’état du PRNG, donc de falsifier la signature d’une session et d’obtenir un accès administrateur. La procédure détaillée de récupération est omise.^[4]

Étape 4

L’accès administrateur peut mener à l’exécution serveur

Horizon3 décrit la chaîne jusqu’à la fonction server_code de HFS. VulnCheck indique que Canary Intelligence a commencé à observer une activité d’exploitation le 1er octobre 2026, selon le rapport du 2 octobre ; cette télémétrie ne prouve pas la compromission d’une installation particulière.^{[4], [5]}

Code Source : Vulnérable vs Sécurisé

Ces extraits reflètent le commit amont réel. randomBytes(32) fournit 256 bits issus du module cryptographique de Node.js pour la clé ; randomUUID() remplace la source de l’identifiant public de connexion. Les secrets qui authentifient des sessions doivent provenir d’une source cryptographique et rester indépendants des sorties observables du PRNG applicatif. Passez à HFS 3.2.1 ou à une version prise en charge ultérieure ; cet extrait explique le changement et ne constitue pas un correctif autonome. Cela sécurise uniquement la valeur de repli générée : si COOKIE_SIGN_KEYS est configurée, chaque clé fournie doit également être générée indépendamment avec un générateur cryptographique, conservée secrète et renouvelée en cas d’exposition.^{[3], [1]}

Extrait source: src/index.ts (clé de signature des cookies) et src/api.auth.ts (identifiant de handshake de connexion, commit amont 59472e5)

IMPLÉMENTATION VULNÉRABLE

import { httpStream, randomId } from './misc'

const keys = process.env.COOKIE_SIGN_KEYS?.split(',')
  || [randomId(30)]
export const app = new Koa({ keys })

const sid = Math.random()

PATCH SÉCURISÉ ET ROBUSTE

import { randomBytes, randomUUID } from 'node:crypto'

const keys = process.env.COOKIE_SIGN_KEYS?.split(',')
  || [randomBytes(32).toString('base64url')]
export const app = new Koa({ keys })

const sid = randomUUID()

Liste de Contrôle de Sécurité pour l'Ingénierie

✓Mettez à jour HFS 3.0.0–3.2.0 vers 3.2.1 ou une version ultérieure ; privilégiez la dernière version stable prise en charge.^{[2], [1]}
✓Inventoriez toutes les instances HFS, y compris sur Windows, dans les conteneurs, les environnements de test et les partages exposés à Internet ; notez leur version et leur exposition.^[4]
✓Si la mise à jour immédiate est impossible, limitez l’accès aux réseaux de confiance et supprimez l’exposition publique pendant sa préparation. Cela réduit l’exposition sans corriger la génération faible de clé.^[4]
✓Après la mise à jour de toute instance exposée publiquement pendant qu’elle était vulnérable, invalidez toutes les sessions existantes et renouvelez toute COOKIE_SIGN_KEYS configurée ; si l’enquête révèle une activité administrative non autorisée, renouvelez aussi les identifiants administrateur. Conservez les journaux pour analyse.^{[1], [4]}
✓Considérez les sondages observés comme un motif d’enquête, pas comme une preuve de compromission. Conservez les journaux et recherchez les modifications de configuration ou exécutions non autorisées.^{[5], [4]}
✓Dans les applications Node.js, vérifiez que chaque valeur configurée dans COOKIE_SIGN_KEYS est générée indépendamment avec un générateur cryptographique, reste secrète et est renouvelée en cas d’exposition ; la valeur de repli sécurisée ne valide pas les substitutions. Pour les autres secrets, utilisez les API de node:crypto, comme randomBytes(). Ne dérivez jamais clés de signature, jetons de réinitialisation ou valeurs d’autorisation de Math.random().^{[3], [6]}