Rejetto HFS CVE-2026-61500 exploitée un jour après la publication de son analyse

Des attaquants ont commencé à exploiter CVE-2026-61500, une faille critique du serveur de fichiers Rejetto HFS, le 3 octobre 2026. C'était un jour après qu'Horizon3.ai a publié son fonctionnement, rapporte The Register. Le bug permet à n'importe qui de falsifier une connexion administrateur, puis d'exécuter du code sur le serveur. Il a été découvert avec Mythos, le modèle d'IA d'Anthropic dédié à la chasse aux vulnérabilités, et HFS 3.2.1 le corrige.

Ce qu'est Rejetto HFS et quelles versions sont concernées

HFS, abréviation de HTTP File Server, est un programme gratuit et open source qui partage les fichiers d'un ordinateur via un navigateur web. Les versions 3.0.0 à 3.2.0 sont vulnérables, selon l'avis de VulnCheck. La version 3.2.1 est la première version corrigée.

Les deux principaux scores divergent légèrement. VulnCheck note la faille 9,3 sur 10, tandis que la base de données CVE de Strix indique 9,8. Les deux la placent dans la catégorie critique.

Détail	Valeur
Versions concernées	HFS 3.0.0 à 3.2.0
Version corrigée	HFS 3.2.1
Score de gravité	9,3 (VulnCheck) ou 9,8 (Strix)
CVE publiée	13 juillet 2026
Détails de l'exploit publiés	2 octobre 2026
Premières attaques observées	3 octobre 2026

Comment fonctionne l'attaque

La cause première est un générateur de nombres aléatoires qui n'est pas conçu pour les secrets. HFS crée la clé qui signe ses cookies de connexion avec Math.random() de JavaScript. Selon VulnCheck, HFS « divulgue aussi des sorties du même générateur à des clients non authentifiés pendant la connexion ».

C'est cette combinaison qui pose problème. Dans le moteur V8 de Google, qui fait tourner Node.js, Math.random() utilise un algorithme appelé xorshift128+. Il est rapide mais entièrement prévisible. Quiconque voit assez de ses sorties peut en déduire son état interne, puis chaque nombre qu'il produira.

Un attaquant lance donc des tentatives de connexion et collecte les nombres divulgués. Selon The Register, Horizon3 a ensuite utilisé Z3, un outil qui résout automatiquement des équations, pour reconstituer l'état du générateur. À partir de là, l'attaquant récupère la clé de signature et forge un cookie administrateur.

« Si un attaquant peut déduire quelle est la clé de signature des sessions, il peut forger des cookies de session valides », a déclaré Zach Hanley, chercheur chez Horizon3, à The Register. L'accès administrateur mène ensuite à l'exécution de code via le propre paramètre server_code de HFS, selon VulnCheck.

Ce que Mythos a trouvé et qu'un scanner pourrait manquer

Hanley attribue à Mythos le mérite d'avoir repéré la chaîne, et pas seulement le générateur faible. Mythos a remarqué le générateur non sécurisé et le chemin de code distinct qui divulguait ses sorties. Il a « reconnu ces deux faits comme une chaîne », a déclaré Hanley à The Register. Un outil qui signale uniquement Math.random() rapporterait une faiblesse sans prouver qu'elle peut être exploitée.

Mythos est le modèle sur invitation qu'Anthropic a mis à jour vers Mythos 5.1 en septembre. Il est crédité de 286 CVE au 3 octobre, rapporte The Register. The Register compte aussi cette faille comme la deuxième liée à Anthropic exploitée dans la nature depuis qu'Horizon3 a rejoint Project Glasswing, le programme de sécurité d'Anthropic, en juillet 2026. VulnCheck attribue la découverte à Hanley, en collaboration avec Anthropic Research.

Qui attaque

VulnCheck a vu les premières attaques le 3 octobre contre des serveurs aux États-Unis et au Japon, depuis des adresses hébergées en Chine, rapporte The Register. Les tentatives suivantes sont passées par des serveurs proxy aux États-Unis.

Le calendrier montre le peu d'effet d'un correctif à lui seul. La fiche CVE, qui renvoyait déjà au correctif de la 3.2.1, remonte au 13 juillet. Pourtant, au moment de la publication, le modèle EPSS, qui estime la probabilité qu'une faille soit exploitée dans les 30 jours, situait ce risque à 0,75 %, selon VulnCheck comme Strix. Les premières attaques observées par VulnCheck ne sont arrivées qu'après la parution d'une analyse pas à pas et d'une vidéo.

Ce que cela signifie pour les développeurs

Si vous utilisez HFS, passez à la 3.2.1 dès maintenant. Tout serveur en 3.0.0 à 3.2.0 accessible depuis Internet doit être considéré comme potentiellement compromis. Vérifiez ses paramètres d'administration, en particulier server_code, pour repérer tout ce que vous n'avez pas ajouté.

La leçon plus large vaut pour quiconque écrit du JavaScript. N'utilisez jamais Math.random() pour des clés, des jetons, des identifiants de session ou des réinitialisations de mot de passe. Dans Node.js, utilisez crypto.randomBytes() ou crypto.randomUUID(). Dans les navigateurs, utilisez crypto.getRandomValues(). Cherchez ensuite dans votre propre code Math.random( près de mots comme key, token, secret ou session.

Vérifiez aussi ce que votre application laisse fuiter. HFS était exploitable parce qu'il envoyait les sorties brutes du générateur à des visiteurs non connectés. Des identifiants d'apparence aléatoire dans les pages d'erreur, les réponses de connexion ou les en-têtes peuvent alimenter le même type d'attaque.

Enfin, n'attendez pas l'exploit pour appliquer le correctif. Un score EPSS faible mesure l'intérêt des attaquants avant une analyse publique, pas après. Des outils d'IA comme Mythos trouvent et expliquent désormais les bugs plus vite, si bien que l'écart entre une analyse et la première attaque devrait rester court.