Lorsque des chercheurs ont expliqué comment Mythos, d’Anthropic, avait aidé à construire une chaîne d’exploitation complète, Rejetto avait déjà corrigé la faille critique de son HTTP File Server. La version 3.2.1 est sortie le 13 juillet 2026 ; Horizon3 a publié son analyse technique le 30 septembre ; VulnCheck a observé des tentatives d’exploitation le 1er octobre. L’intervalle frappant n’est pas une journée sans correctif disponible, mais plus de deux mois pendant lesquels certaines installations exposées sont apparemment restées sans protection.
CVE-2026-61500 touche HFS 3.0.0 à 3.2.0. Selon Horizon3, l’enquête assistée par IA a relié un aléatoire prévisible, des valeurs visibles lors de la connexion et des cookies de session signés à l’exécution de code avec les droits administrateur. C’est une capacité de recherche importante, pas une preuve de piratage autonome universel ni une mesure des infections mondiales.
Une clé de signature que l’on pouvait reconstruire
HFS partage des fichiers au moyen d’un serveur web. La branche 3.x est une réécriture en TypeScript, exécutée sur Node.js avec Koa ; l’ancien logiciel 2.x utilisait Delphi. Dans les versions concernées, la clé de signature des cookies par défaut provenait de Math.random() de JavaScript : un générateur pseudo-aléatoire généraliste, pas une source cryptographiquement sûre.
Un cookie signé ne protège l’intégrité que si sa clé reste secrète et imprévisible. Parallèlement, une procédure de connexion sans authentification exposait des sorties en pleine précision du même générateur. Elles n’étaient pas indépendantes des valeurs servant à créer la clé au démarrage : le générateur suit une séquence déterministe à partir d’un état interne.
Horizon3 indique qu’un agent spécialisé en analyse cryptographique a identifié trois tirages utilisés pour la clé initiale et relié les valeurs exposées à l’implémentation xorshift128+ de V8. Son état réversible permettait de remonter le temps dès lors que suffisamment d’observations corrélées étaient disponibles. La réversibilité seule ne rend pas toutes les applications exploitables : HFS fournissait aussi les observations et leur relation au secret.
La démonstration utilisait 12 observations et Z3, le solveur de satisfaisabilité modulo théories de Microsoft, pour retrouver un état compatible avec les contraintes. Un cookie existant et son code d’authentification de message permettaient de vérifier hors ligne les clés candidates. C’était une reconstruction mathématique, non des essais répétés de mots de passe en ligne. Le cookie était signé mais non chiffré ; le client pouvait lire ses propres données de session.
Avec la clé retrouvée, un cookie pouvait revendiquer une identité administrateur tout en conservant une signature valide. La chaîne décrite vérifiait l’existence du compte administrateur intégré. Une fois la session acceptée, la fonction légitime de JavaScript personnalisé côté serveur de HFS ouvrait la voie à l’exécution de commandes arbitraires. L’identité forgée donnait accès à une fonction privilégiée, plutôt qu’une simple entrée malformée exploitant un analyseur.
La correction modifie les deux extrémités : des octets aléatoires cryptographiquement sûrs pour la clé et un UUID aléatoire pour l’identifiant exposé pendant la connexion. Définir explicitement une clé robuste peut atténuer une partie de la chaîne, mais ne remplace pas l’installation de la version 3.2.1 ou d’une version stable ultérieure.
Ce que l’IA a réellement apporté
Un scanner pouvait déjà signaler Math.random() près du code d’authentification. La difficulté consistait à relier cet avertissement aux sorties observables, au format exact de session, à la clé reconstruite et à une opération privilégiée aux conséquences concrètes. Chaque étape ajoute de l’incertitude et du travail spécialisé, au point de rendre certaines recherches non rentables.
Horizon3 rapporte que Mythos a relié ces étapes à travers les fichiers, le comportement du framework et les mathématiques du générateur, puis produit une preuve de concept fonctionnelle exécutant des commandes sur l’hôte. Des chercheurs humains ont vérifié et reproduit le résultat avant publication. Un exploit fonctionnel rend la priorisation plus concrète qu’un plantage inexpliqué ou une ligne suspecte.
C’était un cas de Project Glasswing utilisant un environnement sur mesure et des agents spécialisés travaillant en parallèle. Des humains ont choisi la cible, organisé l’investigation, validé le résultat et coordonné le signalement. Il ne s’agissait pas d’un chatbot grand public compromettant instantanément et sans assistance un dépôt quelconque.
Le rapport de capacités d’Anthropic souligne lui aussi l’exploitation complète comme preuve d’impact. Le changement potentiel est économique : des recherches nécessitant auparavant une expertise cryptographique particulièrement coûteuse pourraient devenir intéressantes. Les ingrédients étaient connus ; leur synthèse en une chaîne vérifiée constituait la valeur.
L’étude publique ne fournit pas le dénominateur nécessaire pour mesurer la productivité générale. Calcul total, exécutions infructueuses, faux positifs et résultats abandonnés restent des inconnues importantes. Une réussite exceptionnelle n’établit ni la régularité des découvertes critiques ni l’adéquation du coût à un programme plus vaste.
Des tentatives après publication, pas un bilan d’infections
Le correctif du 13 juillet précédait de plus de deux mois l’explication du 30 septembre. Les observations de VulnCheck du 1er octobre concernent donc des systèmes pour lesquels une solution existait déjà, et non une nouvelle faille laissant les administrateurs sans recours.
Le trafic initial rapporté utilisait une infrastructure hébergée en Chine contre des systèmes américains. Des requêtes ultérieures venaient de deux adresses américaines du même sous-réseau, apparemment des relais ; des cibles au Japon ont aussi été signalées. La géographie de l’hébergement n’identifie pas les opérateurs et ne prouve pas un soutien étatique.
Les détections attestent des tentatives, pas le nombre de cibles ayant accepté une session administrateur forgée ou exécuté des commandes. Elles ne justifient ni une estimation mondiale des compromissions ni l’affirmation d’une grande campagne durable. Des charges après intrusion et des victimes confirmées changeraient sensiblement l’évaluation.
Le délai d’environ une journée ne prouve pas non plus que les attaquants utilisaient l’IA ou avaient résolu indépendamment toute la chaîne mathématique pendant la nuit. Ils pouvaient adapter les documents publiés, avoir travaillé auparavant ou utiliser d’autres informations. Scanners, comparaison de correctifs, frameworks d’exploitation et rétro-ingénierie humaine permettaient déjà une réutilisation rapide.
La politique de divulgation coordonnée d’Anthropic prévoit généralement notification aux mainteneurs, examen humain et délai de 90 jours, avec les détails complets normalement 45 jours après un correctif. Ici, l’intervalle était plus long. Ce tampon offre une occasion de mettre à jour, sans garantir que chaque service vulnérable ait été trouvé.
Le chronomètre s’arrête au déploiement vérifié
Des serveurs de fichiers légers peuvent échapper à l’inventaire et aux responsabilités habituelles : un transfert temporaire perdure, un ancien conteneur reste figé ou une redirection de port oubliée maintient l’hôte accessible. Peu d’utilisateurs ne rendent pas l’exécution non authentifiée moins utile comme point d’entrée.
La mesure pertinente va de la disponibilité du correctif à la mise à jour, l’isolation ou la suppression de toutes les instances vulnérables exposées, pas à l’attribution d’un ticket. Inventaires, registres de conteneurs, installations sur terminaux, charges cloud et services accessibles de l’extérieur comptent. Il faut vérifier quel binaire ou quelle image répond réellement.
La distinction des versions est essentielle. CVE-2024-23692, une précédente faille HFS ajoutée au catalogue CISA des vulnérabilités exploitées en 2024, touchait la différente base 2.x. Ce n’est pas cette chaîne cryptographique et cela ne signifie pas que toutes les installations HFS sont compromises.
VPN, listes d’autorisation ou passerelles authentifiées peuvent réduire l’exposition inutile pour un groupe restreint, sans remplacer la mise à jour. Un terminal de confiance peut être compromis, une configuration changer et une frontière présumée céder.
Les journaux autour du 30 septembre et après méritent un examen des authentifications répétées, sessions administrateur inattendues, changements de configuration et codes serveur inconnus. Ce sont des pistes, pas des indicateurs universels et définitifs. Sur un hôte dont la compromission est confirmée, une simple mise à jour ne supprime pas une persistance possible dans les comptes, tâches planifiées, scripts de démarrage ou autres services. Isolation, préservation des preuves, renouvellement des identifiants, évaluation des ressources reliées et reconstruction si l’intégrité est incertaine restent pertinents.
La découverte doit rejoindre la remédiation
Pour les développeurs, la leçon dépasse un appel de fonction. Les générateurs pseudo-aléatoires généralistes ne doivent pas fournir les secrets d’authentification, jetons de réinitialisation, nonces cryptographiques ou identifiants de session sensibles. L’examen doit suivre l’état partagé et les fuites de sorties corrélées : un middleware de signature ne sécurise pas une clé prévisible.
L’IA peut suivre les relations entre fichiers et tester si une faiblesse théorique mène à de vrais privilèges. La validation humaine doit encore contrôler les versions, hypothèses environnementales et possibilités de généraliser une démonstration de laboratoire aux systèmes déployés.
Trois évolutions éclaireront l’impact : le passage éventuel des sondages à des attaques durables avec charges après compromission ; la disparition des versions exposées concernées ; et la qualité de futurs rapports Glasswing, reproductibles, importants et gérables pour les mainteneurs plutôt qu’une avalanche de signalements peu utiles.
HFS étaye une conclusion plus étroite mais substantielle : un système de recherche assisté par IA a aidé des spécialistes à prouver un exploit inhabituel de bout en bout. Sa valeur défensive dépend finalement des mainteneurs traitant le résultat et des opérateurs transformant une correction disponible en protection vérifiée.
Sources
Analyse technique Horizon3 · Version HFS 3.2.1 · Rapport sur Mythos · Trafic d’attaque observé · Politique de divulgation · Ancienne vulnérabilité HFS · Référence originale