La vulnérabilité HFS de Mythos d’Anthropic a été corrigée, puis les attaquants sont passés à l’action

Mythos d’Anthropic a contribué à révéler une faille critique dans HFS, mais des exploitations signalées ont commencé peu après la publication par les chercheurs de la chaîne d’attaque complète. La vulnérabilité HFS de Mythos d’Anthropic permet à un attaquant non authentifié de reconstituer un secret de serveur, de forger une session administrateur et d’obtenir une exécution de code à distance.

La faille, suivie sous la référence CVE-2026-61500, affecte les versions 3.0.0 à 3.2.0 de Rejetto HTTP File Server. Rejetto l’a corrigée dans la version 3.2.1 en juillet 2026. Horizon3 a publié son analyse technique détaillée le 30 septembre, et VulnCheck a détecté des tentatives d’exploitation dès le lendemain.

Cette séquence en fait davantage qu’une nouvelle histoire de découverte de vulnérabilité assistée par IA. Mythos ne s’est pas contenté de mettre en évidence une fonction suspecte. Selon Horizon3, il a relié des faiblesses distinctes, modélisé un générateur de nombres aléatoires réversible, construit les contraintes nécessaires et produit un exploit fonctionnel.

La partie la plus troublante est survenue après la divulgation. Les défenseurs disposaient d’un correctif depuis plus de deux mois, mais des systèmes vulnérables semblaient encore accessibles lorsque les mécanismes de l’exploit sont devenus publics. L’enjeu central n’est donc pas Mythos face à un autre modèle d’IA. Il s’agit de la recherche accélérée de vulnérabilités face au processus plus lent d’identification, de mise à jour et de vérification des logiciels exposés.

La vulnérabilité HFS de Mythos d’Anthropic transforme l’aléatoire en accès administrateur

CVE-2026-61500 transforme une source d’aléa faible en voie non authentifiée vers un contrôle administratif complet.

Rejetto HFS est un serveur open source destiné au partage de fichiers sur le web. Sa branche 3.x actuelle fonctionne sur Node.js et utilise Koa, un framework JavaScript, pour gérer les requêtes web et les sessions.

Un cookie de session indique à une application web quel utilisateur authentifié effectue une requête. Le serveur signe ce cookie avec une clé secrète afin qu’un attaquant ne puisse pas modifier le nom d’utilisateur ou les privilèges sans invalider la signature.

HFS créait sa clé de signature par défaut avec la fonction JavaScript Math.random(). Cette fonction convient aux comportements aléatoires ordinaires, mais elle n’est pas conçue pour générer des secrets cryptographiques.

Le problème allait au-delà du choix initial du générateur. HFS exposait également d’autres valeurs issues du même générateur de nombres pseudo-aléatoires pendant une partie de son processus de connexion. Un générateur de nombres pseudo-aléatoires, ou PRNG, produit une séquence déterministe à partir d’un état interne.

La divulgation technique de Horizon3 indique que Mythos a identifié les deux aspects de cette relation. Il a détecté la génération faible de la clé de signature ainsi qu’un chemin distinct, non authentifié, révélant des sorties observables de la même séquence.

Le modèle a ensuite établi qu’un nombre suffisant de sorties permettrait de reconstituer l’état du générateur. À partir de là, un attaquant pourrait remonter la séquence et reproduire les valeurs utilisées par HFS lors de la création de sa clé de signature.

Il ne s’agit pas de deviner un mot de passe au moyen de tentatives de connexion répétées. L’attaquant résout plutôt l’état interne d’un système déterministe. Une fois cet état connu, la clé supposément secrète devient reproductible.

La chaîne démontrée par Horizon3 commence par vérifier si le nom d’utilisateur administrateur intégré existe. L’attaquant demande ensuite à plusieurs reprises une opération de connexion afin de collecter les sorties Math.random() exposées.

Les chercheurs ont échantillonné l’endpoint vulnérable 12 fois dans l’exploit décrit. Ces observations sont devenues des contraintes pour Z3, un solveur de satisfaisabilité modulo théories développé par Microsoft.

Un solveur SMT détermine quelles valeurs satisfont un ensemble de conditions logiques et mathématiques. Ici, il a permis de retrouver un état cohérent avec les sorties aléatoires observées et le comportement connu de HFS.

L’attaquant peut ensuite remonter l’état reconstitué jusqu’à la séquence de démarrage du serveur. Cela révèle les valeurs utilisées pour construire la clé de signature des cookies.

Avec cette clé, l’attaquant crée un cookie correctement signé prétendant représenter l’administrateur. HFS accepte la session falsifiée car sa signature est valide, même si le véritable administrateur n’a jamais authentifié l’attaquant.

L’accès administratif fournit le dernier maillon. HFS prend en charge du code personnalisé côté serveur, de sorte qu’un administrateur peut configurer du JavaScript exécuté sur l’hôte. Horizon3 a utilisé cette capacité légitime pour démontrer l’exécution de commandes arbitraires.

La distinction est importante. Le comportement dangereux ne dépend pas de l’injection de code malformé via un bug de parseur accidentel. Il combine une identité falsifiée avec une fonctionnalité volontairement mise à la disposition des administrateurs.

Le correctif de Rejetto traite les deux sources de prévisibilité. La version corrigée utilise des octets aléatoires cryptographiquement sûrs pour la clé de signature et un UUID aléatoire pour l’identifiant de connexion exposé.

Les opérateurs devraient installer la version HFS 3.2.1 ou une version stable plus récente. Définir explicitement une clé de signature robuste peut réduire une partie du risque, mais la mise à niveau élimine la chaîne documentée et reste la réponse appropriée.

Mythos a trouvé une chaîne que des examinateurs humains auraient pu abandonner

Le résultat important de Mythos n’était pas d’identifier `Math.random()`, mais de prouver que plusieurs erreurs d’apparence ordinaire formaient un exploit concret.

Les outils d’analyse statique avertissent les développeurs depuis des années des générateurs de nombres aléatoires faibles. Un scanner peut rechercher Math.random() à proximité du code d’authentification et signaler la ligne pour examen.

Cette observation ne suffit pas à établir une compromission à distance. Un chercheur doit encore déterminer si un attaquant peut observer des sorties liées, reconstituer le générateur, récupérer la clé exacte, forger le bon format de cookie et transformer l’authentification en impact significatif.

Chaque étape ajoute du travail et de l’incertitude. Cela détermine souvent si une découverte fera l’objet d’une enquête approfondie, notamment lorsque les chercheurs doivent choisir parmi de nombreuses pistes possibles.

Horizon3 affirme que Mythos a géré ce parcours de raisonnement plus long. Son agent spécialisé en analyse cryptographique a remarqué que HFS consommait trois sorties aléatoires lors de la création de la clé de signature au démarrage.

Le modèle a également identifié un chemin de connexion qui renvoyait des valeurs à pleine précision produites par le même générateur. Il a reconnu que le cookie était signé mais non chiffré, ce qui permettait au client de lire ses propres données de session.

Mythos a ensuite relié ces faits à l’implémentation xorshift128+ de V8. V8 est le moteur JavaScript utilisé par Node.js, et xorshift128+ maintient un état interne réversible.

La réversibilité ne rend pas automatiquement exploitable chaque application utilisant ce générateur. L’attaquant a toujours besoin d’un nombre suffisant d’observations utiles et d’un moyen de les corréler à la séquence générant le secret.

HFS réunissait ces deux conditions. Il exposait des valeurs consécutives via le flux de connexion, tandis que la clé de signature provenait du même générateur au démarrage du processus.

Le modèle a proposé d’utiliser Z3 pour reconstituer l’état plutôt que de tenter une recherche naïve parmi toutes les clés possibles. Il a également identifié un cookie et une signature existants comme mécanisme de vérification hors ligne.

Cette étape de vérification est importante. Un candidat reconstitué peut être testé localement contre le code d’authentification de message d’un cookie légitime. L’attaquant n’a pas besoin d’envoyer chaque candidat à la cible et de générer des requêtes manifestement infructueuses.

Selon Horizon3, Mythos a créé la preuve de concept fonctionnelle et démontré l’exécution de commandes arbitraires. Des chercheurs humains ont examiné le résultat avant la divulgation, ce qui est essentiel lorsqu’une analyse de modèle peut contenir des erreurs subtiles.

Le rapport plus général d’Anthropic sur les capacités de Mythos décrit une insistance similaire sur l’exploitation complète. L’entreprise soutient que la production d’un exploit fonctionnel aide à distinguer les vulnérabilités importantes des plantages ou du code suspect sans impact pratique.

Cette approche peut améliorer le triage défensif. Une voie confirmée vers l’accès administrateur mérite un traitement différent d’un avertissement isolé sans déclencheur accessible.

Elle abaisse aussi la barrière économique à l’exploration de catégories de vulnérabilités inhabituelles. Les chercheurs de Horizon3 ont indiqué que les résultats cryptographiques peuvent être dépriorisés car leur démonstration exige des connaissances mathématiques spécialisées et beaucoup de temps.

Un système d’IA qui accomplit ces étapes peut rendre viables des recherches auparavant non rentables. L’ensemble des bugs qui méritent d’être étudiés s’élargit lorsque le coût marginal de création et de test d’un exploit diminue.

L’exploit HFS de Mythos illustre clairement ce changement. Aucun ingrédient pris isolément n’était inédit. L’aléatoire faible, les sorties de générateur exposées, les cookies signés et les fonctions administratives privilégiées sont des concepts de sécurité établis.

Le changement réside dans la synthèse. Mythos aurait suivi la relation à travers les fichiers, les frameworks, le comportement mathématique et les fonctionnalités de l’application sans que les chercheurs aient à prescrire chaque étape intermédiaire.

C’est aussi pourquoi les affirmations simplistes selon lesquelles l’IA « trouve un bug » passent à côté de la véritable pression. La découverte a de la valeur, mais la construction d’un exploit détermine si une découverte devient un problème opérationnel urgent.

La divulgation publique s’est heurtée à un cycle de correctifs lent

Le correctif existait avant l’analyse complète de l’exploit, mais des systèmes HFS accessibles publiquement seraient restés vulnérables lorsque la méthode est devenue plus facile à reproduire.

Rejetto a publié la version 3.2.1 le 13 juillet 2026. Les enregistrements CVE identifient les versions 3.0.0 à 3.2.0 comme affectées.

Horizon3 a attendu le 30 septembre pour publier son analyse détaillée. Ce délai a donné aux administrateurs le temps de mettre à jour sans fournir aux attaquants une explication complète de la vulnérabilité.

La divulgation incluait les mécanismes importants. Elle décrivait la fuite de nombres aléatoires, la reconstitution de l’état, la récupération de clé, la session administrateur falsifiée et le passage à l’exécution de code.

VulnCheck a commencé à détecter des tentatives d’exploitation le 1er octobre, selon le trafic d’attaque observé. L’activité initiale aurait impliqué une infrastructure hébergée en Chine ciblant des systèmes vulnérables aux États-Unis.

Des requêtes ultérieures provenaient de deux adresses américaines du même sous-réseau, qui semblaient fonctionner comme des proxys. Des chercheurs ont également signalé un ciblage de systèmes au Japon.

Ces observations étayent l’existence de tentatives d’exploitation actives, mais elles n’établissent ni l’identité de l’attaquant ni une affiliation gouvernementale. L’emplacement de l’hébergement et celui du proxy sont de faibles signaux d’attribution.

Elles ne révèlent pas non plus combien de systèmes ont été compromis. Une détection peut montrer que quelqu’un a envoyé du trafic lié à un exploit sans prouver que la cible a accepté une session falsifiée ou exécuté une commande.

Même avec ces limites, le calendrier importe. La première activité observée a suivi l’explication technique publique d’environ un jour.

Cela ne prouve pas que les attaquants ont reproduit indépendamment chaque étape mathématique durant cette période. Ils peuvent avoir développé la technique plus tôt, adapté des éléments divulgués ou obtenu suffisamment d’informations à partir d’enregistrements de vulnérabilités existants.

La leçon opérationnelle reste la même. Dès que des informations détaillées sur un exploit deviennent publiques, les défenseurs devraient supposer que des acteurs compétents peuvent rapidement les convertir en trafic d’analyse et d’attaque.

La politique de divulgation d’Anthropic vise à équilibrer ces besoins concurrents. Elle prévoit généralement la notification des responsables de maintenance, un délai de divulgation de 90 jours et une revue humaine des signalements générés par l’IA.

La politique indique qu’Anthropic attend normalement 45 jours après un correctif avant de publier les détails techniques complets. Ce délai doit permettre aux utilisateurs en aval de déployer les correctifs.

CVE-2026-61500 a connu un intervalle plus long entre son correctif de juillet et l’analyse de Horizon3 en septembre. L’apparition de systèmes vulnérables après cet intervalle montre pourquoi le calendrier de divulgation ne peut compenser une visibilité incomplète des actifs.

Un serveur peut être négligé parce qu’il a été déployé pour un transfert ponctuel et n’a jamais été inscrit dans un inventaire. Un conteneur peut rester figé sur une image plus ancienne. Un service auto-hébergé peut aussi rester derrière une règle oubliée de redirection de port.

HFS attire précisément ce type de cas d’usage légers. Son accessibilité facilite le partage de fichiers, mais elle peut aussi encourager des déploiements en dehors d’une infrastructure gérée de manière centralisée.

L’historique du logiciel rend cette préoccupation concrète. Une précédente faille HFS affectant l’ancienne branche 2.x a été ajoutée au catalogue Known Exploited Vulnerabilities de la CISA en 2024.

Cet ancien problème était une vulnérabilité différente, dans une base de code différente. HFS 3.x a été réécrit en TypeScript, tandis que la branche 2.x utilisait Delphi.

Ce précédent ne signifie pas que chaque installation HFS est compromise. Il montre toutefois que les serveurs de fichiers exposés à internet constituent des cibles attrayantes, surtout lorsque l’exploitation mène directement à l’exécution de code.

Le déploiement de correctifs nécessite donc une étape de vérification. Les équipes de sécurité ne devraient pas clôturer le ticket lorsqu’une mise à jour est attribuée. Elles devraient confirmer que chaque instance accessible signale une version corrigée et que les anciens conteneurs ou binaires ne répondent plus aux requêtes.

Le véritable enjeu oppose la découverte par l’IA à la rapidité de remédiation

Mythos accélère le rythme de la recherche en sécurité, mais l’exposition d’une organisation dépend toujours de sa capacité à localiser et mettre à jour rapidement ses systèmes.

Les programmes de sécurité mesurent souvent la gestion des vulnérabilités à travers des volumes. Les équipes indiquent combien de constats elles ont ouverts, combien de correctifs elles ont déployés ou quel pourcentage a respecté un objectif de niveau de service.

CVE-2026-61500 met en lumière un intervalle plus déterminant. Le délai important commence lorsqu’un correctif devient disponible et s’achève lorsque chaque instance vulnérable exposée est soit mise à jour, isolée ou supprimée.

La recherche assistée par IA réduit le temps nécessaire pour transformer du code source en chemin d’attaque validé. La divulgation publique réduit ensuite le coût de reproduction de ce chemin pour d’autres chercheurs et attaquants.

Le processus de correction ne s’accélère pas automatiquement au même rythme. Il dépend encore des registres de propriété, des fenêtres de maintenance, des tests, des validations, du déploiement et de la confirmation.

Cela crée une compétition asymétrique. Les chercheurs peuvent paralléliser l’analyse entre plusieurs dépôts, tandis que les défenseurs doivent traiter chaque système de production concerné dans son contexte métier.

La vulnérabilité HFS liée à Anthropic Mythos démontre également pourquoi les scores de gravité ne suffisent pas à eux seuls. Une note critique identifie l’impact potentiel, mais elle ne dit pas à une organisation si l’application vulnérable est accessible depuis internet.

À l’inverse, un petit serveur de partage de fichiers peut recevoir peu d’attention parce qu’il ne sert qu’à quelques utilisateurs. S’il permet l’exécution de code à distance sans authentification, son importance commerciale modeste ne réduit pas son utilité comme point d’entrée.

La réponse appropriée commence par la découverte. Les équipes devraient rechercher Rejetto HFS dans les inventaires logiciels, les registres de conteneurs, les charges de travail cloud, les déploiements sur les terminaux et les services accessibles depuis l’extérieur.

Elles devraient distinguer la branche 3.x des anciennes versions de HFS, car les correctifs et les mécanismes de vulnérabilité diffèrent. Toute installation 3.x prise en charge devrait exécuter la version 3.2.1 ou une version ultérieure, bien que la dernière version stable soit préférable.

Les contrôles réseau apportent une couche supplémentaire. Une instance HFS destinée à un groupe limité ne devrait pas rester ouverte à l’ensemble d’internet lorsque l’accès peut être restreint via un VPN, une liste d’autorisation ou une passerelle authentifiée.

Ces contrôles ne remplacent pas la mise à niveau. Un terminal de confiance compromis, une erreur de configuration ou une future modification du réseau peut exposer un service que les administrateurs croyaient isolé.

Les équipes devraient également examiner les journaux du serveur autour de la date de divulgation publique. Des appels répétés aux points de terminaison d’authentification, des sessions administrateur inattendues, des modifications de configuration et du code côté serveur inconnu méritent une enquête.

Un attaquant ayant réussi pourrait modifier davantage que la configuration HFS visible. L’exécution de code à distance peut permettre une persistance via des comptes du système d’exploitation, des tâches planifiées, des scripts de démarrage ou des services supplémentaires.

Pour cette raison, corriger un hôte dont la compromission est confirmée ne suffit pas. Les intervenants devraient l’isoler, préserver les preuves, renouveler les identifiants concernés, évaluer les ressources connectées et reconstruire le système lorsque son intégrité ne peut être établie.

Les implications défensives dépassent HFS. Les développeurs devraient considérer les générateurs pseudo-aléatoires généralistes comme des sources inacceptables pour les secrets d’authentification, les jetons de réinitialisation, les nonces cryptographiques et les identifiants de session.

La revue de code devrait examiner les relations d’état partagé, et non seulement les appels individuels. Un secret sécurisé peut tout de même devenir prévisible si le même générateur divulgue ailleurs des sorties corrélées.

Les valeurs par défaut des frameworks exigent une attention similaire. Les développeurs supposent parfois qu’une bibliothèque rendra sûre une entrée non sécurisée. Un framework de signature peut protéger l’intégrité d’un cookie uniquement si la clé de signature fournie reste secrète et imprévisible.

L’analyse assistée par IA est bien adaptée au suivi de ces relations entre fichiers. Les modèles peuvent rechercher les sites d’appel, tracer le flux de données, comparer le comportement des frameworks et tester si une faiblesse théorique atteint une opération privilégiée.

Cet avantage n’élimine pas le besoin de validation humaine. Un exploit généré peut mal interpréter une version, omettre une hypothèse environnementale ou démontrer un comportement qui ne se généralise pas au-delà d’un banc d’essai.

Le flux de travail le plus solide combine l’échelle des machines et une revue responsable. L’IA propose et teste des chaînes d’attaque, tandis que des chercheurs expérimentés reproduisent le résultat, évaluent la gravité, coordonnent la remédiation et contrôlent la divulgation.

Ce que l’exploit Mythos HFS ne prouve pas

Une chaîne d’exploitation réussie démontre une capacité significative, mais elle n’établit pas que Mythos trouvera de manière fiable chaque vulnérabilité critique.

Le rapport de Horizon3 est une étude de cas produite par une organisation participant au Project Glasswing d’Anthropic. Les chercheurs ont utilisé un harness personnalisé qui exécutait des agents spécialisés en parallèle sur la base de code de HFS.

Ce contexte est important. Le résultat ne représente pas un chatbot grand public non assisté recevant un dépôt et compromettant instantanément celui-ci.

Le harness a orienté l’enquête en attribuant aux agents des classes de vulnérabilités précises. Des chercheurs humains ont également sélectionné la cible, examiné les résultats et géré la divulgation responsable.

Mythos semble néanmoins avoir apporté davantage que de l’autocomplétion ou une liste de contrôle de sécurité générique. Selon les chercheurs, il a lié de manière indépendante le PRNG faible, la fuite de sortie, le format de session, la reconstruction rétrospective de l’état et la fonction d’exécution de code administrative.

Les preuves publiées étayent la découverte concernant HFS, car un exploit fonctionnel a démontré la chaîne. Elles fournissent moins d’informations sur les faux positifs, la puissance de calcul totale, les exécutions infructueuses et les découvertes écartées au cours de l’analyse plus large.

Ces dénominateurs manquants limitent les comparaisons générales de productivité. Un modèle qui trouve une vulnérabilité exceptionnelle après de nombreuses tentatives coûteuses présente une proposition opérationnelle différente de celle d’un modèle qui réussit systématiquement.

Le cas ne montre pas non plus que l’IA seule a provoqué l’exploitation rapide. Les attaquants se déplacent depuis longtemps rapidement après la publication de code de preuve de concept et d’analyses techniques.

Les scanners conventionnels, les outils de diffing, les frameworks d’exploitation et l’ingénierie inverse humaine prennent déjà en charge ce flux de travail. L’IA ajoute de la vitesse et de l’accessibilité, mais elle rejoint une chaîne d’outils offensifs existante.

Un emplacement de source n’établit pas davantage une attribution. Les attaques signalées utilisaient une infrastructure en Chine et aux États-Unis, mais les proxys et les hôtes compromis masquent régulièrement l’emplacement d’un opérateur.

Les affirmations concernant une campagne menée par un État-nation exigeraient des preuves supplémentaires, notamment des recoupements d’outils, l’historique de l’infrastructure, la sélection des victimes et le comportement après l’accès.

L’ampleur de l’exploitation réussie reste également incertaine. Les rapports publiés décrivaient un petit nombre de requêtes détectées contre des systèmes vulnérables réels.

Cela suffit à justifier l’application urgente de correctifs. Cela ne suffit pas à estimer un nombre mondial d’infections ni à affirmer l’existence d’une campagne généralisée.

Les défenseurs devraient résister aux deux extrêmes. Rejeter Mythos comme du marketing ignore un exploit validé et techniquement intéressant. Traiter un cas comme la preuve d’un piratage autonome universel exagère ce que les preuves publiques étayent.

La conclusion équilibrée est plus étroite, mais reste importante. Un système de recherche assisté par IA a aidé des spécialistes à transformer une erreur subtile de conception cryptographique en exploit de bout en bout aboutissant à l’exécution de code à distance.

Cette capacité élargit le nombre de découvertes que les chercheurs peuvent poursuivre de manière économiquement viable. Elle augmente également l’intérêt de réduire le délai entre la disponibilité d’un correctif et son déploiement vérifié.

Trois signaux montreront si les défenseurs peuvent suivre le rythme

Le prochain test consistera à déterminer si l’exploitation s’étend, si l’adoption des correctifs s’améliore et si les divulgations issues de l’IA restent gérables pour les responsables de maintenance logicielle.

Le premier signal est l’ampleur des attaques observées. Davantage d’adresses sources, de variantes d’exploit, de charges utiles post-compromission ou d’organisations affectées renforceraient la conclusion selon laquelle CVE-2026-61500 a dépassé le stade des tests opportunistes.

Un flux continu de sondes simples étayerait une interprétation plus étroite. Cela suggérerait que les attaquants expérimentent la technique publique sans avoir encore mis en place une campagne durable.

Le deuxième signal est de savoir si les opérateurs de Rejetto HFS retirent réellement les versions vulnérables. Les mesures internet et les rapports d’incident peuvent révéler si les installations exécutant les versions 3.0.0 à 3.2.0 persistent après la diffusion des avertissements.

Un déclin rapide montrerait que les responsables de maintenance, les fournisseurs de sécurité et les administrateurs ont transformé la divulgation en action. Une exposition durable confirmerait que l’inventaire et le déploiement restent les facteurs limitants.

Le troisième signal est la qualité et le volume des futures divulgations de Project Glasswing. Anthropic indique que les rapports de vulnérabilité issus de l’IA font l’objet d’une revue humaine et d’un traitement coordonné avant publication.

Un flux régulier de découvertes reproductibles et à fort impact étayerait l’argument selon lequel Mythos change l’économie de la recherche. Un déluge de rapports de faible valeur alourdirait au contraire la charge des responsables de maintenance de projets open source et affaiblirait la confiance dans le processus.

C’est la conséquence plus large de la vulnérabilité HFS liée à Anthropic Mythos. Une meilleure découverte ne crée une valeur défensive que lorsque les responsables de maintenance peuvent absorber les signalements et que les utilisateurs déploient les correctifs qui en résultent.

Les équipes de sécurité devraient mettre à jour dès maintenant les serveurs HFS concernés, vérifier la version déployée, restreindre toute exposition inutile et enquêter sur les activités suspectes après le 30 septembre. Elles devraient ensuite se poser une question plus difficile : si le prochain exploit assisté par IA arrive selon le même calendrier raccourci, leur inventaire des actifs pourra-t-il fournir une réponse avant les attaquants ?