Une faille d'authentification de Rejetto HFS trouvée par IA attire des tentatives d'exploitation

Des attaquants ont commencé à sonder une faille critique de contournement d'authentification dans Rejetto HTTP File Server (HFS) le 1er octobre 2026, un jour après que Horizon3.ai a publié les détails techniques qui la sous-tendent. La faille, suivie sous le nom CVE-2026-61500, porte un score CVSS de 9,3 et permet à un attaquant distant de forger une session administrateur sur un serveur non corrigé, puis d'atteindre l'exécution de code à distance. Rejetto a livré un correctif en juillet, dans la version 3.2.1. Un correctif fonctionnel existait depuis plus de deux mois avant la première détection enregistrée, et cet écart est la partie de l'histoire à surveiller.

À lire aussi: La faille de lecture de fichiers notée 9,3 chez Atlassian attire l'exploitation en quelques heures · Google corrige CVE-2026-58704, une faille zero-day du modem des Pixel exploitée activement.

Le modèle Mythos d'Anthropic a aidé à trouver le bug. Cela fait de CVE-2026-61500 un exemple net de deux tendances simultanées : la découverte de vulnérabilités assistée par IA d'un côté, et le travail lent et inégal de correction des logiciels exposés sur Internet de l'autre.

HFS est un serveur de fichiers léger et open source qu'un administrateur fait tourner pour déplacer des fichiers via HTTP, parfois sur une machine accessible depuis l'Internet public. Cet emplacement est ce qui rend un bug de falsification de session grave. Un attaquant qui accède au rôle d'administrateur prend le contrôle de la configuration et des opérations de fichiers du serveur. Un simple listage de répertoire serait un problème bien moindre. La fonction server_code transforme ce contrôle en exécution de code.

Ce que la faille permet à un attaquant de faire

Le bug est un problème de falsification de session dont la racine est un générateur de nombres aléatoires faible. Les versions 3.0.0 à 3.2.0 de HFS dérivent la clé de signature de leurs cookies de session de la fonction Math.random() de JavaScript, qui n'a jamais été conçue pour garder un secret. Les mêmes versions remettent aussi des sorties de ce générateur à des clients non authentifiés pendant le processus de connexion. (Avis GitHub)

Ces deux choix ensemble ouvrent la porte. Un attaquant distant peut collecter un petit nombre de réponses de connexion, reconstruire l'état interne du générateur à partir des valeurs exposées, récupérer la clé de signature des cookies et signer un cookie de session administrateur valide. Aucun vol d'identifiants n'est nécessaire. Math.random() est un générateur pseudo-aléatoire, et les générateurs pseudo-aléatoires sont déterministes : leurs sorties sont fonction d'un algorithme connu et d'une graine inconnue, donc suffisamment de sorties observées peuvent révéler l'état et prédire le reste.

Un contournement d'authentification de ce type est plus difficile à défendre qu'un mot de passe faible. Un problème de mot de passe peut se régler avec un secret plus long ou un second facteur ; ici, le secret lui-même est dérivé d'une source prévisible, donc la politique de mots de passe n'aide pas. L'attaquant n'a jamais à deviner quoi que ce soit qu'un défenseur peut renforcer.

Depuis une session administrateur, la fonction documentée server_code fournit l'étape suivante. Cette fonction permet à un administrateur de définir des points de terminaison personnalisés qui exécutent du JavaScript côté serveur, une façon légitime d'étendre HFS et, en l'occurrence, une voie vers l'exécution de code à distance pour quiconque a forgé une session admin. La vulnérabilité est notée 9,3 sur le système de notation des vulnérabilités communes, une bande réservée aux failles joignables à distance et menant à une compromission totale.

La cause racine est une erreur antérieure à cet incident et qui lui survivra. Node.js fournit crypto.randomBytes() pour l'aléatoire sensible à la sécurité, et le conseil standard pour quiconque touche au code source de HFS est de dériver les clés avec un générateur cryptographiquement sûr plutôt qu'avec Math.random().

Le correctif de la version 3.2.1 ferme la brèche pour HFS. La même erreur mérite d'être recherchée ailleurs : du code qui recourt à Math.random() pour construire un jeton, une clé ou un identifiant de session porte la même classe de faille.

Le modèle qui l'a trouvée

Le chercheur de Horizon3.ai Zach Hanley a déclaré, dans une divulgation publiée le 30 septembre 2026, que le modèle Mythos d'Anthropic avait trouvé la vulnérabilité, dans le cadre du projet Glasswing, l'effort d'Anthropic pour utiliser l'IA de pointe afin de trouver et corriger des failles dans des logiciels critiques. Security Affairs a rapporté que la faille avait été publiée via le CNA de VulnCheck le 13 juillet 2026. TechTimes a rapporté que la clé de signature avait été récupérée à l'aide du solveur Z3. (Divulgation Horizon3.ai, Security Affairs)

Z3 est un solveur polyvalent utilisé en analyse de programmes. L'appliquer à la sortie du générateur rend la reconstruction d'état traitable. Le projet Glasswing, le programme d'Anthropic qui pointe des modèles de pointe vers des logiciels critiques, est le cadre de cette découverte. L'argument derrière de tels programmes est simple : un modèle peut lire plus de code qu'une équipe d'audit et ne se fatigue pas. Savoir si cela produit un flux régulier de failles de haute gravité corrigées est une autre question, et les décomptes de VulnCheck sont l'un des rares moyens publics de le vérifier.

L'angle de l'IA invite à une affirmation plus large que ne le soutiennent les preuves. VulnCheck a compté 75 CVE mentionnant « Anthropic », dont 40 crédités à des chercheurs d'Anthropic, et un seul explicitement attribué à Glasswing. Ce sont les décomptes de VulnCheck, et ils évolueront à mesure que d'autres divulgations seront déposées. Une seule découverte créditée est un vrai résultat. Ce n'est pas encore un bilan, et cela ne montre pas à soi seul que l'IA a changé la vitesse à laquelle les bugs critiques sont trouvés.

Pourquoi un correctif de juillet n'a pas arrêté les sondages d'octobre

La fenêtre entre le correctif et les premières tentatives d'exploitation est là où l'incident devient inconfortable. Rejetto a livré le correctif dans la version 3.2.1 en juillet 2026, et Security Affairs a rapporté que la faille avait été publiée via le CNA de VulnCheck le 13 juillet. Une aide publique à l'exploitation est arrivée fin septembre, quand le chercheur en sécurité Alejandro Ramos, connu sous le nom aramosf, a publié une preuve de concept en Python. (Preuve de concept aramosf)

Cette séquence est routinière pour un logiciel exposé sur Internet. Un correctif existe, mais un opérateur doit l'appliquer. La divulgation et une preuve de concept fonctionnelle abaissent la compétence nécessaire pour attaquer, et un serveur corrigé reste sûr tandis qu'un serveur qui ne l'est pas devient plus facile à frapper chaque semaine qui passe. Comme une preuve de concept est apparue avant la première détection enregistrée, l'outillage pour exploiter la faille était public avant que les tentatives ne commencent.

Les dates ne décrivent pas un faux pas dans la divulgation coordonnée. La faille a été publiée via une autorité de numérotation CVE en juillet, le mois même où le correctif a été livré, et le compte rendu technique de Horizon3 a suivi fin septembre. Ce qui a changé début octobre, c'est la portée : un compte rendu public et une preuve de concept fonctionnelle ont permis à un groupe bien plus large de personnes d'essayer la faille.

Ce que VulnCheck a réellement observé

La télémétrie d'exploitation appartient à VulnCheck, et son ampleur mérite de rester proportionnée. L'entreprise a détecté des tentatives d'exploitation le 1er octobre 2026, un jour après qu'Horizon3 a publié plus de détails, et a ajouté CVE-2026-61500 à sa propre liste des vulnérabilités exploitées. Caitlin Condon, de VulnCheck, a déclaré que l'activité jusqu'ici ressemblait à de la reconnaissance à petite échelle. Une seule adresse IP de China Telecom a sondé des déploiements Canary au Japon et aux États-Unis. Le service Target Intelligence de VulnCheck a identifié environ 100 instances HFS exposées sur Internet. (The Hacker News)

Les déploiements Canary de VulnCheck sont des leurres que l'entreprise exploite pour observer les attaques, donc les systèmes de son rapport sont des leurres, pas des serveurs clients. Le chiffre d'environ 100 vient de son balayage Target Intelligence et compte des instances exposées sur Internet, pas des instances confirmées vulnérables.

Ces chiffres décrivent des tests, non une vague de serveurs compromis. La reconnaissance peut être la première étape d'une attaque, et une faille qui donne un accès administratif complet n'est pas à laisser exposée. Mais l'étiquette exacte pour ce que VulnCheck a observé début octobre est « sondage ». Environ 100 instances joignables constituent une petite population, et les déploiements Canary sont des leurres plutôt que des systèmes de production, donc une seule adresse source qui les frappe ressemble davantage à un balayage qu'à une campagne.

C'est aussi la deuxième fois que HFS attire des attaquants. CVE-2024-23692, une faille notée 9,8, a été exploitée en juillet 2024 pour livrer des mineurs de cryptomonnaie, des chevaux de Troie et des logiciels malveillants que les chercheurs ont nommés HATVIBE. La répétition suggère que le vivier de serveurs HFS exposés qui avaient attiré des attaquants il y a deux ans reste joignable.

La découverte par IA ajoute une nuance plus récente, et elle joue dans les deux sens. Un modèle qui lit le code et repère un défaut de dérivation de clé peut trouver un bug plus vite que les défenseurs ne le feraient. Le même pipeline de publication alimente ensuite des avis publics et des preuves de concept, ce qui raccourcit le temps dont les attaquants ont besoin pour exploiter tout ce qui reste non corrigé. La vitesse de découverte et la vitesse de correction sont des problèmes différents. Un seul des deux s'est amélioré ici.

Réserves

Les chiffres d'exploitation viennent de la télémétrie de VulnCheck, non de Rejetto ni d'Anthropic, et ils décrivent ce qu'un réseau de surveillance a vu. Les décomptes de 75 CVE et d'un seul cas Glasswing sont ceux de VulnCheck et changeront. Le récit de Horizon3 selon lequel Mythos a trouvé la faille vient de la divulgation de l'entreprise elle-même, et la vérification indépendante de la contribution d'un modèle à une découverte précise est difficile ; Anthropic n'a pas publié de liste complète des résultats de Glasswing.

On ne sait pas non plus combien des quelque 100 instances exposées sur Internet exécutent une version vulnérable, combien ont été corrigées depuis juillet, ni si l'un des sondages a mené à une intrusion réussie. La description de VulnCheck pointe vers de la reconnaissance, et aucune source de cet article ne rapporte de compromission confirmée d'une victime nommée.

La télémétrie de VulnCheck montre une reconnaissance à petite échelle, une seule adresse IP source sondant des leurres Canary, et environ 100 instances exposées sur Internet, une base faible pour une campagne massive.

Ce qu'il faut surveiller

Trois choses montreront si cela reste une affaire de sondage. D'abord, si VulnCheck ou d'autres réseaux de surveillance signalent des adresses source supplémentaires ou des intrusions réussies, ce qui ferait passer l'activité de la reconnaissance à l'exploitation. Ensuite, si les opérateurs de HFS mettent à niveau, car une instance exposée et non corrigée garde la faille utile, quelle que soit la façon dont le bug a été trouvé. Enfin, si le projet Glasswing produit d'autres découvertes créditées, ce qui transformerait un exemple isolé en preuve sur l'ampleur du changement qu'apporte l'IA à la recherche de vulnérabilités.

La faille elle-même n'a rien de remarquable : une clé de sécurité construite à partir d'un générateur qui n'a jamais été destiné à garder un secret. Ce qui rend CVE-2026-61500 digne d'attention, c'est le calendrier. Un modèle d'IA l'a trouvée, les développeurs l'ont corrigée en juillet, et les attaquants n'ont commencé à la tester qu'en octobre, après la publication des détails et d'une preuve de concept.

Crédit photo : rejetto, Wikimedia Commons, CC BY-SA 3.0.