Mythos découvre une vulnérabilité dans curl

• Mythos d’Anthropic a signalé 5 vulnérabilités dans curl, mais il n’en reste en réalité qu’une seule
• Après examen par l’équipe sécurité de curl, 3 ont été classées comme faux positifs et 1 comme un bug ordinaire
• La vulnérabilité confirmée fera l’objet d’un CVE de faible gravité et sera publiée fin juin avec curl 8.21.0
• Le rapport contenait environ 20 bugs, et l’équipe curl est en train de corriger les points qu’elle juge valides
• Daniel Stenberg estime que les résultats sur curl ne prouvent pas vraiment que Mythos soit à un niveau particulièrement dangereux

---

La voie d’accès de Mythos d’Anthropic à curl

• En avril 2026, Anthropic a suscité un vif intérêt en concluant que son nouveau modèle d’IA Mythos était « dangereusement bon » pour trouver des failles de sécurité dans le code source
• Anthropic a choisi de ne pas publier Mythos immédiatement, mais de le fournir d’abord de manière limitée à certaines entreprises afin de leur laisser le temps de corriger des problèmes importants
• Dans le cadre du project Glasswing, Anthropic a également donné, via la Linux Foundation, un accès à son modèle d’IA le plus récent à des « projets open source »
• La Linux Foundation a confié cette partie à Alpha Omega, et la proposition a été transmise à Daniel Stenberg, développeur principal de curl
• Le contrat d’utilisation a bien été signé, mais l’accès effectif a été retardé ; au final, quelqu’un d’autre disposant d’un accès à Mythos a scanné et analysé curl avant de transmettre le rapport

L’analyse de sécurité IA de curl était déjà en cours

• Avant même le rapport de Mythos, curl faisait déjà l’objet d’analyses par plusieurs outils basés sur l’IA, tout en continuant à utiliser des analyseurs de code statique classiques, des options de compilation strictes et des années de fuzzing
• Les principaux outils d’inspection IA du code de curl étaient AISLE, Zeropath et OpenAI’s Codex Security
• Au cours des 8 à 10 derniers mois, leurs analyses ont conduit à l’intégration de 200 à 300 corrections de bugs dans curl
• Parmi les éléments signalés par ces outils d’IA, certains se sont révélés être de vraies vulnérabilités et ont été publiés sous forme de CVE, au nombre de « probablement plus de 12 »
• GitHub Copilot et Augment code sont également utilisés pour la revue de pull requests, aidant à corriger les problèmes signalés et à fusionner un meilleur code
• Les revues IA ne remplacent pas la revue humaine ; elles servent de moyen de vérification supplémentaire et contribuent à améliorer la qualité des fusions
• Les chercheurs en sécurité utilisent eux aussi l’IA de manière large et efficace, et de nombreux rapports de sécurité de haute qualité arrivent
• Dans le projet curl, la sécurité est la priorité absolue, avec de multiples règles et procédures d’ingénierie logicielle appliquées pour réduire les défauts
• Le scan de défauts n’est qu’une des nombreuses étapes destinées à garder curl sûr ; il semble difficile de trouver un projet qui fasse autant, voire plus, pour la sécurité logicielle que curl

Premiers résultats de l’analyse de Mythos, le 6 mai 2026

• Le premier rapport d’analyse du code source généré par Mythos a offert à curl une occasion d’identifier des axes d’amélioration et des bugs à corriger
• Le scan initial a été réalisé sur le dépôt git de curl et un commit récent précis de la branche master
• L’analyse portait sur 178 000 lignes de code dans les sous-répertoires src/ et lib/
• Le rapport décrivait en détail les différentes approches et méthodes employées pour tenter de trouver des défauts
• En tête du rapport, il était indiqué que curl était l’une des bases de code C les plus fuzzées et auditées, ayant déjà reçu « OSS-Fuzz, Coverity, CodeQL, plusieurs audits payants », et qu’il serait difficile de trouver quelque chose dans les chemins critiques de HTTP/1, TLS et du parsing d’URL
• Mythos n’a effectivement trouvé aucun problème réel dans ces chemins critiques

Taille de la base de code curl et historique de sécurité

• En excluant les lignes vides, curl se compose actuellement de 176 000 lignes de code C
• Le code source représente 660 000 mots, soit 12 % de plus que l’intégralité du roman Guerre et Paix en anglais
• Chaque ligne de code source de production dans curl a été écrite puis réécrite en moyenne 4,14 fois
• Le code de production historique encore présent dans le git master actuel a été écrit par 573 contributeurs distincts
• À ce jour, des changements proposés par 1 465 contributeurs au total ont été fusionnés dans le dépôt git de curl
• curl a publié jusqu’à présent 188 CVE
• curl est installé sur plus de 20 milliards d’instances
• curl fonctionne sur plus de 110 systèmes d’exploitation et 28 architectures CPU
• curl tourne sur des smartphones, des tablettes, des voitures, des téléviseurs, des consoles de jeu et des serveurs

Les « 5 vulnérabilités confirmées » ramenées en réalité à 1

• Le rapport de Mythos concluait avoir trouvé 5 « Confirmed security vulnerabilities »
• Après quelques heures d’examen détaillé par l’équipe sécurité de curl, une seule des cinq est restée comme vulnérabilité réellement confirmée
• Parmi les 4 restantes, 3 ont été considérées comme des faux positifs pointant des limites déjà documentées dans l’API
• La dernière a été jugée non pas comme une vulnérabilité, mais comme un bug ordinaire
• L’unique vulnérabilité confirmée donnera lieu à un CVE de faible gravité (severity low)
• Ce CVE doit être publié fin juin, en même temps que la prochaine version de curl, 8.21.0
• Les détails de cette vulnérabilité ne seront pas divulgués avant sa publication
• Le rapport de Mythos contenait aussi plusieurs bugs finalement considérés comme n’étant pas des vulnérabilités, et l’équipe curl enquête et corrige un à un les points qu’elle juge valides
• Le rapport répertoriait proprement environ 20 bugs, avec très peu de faux positifs
• Grâce à ce rapport, curl s’améliore, mais en nombre de découvertes, les outils d’IA utilisés auparavant avaient conduit à davantage de corrections de bugs
• Cela reflète aussi le fait que les premiers outils ont trouvé en premier plus de bugs et des bugs plus simples, tandis que les problèmes ont été corrigés au fil du temps, rendant la découverte de nouveaux défauts de plus en plus difficile
• Un bug peut être petit ou important ; comparer uniquement les chiffres n’est donc pas toujours équitable

Mythos ne semble pas être à un niveau « dangereux » particulier

• Si l’on se limite aux résultats de l’analyse de curl, le fort engouement autour de Mythos paraît relever surtout du marketing
• Rien n’indique que la configuration de Mythos trouve des problèmes à un niveau particulièrement supérieur ou plus sophistiqué que les outils précédents
• Il est possible que Mythos soit légèrement meilleur, mais pas au point de produire une différence majeure dans l’analyse de code
• Cette évaluation reste toutefois limitée aux résultats obtenus sur un seul dépôt de code source, celui de curl
• Il n’est pas exclu que Mythos soit bien meilleur sur d’autres cibles

Les analyseurs de code IA restent extrêmement puissants

• Les analyseurs de code basés sur l’IA sont nettement plus performants que les analyseurs traditionnels du passé pour trouver des failles de sécurité et des erreurs dans le code source
• Les modèles d’IA modernes sont tous bien adaptés à cette tâche, et quiconque dispose de temps et d’une volonté d’expérimentation peut trouver des problèmes de sécurité
• Le chaos de haute qualité est bel et bien en cours
• Les projets qui n’ont pas encore scanné leur code source avec des outils fondés sur l’IA ont de fortes chances de découvrir de nombreux défauts, bugs et vulnérabilités potentielles grâce à cette génération d’outils
• Pas seulement Mythos : de nombreux autres outils d’IA peuvent produire ce type de résultats
• Si un projet n’utilise pas d’analyseur de code IA, il laisse du temps et des opportunités aux attaquants et acteurs malveillants pour trouver et exploiter des défauts encore inconnus

Ce qui distingue les analyseurs IA des analyseurs classiques

• Les analyseurs IA peuvent détecter les cas où les commentaires disent une chose sur le code alors que le comportement réel du code en indique une autre
• Ils peuvent inspecter du code destiné à des plateformes et configurations sur lesquelles il n’est généralement pas possible d’exécuter les analyseurs
• Ils « connaissent » les détails des bibliothèques tierces et des API, ce qui leur permet de repérer les mauvais usages ou les hypothèses erronées
• Ils « connaissent » les détails des protocoles implémentés par curl, et peuvent donc signaler les endroits où le code semble violer ou contredire leurs spécifications
• Ils font généralement bien le travail fastidieux et difficile de synthèse et d’explication des défauts détectés, souvent pénible avec les analyseurs classiques
• Ils peuvent générer et proposer des patchs pour les problèmes trouvés, même si ces patchs ne constituent généralement pas une correction complète à 100 %

Détails du rapport Mythos

• Le rapport de Mythos conclut à 0 vulnérabilité de sûreté mémoire
• Sur le plan méthodologique, cette revue était une analyse pilotée manuellement, avec des sous-agents LLM effectuant des lectures de fichiers en parallèle
• Toutes les découvertes candidates ont été revérifiées avant consignation par une inspection directe du code source dans la session principale
• La cartographie des CVE et la recherche de variantes ont été construites à partir du vuln.json propre à curl
• Aucun outil SAST automatisé n’a été utilisé
• Ce résultat est cohérent avec le fait que curl est l’une des bases de code C les plus fuzzées et auditées qui soient
• L’infrastructure défensive de curl ferme systématiquement les types de bugs qui produisent généralement des résultats sur une base de code de cette taille
• Parmi les éléments défensifs figurent dynbuf limité, curlx_str_number avec des maximums explicites pour tout parsing numérique, curlx_memdup0 avec garde anti-overflow, l’application des chaînes de format CURL_PRINTF, des limites de taille de réponse par protocole et la limite de ligne de 64 KB de pingpong
• La couverture inclut tous les petits protocoles, tous les parseurs de fichiers, tous les chemins de validation des backends TLS, HTTP/1·2·3, toute la profondeur de FTP, mprintf, x509asn1, DoH, tous les mécanismes d’authentification, l’encodage de contenu, la réutilisation de connexions, le cache de session, l’outil CLI, le code spécifique aux plateformes ainsi que la chaîne d’approvisionnement CI et build

L’IA redécouvre de nouveaux cas d’erreurs déjà connues

• Les outils d’IA trouvent des erreurs de types généraux et bien établis déjà connus, en découvrant simplement de nouveaux cas
• Jusqu’à présent, l’IA n’a pas signalé de type de vulnérabilité totalement nouveau ni de catégorie de faille inédite
• L’IA ne réinvente donc pas la sécurité elle-même de cette manière
• En revanche, elle déterre plus de problèmes que n’importe quel outil antérieur

La chasse aux défauts n’est pas terminée

• Ce résultat ne constitue pas la dernière découverte ni le dernier rapport de bug
• Même à ce moment-là, des chercheurs en sécurité envoyaient encore des signalements supplémentaires de problèmes suspects
• Les outils d’IA vont continuer à s’améliorer, et les chercheurs pourraient découvrir des approches de prompt nouvelles et différentes pour pousser les IA existantes à trouver davantage de problèmes
• curl espère continuer à subir des scans répétés avec Mythos et d’autres IA, jusqu’à ce qu’aucun nouveau problème ne sorte réellement

[GN⁺]

Réactions sur Hacker News

• Citation : « Je ne vois pas quelle autre conclusion tirer que le fait que l’énorme emballement autour de ce modèle relevait surtout du marketing. Je n’ai vu aucun élément montrant que cette configuration trouve des problèmes à un niveau sensiblement supérieur ou d’une manière plus sophistiquée que les outils antérieurs à Mythos. C’est peut-être un peu mieux, mais pas au point de sembler changer de façon significative l’analyse de code »
  Cela rappelle à tout le monde que la concurrence dans ce domaine est rude, et qu’elle s’accompagne de beaucoup de marketing, explicite ou plus subtil

  • Pas vraiment surprenant qu’Anthropic utilise le marketing pour convaincre que son modèle est plus avancé, mieux conçu, que l’IA représente une menace nécessitant une régulation, et qu’eux seuls ont la réponse
    Plus sérieusement, jusqu’ici j’ai vu peu de signes montrant que Mythos soit autre chose qu’Opus avec un dispositif d’analyse de code orienté sécurité. Cela dit, le fait même que ce genre de bug puisse être trouvé automatiquement est plus important que le battage publicitaire
    Je serais curieux de connaître le taux de faux positifs. Si 90 % est erroné et qu’on n’entend parler que des cas exploitables en marketing, cela n’a pas beaucoup de sens
  • C’est à peu près le résultat auquel je m’attendais, mais le grand indice, c’est que des outils existants basés sur des LLM étaient déjà utilisés sur des codebases largement auditées
    Donc oui, le marketing d’Anthropic est peut-être exagéré, mais il ne restait peut-être déjà plus grand-chose à trouver, et l’article le dit aussi
    Il est difficile de juger s’il s’agit d’une grande avancée pour d’autres types de projets, mais il devient clair que tout le monde devrait dès aujourd’hui utiliser des outils d’IA de revue de code pour auditer du code existant, alors qu’en pratique ce n’est pas encore le cas
  • curl n’est pas un bon point de référence. C’est l’une des codebases les plus disséquées qui existent, avec des pratiques de tests de sécurité extrêmement solides
    Des chercheurs utilisant des modèles similaires, sans être identiques à Mythos, ont déjà eu largement le temps de signaler des bugs. Daniel a peut-être raison de penser que Mythos n’a pas changé la donne pour curl, mais pour presque toutes les autres codebases, les conditions de départ sont différentes. Le vrai marketing, c’est peut-être plutôt sa modestie sur la maturité de curl
  • Mozilla fait le marketing d’Anthropic à sa place ?
    Dans le cadre d’une collaboration continue avec Anthropic, nous avons eu l’occasion d’appliquer une première version de Claude Mythos Preview à Firefox. La version 150 de Firefox publiée cette semaine inclut des correctifs pour 271 vulnérabilités identifiées lors de cette évaluation initiale
    À mesure que cette capacité arrive entre les mains d’un plus grand nombre de défenseurs, beaucoup d’équipes vivent le même vertige que nous lorsque les premiers résultats sont devenus clairs. Même un seul bug de ce type dans une cible très robuste aurait déjà été une alerte rouge en 2025 ; en voir autant d’un coup oblige à se demander si l’on peut réellement suivre le rythme
    https://blog.mozilla.org/en/privacy-security/ai-security-zer...
  • Il est tout à fait possible que l’emballement relevait surtout du marketing
    L’autre possibilité, c’est que curl soit suffisamment sûr et qu’il y ait donc bien moins à trouver que dans d’autres projets

• Je suis d’accord avec l’idée d’un « événement marketing remarquablement réussi ». Anthropic a bien joué le coup
  Cela a atteint jusqu’au RSSI d’une petite organisation semi-publique néerlandaise, qui a un peu paniqué à l’annonce du tsunami de vulnérabilités censé accompagner Mythos
  Grâce à cela, j’ai obtenu davantage de budget et de priorité au conseil d’administration. Il ne faut pas gâcher une bonne frayeur marketing

  • Je ne suis pas d’accord avec « on ne voit pas de tsunami ». Entre plus de 100 bugs dans Firefox, davantage de projets open source, d’anciennes vulnérabilités d’exécution de code à distance sur OpenBSD/Linux jamais vues auparavant, et même quelques élévations locales de privilèges dans Linux en seulement deux ou trois semaines
    Cela ressemble moins à une panique marketing qu’à une hausse détectable des divulgations de vulnérabilités de haute qualité avec peu de faux positifs. On a l’impression d’accélérer en quelques semaines ce qui aurait représenté plusieurs années de rapports de bugs de qualité
  • Anthropic est en train de ruiner rapidement le capital sympathie de ses clients en répétant toujours la même manœuvre. Personnellement, je trouve que c’est un marketing affreux
    Qu’une entreprise étudie les menaces de cybersécurité liées aux LLM en général, c’est une chose ; qu’elle redirige ensuite la discussion vers « notre nouveau modèle est si puissant », c’en est une autre. C’est poisseux et désagréable
  • Il explique en détail que curl a été extrêmement affiné du point de vue de l’ingénierie logicielle. Pense-t-on vraiment que la majorité du code est aussi polie que cela ?

• Si un agent IA trouve 0 bug dans un utilitaire logiciel donné, pourquoi faudrait-il y voir que cet agent IA est médiocre pour trouver des bugs ?
  Et s’il y avait réellement 0 bug ?
  L’attente selon laquelle « cinq problèmes nous ont paru insignifiants alors que nous nous attendions à une longue liste » ne correspondait peut-être simplement pas à la réalité. Mais cela ne veut pas forcément dire que les capacités de Mythos sont inférieures à ce qui était annoncé. curl est peut-être simplement un outil durci qui, dans son état actuel, n’a pas beaucoup de vulnérabilités de sécurité

  • L’auteur du billet a aussi envisagé ce point au sujet des bugs restants
    « D’autres choses à trouver. Ce ne sont absolument pas les derniers bugs qu’ils trouveront ou signaleront. Pendant que je rédigeais ce brouillon, j’ai encore reçu de la part de chercheurs en sécurité des signalements sur des problèmes suspects. Les outils d’IA vont encore s’améliorer, et les chercheurs trouveront de nouvelles manières de formuler leurs prompts pour amener les IA actuelles à trouver davantage. Nous ne sommes pas au bout. J’espère que nous pourrons continuer à scanner curl avec Mythos et d’autres IA de façon répétée, jusqu’à ce qu’il devienne réellement impossible de trouver de nouveaux problèmes »
    C’est cohérent. Supposer qu’il ne restait précisément qu’une seule vraie découverte, qu’elle n’a été trouvée que par Mythos exactement au moment de sa sortie, tandis que tous les autres projets ramassaient juste avant toutes les découvertes possibles, exige une coïncidence assez énorme. C’est possible, mais ce n’est pas le point de départ le plus sûr quand on cherche à remettre en cause l’hypothèse

• Il est difficile de ne pas voir curl comme un outil relativement simple et bien délimité par nature. Il suffit de le comparer à un système d’exploitation, un navigateur web, une base de données ou la codebase d’une entreprise valant des dizaines de milliards
  Il est donc plausible que Mythos/ChatGPT 5.5 soit bien meilleur sur une complexité qui n’existe pas dans curl. curl a énormément de fonctionnalités en tant que « client capable de tout faire », mais sa complexité reste de plusieurs ordres de grandeur inférieure à celle d’autres logiciels dont nous dépendons

  • curl est bien plus complexe qu’on ne l’imagine. La plupart des gens le connaissent seulement comme un outil en ligne de commande qui appelle des endpoints HTTP(S) et affiche la sortie, mais en réalité il prend en charge presque tous les protocoles de transfert de fichiers et c’est une bibliothèque conçue pour des processus de longue durée
    Comme il est pensé pour des processus de longue durée, il emploie toutes sortes de techniques possibles pour mettre en pipeline et réutiliser les connexions et les ressources. Il propose aussi des API asynchrones pour s’intégrer à des boucles d’événements existantes
    Est-ce qu’un navigateur web ou une base de données est plus complexe ? Oui, très probablement. Ils résolvent des problèmes immenses. Mais curl est sans aucun doute plus complexe que la plupart du code applicatif qui l’utilise
  • Je suis d’accord sur le fait que c’est un outil assez basique, mais comme l’article le souligne, sa longueur de code dépasse Guerre et Paix. À cette échelle, il reste largement de quoi introduire des vulnérabilités de sécurité
  • Pour citer l’article : « curl représente actuellement 176 000 lignes de code C hors lignes vides. Le code source totalise 660 000 mots, soit 12 % de plus que l’édition anglaise complète du roman Guerre et Paix »
    « curl est installé sur plus de 20 milliards d’instances. Il tourne sur plus de 110 systèmes d’exploitation et 28 architectures CPU. Il fonctionne sur tous les smartphones, tablettes, voitures, téléviseurs, consoles de jeu et serveurs de la planète »
    Difficile d’appeler cela simple ou bien délimité. La plupart des systèmes d’exploitation ou navigateurs web ne tournent même pas dans les voitures ou les téléviseurs

• La conclusion « pas particulièrement dangereux » ne me paraît pas vraiment découler de tout cela. Comme cela a été mentionné, curl a déjà été analysé de fond en comble avec tous les outils disponibles, ce qui est loin d’être le cas de la plupart des logiciels

  • Mais Mythos est présenté non pas comme un outil qui fait un peu mieux ce que les outils existants savent déjà faire, mais comme une révolution
  • Mythos est soit dangereux, soit non dangereux. Ici, dangereux signifie « trouve bien plus de vulnérabilités que celles trouvées avec les outils disponibles »
    Mythos n’a trouvé qu’une vulnérabilité supplémentaire, et x+1 n’est pas beaucoup plus grand que x ; selon cette définition, la conclusion est donc que Mythos n’est pas dangereux
  • Oui, mais n’est-ce pas alors un jugement de Mythos comparé à d’autres modèles ?
    Dans ce cas, la conclusion tient toujours. « La plupart des logiciels » n’ont pas été analysés autant que curl, ni avec d’autres outils ni avec d’autres modèles. Si ces outils peuvent produire à peu près les mêmes résultats que Mythos, il est difficile de considérer Mythos comme particulièrement dangereux
  • Est-ce que « pas particulièrement dangereux » ne portait pas plutôt sur les vulnérabilités découvertes ? Ils savent probablement mieux que quiconque ce qu’ils considèrent comme une faible gravité
  • curl reçoit actuellement un volume record de signalements de bugs/vulnérabilités de haute qualité. C’est un changement assez net par rapport aux anciennes vagues de faible qualité, donc cela ne signifie pas qu’il n’y a plus rien à trouver
    Beaucoup, voire la plupart, semblent avoir été trouvés par des experts humains aidés par des outils d’IA, mais si Mythos est vraiment révolutionnaire, il devrait être capable de trouver ce genre de problèmes par lui-même
    https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/, lié dans l’article original

• Le passage « la vulnérabilité unique confirmée devrait recevoir un CVE de faible gravité et sera divulguée en même temps que la prochaine version de curl 8.21.0 prévue fin juin » m’a marqué
  J’ai toujours du mal à saisir le niveau de qualité et de finition atteint par cURL. C’est l’exemple parfait d’un logiciel tellement bien fait que les gens n’y pensent presque jamais à deux fois

  • C’est simple. Cela montre ce qui est possible quand on applique des standards de qualité élevés à chaque ligne de code commitée, relue et fusionnée, quelle que soit l’implémentation ou le langage
    Mais à l’ère de la course au moins-disant, de l’offshore low cost, et maintenant de la génération de code par LLM, la plupart des entreprises ne se soucieront pas de cette qualité tant qu’il n’y aura pas de responsabilité clairement engagée
  • curl et SQLite sont mes exemples préférés de ce qu’on obtient quand « n’importe quoi » est correctement conçu et rigoureusement testé. C’est presque philosophique
    Les exigences de contribution de ces projets imposent cette rigueur, et les mainteneurs les font respecter. Ce qui rend cela possible, c’est de la documentation qui ne fait pas partie de la charge utile, c’est-à-dire des documents qui ne sont pas le code du projet lui-même. Cela me fait penser aux expériences de pensée d’Einstein ayant conduit à des projets concrets comme le GPS, ou à la conviction de Descartes que tout problème peut être résolu par un raisonnement rationnel
  • C’est ironique de voir un logiciel aussi bien conçu finir avec des gens qui font curl ... | bash sans y voir de problème
    Puis ils se défaussent avec des termes comme « modèle de menace »
    Moi, je passe mon tour sur le curl-bash et j’utilise un installateur de paquets signé cryptographiquement

• Je sais que l’emballement autour de Mythos fait partie du marketing d’Anthropic, mais si l’on parle d’une codebase extrêmement relue, n’est-il pas possible qu’il n’y ait tout simplement plus, à l’heure actuelle, d’exploit de sécurité notable ?
  Le fait de ne rien trouver n’est pas forcément une preuve à charge. Surtout si d’autres outils avaient déjà identifié des centaines de vulnérabilités auparavant. À ce stade, tout semble avoir été fouillé de fond en comble

• Le marketing est toujours présent, et les gens doivent savoir le remettre dans son contexte
  Par ailleurs, curl est un projet open source, relativement petit mais critique, bien connu et utilisé partout. En dehors des bibliothèques d’images, curl, sudo, su ou passwd feraient aussi partie des premiers outils que j’essaierais
  On ne sait encore absolument pas ce que Mythos peut réellement faire. Que signifie un modèle à 10 000 milliards de paramètres en termes de coût et de benchmarks ?
  Cela dit, si les LLM ont commencé à devenir bien meilleurs que les humains pour trouver ce type de problèmes il y a environ six mois, alors à un moment il faut regarder en face ce que tout le monde évitait. Aujourd’hui, il faut ajouter les LLM aux scans de sécurité et prendre cela au sérieux
  Dans le pire des cas, on peut quand même utiliser le marketing d’Anthropic pour dire que c’est désormais indispensable et que quelque chose a changé

  • Sur la question « que signifie un modèle à 10 000 milliards de paramètres en termes de coût et de benchmarks ? », pour moi cela signifie qu’on a atteint le sommet de la courbe en S des effets d’échelle
    Si, à cette taille, l’outil n’est pas sensiblement meilleur, alors on est clairement entré dans la zone des rendements décroissants
  • Le fait qu’« on ne sache encore absolument pas ce que Mythos peut faire » est intentionnel. Mais il suffit de voir ce que les gens croient déjà qu’il peut faire
  • L’affirmation selon laquelle « les LLM sont devenus bien meilleurs que les humains pour trouver ce type de problèmes » me fait lever les yeux au ciel. Les analyseurs statiques classiques sont meilleurs que les humains depuis des décennies pour certaines tâches mécaniques précises, et être meilleur que l’humain sur une tâche mécanique précise ne veut pas dire grand-chose
    Ce qui est nouveau et intéressant, ce sont les types potentiels de « bugs flous » que, comme l’article l’explique, les LLM peuvent repérer : par exemple quand le code ne correspond pas à ce que décrivent les commentaires, quand une bibliothèque tierce est utilisée d’une manière inhabituelle, quand le code diverge du protocole qu’il implémente, ou simplement quand quelque chose paraît étrange et mérite qu’un humain regarde de plus près. Cela comble un vide dans la boîte à outils traditionnelle du débogage, mais ne doit pas les remplacer

• De ce que je comprends, le message autour de Mythos est qu’il met l’expertise des meilleurs spécialistes en sécurité et des meilleurs experts des langages, protocoles et code à la portée de toute personne ayant accès à l’outil
  Le danger venait du fait de donner cet accès au monde entier avant que les défenseurs eux-mêmes n’aient accès à ce niveau d’expertise
  curl est au centre de tout, donc des spécialistes en sécurité, protocoles et langages l’examinent depuis des années. Le fait que Mythos ait trouvé quelque chose est intéressant, mais ce n’est pas un signal indiquant qu’il ne s’agit que de battage marketing et que ce n’est pas dangereux
  On peut considérer que 99,99 % des projets ne sont pas aussi sûrs que curl, qu’ils soient open source ou propriétaires. Les LLM n’hésiteront pas à décompiler et explorer aussi des projets propriétaires. Si un projet n’a pas été fuzzé ni revu par des outils d’IA existants et par des experts, il faut partir du principe qu’il peut déjà être compromis. C’est vrai avec les outils actuels, et un système comme Mythos rend simplement ce type de capacité accessible à un public plus large et moins expert

  • D’accord. Anthropic n’a jamais revendiqué une performance surhumaine, seulement la vitesse et l’échelle
    Le fait de ne pas trouver beaucoup de nouvelles vulnérabilités dans un logiciel déjà très étudié ne dit rien sur le potentiel global d’abus dangereux

• À lire « curl est l’une des codebases C les plus fuzzées et auditées qui existent. Il y a eu OSS-Fuzz, Coverity, CodeQL et plusieurs audits payants. Trouver quelque chose dans les hot paths HTTP/1, TLS, et le cœur du parsing d’URL est difficile »
  Cette formulation donne l’impression non pas que le LLM a essayé puis échoué, mais qu’il a renoncé avant même d’essayer. J’ai souvent vu Claude faire cela si on ne le pousse pas explicitement à aller jusqu’au bout, donc je me demande ce qui s’est réellement passé ici

[GN⁺]

Commentaires sur Lobste.rs

• Pris isolément, ce n’est pas si surprenant, mais il faut sans doute voir ce résultat comme le fait que « après que les modèles précédents ont été attaqués presque tous les jours, un problème de sécurité a été trouvé en une seule exécution dans l’une des applications les plus examinées qui soient »

  • Le fait de « faire tourner en continu des analyseurs statiques de code classiques, d’utiliser les options de compilation les plus strictes et de pratiquer le fuzzing pendant des années » est en réalité quelque chose que très peu d’endroits font, contrairement à ce qu’on pourrait croire
    Il faut peut-être désormais se préparer à une période sombre où la sécurité diminue, voire disparaît, jusqu’à ce que tout soit réécrit
  • Il est vrai que les LLM deviennent compétents pour trouver des vulnérabilités, mais je ne vois pas pourquoi décrire curl comme l’une des applications les plus auditées
    curl avait un programme de bug bounty et a attiré un certain niveau de recherche, mais cela a aussi eu pour effet que Daniel s’est retrouvé enseveli sous des signalements de déchets générés par l’IA. Que ce soit publiquement ou en privé, cela n’a jamais été une cible de tout premier plan pour la recherche de vulnérabilités
    Cela n’entre pas dans la catégorie « on ne trouvera rien ici quoi qu’il arrive », surtout si l’on peut y consacrer des ressources de calcul massives quasi subventionnées
  • La vulnérabilité est aussi de faible gravité
    D’après le billet de blog, « la seule vulnérabilité confirmée devrait devenir un CVE de faible gravité, qui sera publié avec la prochaine version de curl 8.21.0 prévue fin juin »
    Il est également indiqué qu’il y avait 4 faux positifs

• « Finalement, une autre personne ayant accès au modèle m’a proposé d’exécuter à ma place les scans et analyses de curl avec Mythos et de m’envoyer un rapport. Pour moi, la différence n’avait pas tant d’importance. Je n’aurais de toute façon pas eu beaucoup de temps pour explorer divers prompts et creuser le sujet. »
  C’est exactement le genre de comportement qu’on adopte quand on fait tourner une machine à hype qui livre moins que promis : « Essayez notre truc ! Non, enfin, pas exactement vous-même. On va le faire pour vous ! » Et en coulisses, ce sont les méthodes traditionnelles et coûteuses qui tournent
  Je ne sais pas si c’était le cas ici aussi, mais je ne pense pas que cette possibilité soit négligeable. Je me demande qui d’autre s’est vu proposer d’utiliser Mythos sans en fait pouvoir utiliser Mythos directement, en ne recevant que les résultats

  • Ils ont peut-être simplement acheté une vulnérabilité du marché noir et l’ont présentée comme trouvée par Mythos. Dans ce cas, ce n’est qu’un point de données recraché par l’IA
    Il est même possible qu’une grande partie de ce type de découvertes soit discutée sur des forums obscurs que les mainteneurs ne fréquentent guère
    Cela ne veut pas dire que l’IA ne peut pas rendre les logiciels plus sûrs. Mais si les entreprises d’IA cachent trop bien leur jeu, il devient impossible de savoir ce qui est réel
  • Je me demande si l’on a aussi cherché des explications alternatives qui ne confirment pas simplement les idées préexistantes sur Anthropic

• Il y a trois mois, j’ai vu cette personne annoncer sur scène qu’elle mettait fin au programme de bug bounty à cause des signalements de déchets générés par l’IA
  Je me demande si l’outil s’est vraiment autant amélioré, ou si le fait qu’il n’y ait plus de motivation financière pousse simplement les gens à passer plus de temps à distinguer les vraies vulnérabilités des déchets

  • Il en parle ici : https://daniel.haxx.se/blog/2026/04/22/high-quality-chaos/ . Cela dit, les signalements de déchets semblent effectivement s’être arrêtés

• En regardant Mastodon, ce genre de résultat se prête bien à l’emballement du biais de confirmation
  Mais si l’on met de côté ce biais, cela ne me paraît pas approprié à généraliser. Cela dit, c’est bien que ce point de données soit rendu public

  • Je ne sais pas à quel point cela s’applique à Mastodon dans son ensemble, mais autour de moi l’ambiance est tellement anti-IA que même des gens expérimentés jettent juste un lien GitHub dans l’interface de chat de Claude pour montrer que c’est inutile
    Or, ce n’est pas un outil qu’on utilise comme ça. Même quand on essaie de montrer des résultats aux gens, ils veulent seulement pointer les échecs et en rire, donc c’est vraiment difficile

• J’aimerais voir davantage d’articles de ce genre
  Le fait qu’un seul problème de faible gravité ait été trouvé dans curl est encourageant, mais cela reste un cas isolé. Il est aussi possible que curl soit simplement plus mature que d’autres bibliothèques essentielles

• « Le monde entier semblait avoir perdu la tête. Était-ce la fin du monde tel que nous le connaissions ? C’était assurément un coup de marketing étonnamment réussi. »
  Ce genre de style ne m’intéresse pas. J’aimerais voir une pensée claire et un raisonnement solide. Il faut interpréter cela de bonne foi
  Sans bonnes preuves ni bon raisonnement, dire que Glasswing était « un coup de marketing » relève de la supposition. Je comprends le scepticisme sain, mais un scepticisme sain doit aussi se retourner contre soi-même. Sur quelle base peut-on en être si certain ?
  Si quelque chose est un coup, qu’est-ce que cela veut dire exactement ? Quand je lis le mot « coup », j’y entends la nuance d’une intention de manipulation. Les personnes les mieux placées pour parler directement d’intention sont « celles qui étaient dans la pièce ». Les autres ne font au mieux que des prédictions, mais trop de gens ne traitent même pas leurs prédictions comme telles et les présentent comme des faits
  Si l’on n’était pas présent, il est plus sage d’expliquer son raisonnement que d’affirmer
  Les incitations vont dans plusieurs directions. Je ne suis pas naïf. Mais d’un auteur sérieux, j’attends qu’il respecte l’intelligence du lecteur et son désir de comprendre le monde
  Il est fréquent qu’un expert d’un domaine s’aventure avec trop d’assurance dans un autre et se trompe. Sur quelle base faudrait-il penser que le mainteneur de curl possède en général, et en particulier concernant le statut du projet qu’il maintient, de bons critères épistémologiques ? Les humains ont souvent une forte incitation à ne pas vouloir qu’une machine fasse mieux qu’eux. Cela ne veut pas dire que Mythos en soit déjà là. Je suspends mon jugement sur ce point. Mais si l’on s’en tient au raisonnement montré dans ce texte, il m’est difficile d’être impressionné par l’auteur

  • Je ne suis pas d’accord avec l’idée qu’il soit prématuré de dire que Glasswing était un coup de marketing. Si l’on regarde ce qui suit immédiatement la phrase « un coup de marketing réussi », cela me paraît être une critique équitable
    « Dans le cadre du projet Glasswing, Anthropic a aussi fourni, via la Linux Foundation, un accès à ses modèles d’IA les plus récents à des “projets open source”. La Linux Foundation a confié cette partie au projet Alpha Omega, dont des représentants m’ont contacté. En tant que développeur principal de curl, on m’a proposé l’accès au modèle magique, et j’ai accepté avec plaisir. Bien sûr, je voulais voir ce qu’il était possible de trouver dans curl. »
    À la lecture de l’ensemble du texte, je n’ai pas eu l’impression que l’auteur disait que Glasswing était uniquement un coup de marketing, mais plutôt que, comme coup de marketing, c’était clairement un succès, et que le reste restait à déterminer
    Le reste du texte après la citation indique qu’il y avait plus qu’un simple marketing, et conclut même que c’était « toujours très bien ». L’idée était que cela a de fortes chances d’être utile, même si cela n’est pas à la hauteur de l’hyperbole marketing haletante reçue jusqu’ici
  • Peu après, OpenAI a publié une nouvelle version de modèle selon son cycle habituel de mises à niveau, et elle a montré des capacités similaires dans ce domaine, sans fanfare ni agitation particulière
    C’était simplement GPT-5.5. En ce sens, je pense que le fait d’avoir caché Mythos en invoquant sa prétendue dangerosité visait peut-être à concentrer l’attention sur les cas d’usage en sécurité et à créer une nouvelle demande