Le Rejetto HTTP File Server (HFS) 3.x est à nouveau dans le collimateur : la faille CVE-2026-61500 (avec un score CVSS allant jusqu’à 9,8) exploite une signature de cookie de session faible basée sur `Math.random()`, combinée à une fuite permettant aux attaquants distants de reconstruire la clé de signature, de falsifier les cookies d’administrateur et d’atteindre une **exécution de code à distance via `server_code`. Horizon3.ai a découvert cette chaîne d’exploitation en utilisant Anthropic Mythos ; la correction a été déployée dans HFS 3.2.1 le 13 juillet 2026, mais une visibilité technique tardive en septembre et octobre 2026** a déclenché des scans actifs.
VulnCheck a signalé des déclenchements de canaris (canary tokens) entre le 1 et le 2 octobre depuis une adresse China Telecom ciblant des pièges à pêche (honeypots) au Japon et aux États-Unis — une reconnaissance à petite échelle, sans preuve d’exploitation massive, mais suffisante pour figurer dans la liste VulnCheck KEV. Comme au 6 octobre, la CISA n’avait pas encore ajouté la CVE-2026-61500 à la liste KEV, ce qui signifie qu’il n’y a pas de date limite fédérale — pourtant, attendre une inclusion KEV est risqué : la faille est réseau-accessible, non authentifiée et touche des serveurs de fichiers exposés qui ne se mettent rarement à jour à la vitesse des pare-feux.
BleepingComputer et SecurityWeek décrivent la chaîne d’exploitation suivante : collecter quelques réponses de connexion, inverser le générateur de nombres pseudo-aléatoires (PRNG), signer un cookie d’administrateur, puis activer le JavaScript côté serveur. Cela rappelle que « petit composant open-source » n’est pas « petit risque » lorsqu’il est déployé sur un DMZ ou partagé en interne par les développeurs.
**Que doivent faire les responsables IT et sécurité maintenant ?**
Inventorier les versions HFS 3.0.0 à 3.2.0 ; mettre à jour vers 3.2.1+ ou supprimer toute exposition internet. Détacher l’interface admin des réseaux publics, restreindre les IP sources, et rotater les sessions après correction. Analyser les logs à la recherche de tentatives de connexion répétées suivies d’actions admin et de connexions sortantes inattendues. Traiter tout RCE suspecté comme une compromission de l’hôte.
**Statut des preuves**
- Délégation Horizon3.ai (2026-09-30),
- Notes de version Rejetto 3.2.1,
- Données canary de VulnCheck,
- BleepingComputer/SecurityWeek (2026-10-05).
L’assistance par IA (Mythos) est l’angle médiatique, mais opérationnellement, cela change peu : les attaquants n’ont besoin que d’une chaîne fonctionnelle et de ports exposés. De nombreuses instances HFS sont des nœuds de labo ou de dépôt de fichiers oubliés après la fin des projets — des cibles idéales pour la reconnaissance. Comme la correction existait depuis juillet mais que les scans ont augmenté après la médiatisation en septembre, les cycles de correction doivent inclure un inventaire des applications dormantes, et non seulement des systèmes de production avec des propriétaires dans le CMDB.
Forensiquement : conserver les journaux web et d'application, comparer la configuration du `server_code` avant/après, et rechercher de nouveaux utilisateurs locaux ou des tâches planifiées sur l'hôte. Si HFS partage un hôte avec d'autres logiciels, supposez une mouvement latéral après une exécution de code à distance (RCE).
ShinyHunters mentionne dans certains commentaires du secteur un intérêt pour la classe de vulnérabilité, mais pas nécessairement pour cette CVE — séparez l'attribution de la priorité de correction.
Effectuez un balayage interne de la surface d'attaque : HFS écoute souvent sur des ports inhabituels dans les réseaux de laboratoire. Incluez les failles de génération de nombres pseudo-aléatoires (PRNG) et de sessions dans votre liste de vérification pour les outils hérités. Après la mise à jour vers la version 3.2.1, régénérez toutes les sessions et envisagez de déplacer les services de fichiers vers des plateformes gérées avec une gestion centralisée de l'identité et des accès (IAM).
Si HFS s'exécute en tant que service Windows, examinez le compte qu'il utilise — une RCE dans ce contexte signifie souvent des privilèges élevés. Une surveillance continue sans liste KEV signifie que votre modèle de risque doit gérer les vulnérabilités critiques CVSS sans attendre CISA.
Exécutez un balayage interne de la surface d'attaque : HFS écoute souvent sur des ports inhabituels dans les réseaux de laboratoire. Incluez les faiblesses de PRNG/session dans votre checklist d'outils hérités. Après la mise à jour vers la version 3.2.1, faites tourner toutes les sessions et envisagez de déplacer les services de fichiers vers des plateformes gérées avec une IAM centralisée. Si HFS fonctionne en tant que service Windows, vérifiez le compte qu'il utilise — une RCE (exécution de code à distance) ici signifie souvent des privilèges élevés. Une surveillance continue sans une liste KEV signifie que votre modèle de risque doit gérer les vulnérabilités critiques CVSS sans attendre CISA.
Les équipes d'intelligence menaçante doivent suivre à la fois les cycles d'hype des vulnérabilités et le volume réel de sondages : les déclencheurs de canaris prouvent une intention de trouver des victimes, pas une compromission réussie. Toujours associer les détections réseau aux propriétaires d'actifs — les développeurs déployent souvent HFS sans ticketing. Des exercices de red team peuvent valider si votre EDR détecte l'exploitation post-intrusion depuis l'exécution de `server_code`. Documentez les chemins de mise à jour pour les machines de laboratoire isolées qui ne peuvent pas se mettre à jour automatiquement.