Mythos affirmait qu'il ne restait rien dans curl. Une startup y a trouvé six CVE
By Surya Pratap
24 septembre 2026
10 min read
AI & Technology
24 septembre 2026
10 min read
Zéro, puis vingt-neufHover to exploreLe 24 août, Daniel Stenberg, qui maintient curl, a publié deux courtes lignes d'état. Mythos, d'Anthropic, « dit ne plus rien trouver ». Codex Security, d'OpenAI, « affiche une liste vide ». Le lendemain, il publiait un tableau d'affichage : Mythos: 0 / Aisle: 29.
Six de ces vingt-neuf rapports sont devenus des CVE, corrigées dans curl 8.22.0 le 2 septembre. La plupart des articles en ont tiré une variante de une startup bat OpenAI et Anthropic. C'est vrai, dans une certaine mesure. C'est aussi la leçon la moins utile de l'épisode.
Les chiffres de cet article proviennent du récit d'AISLE sur ses découvertes d'août (2 septembre 2026), du tableau des vulnérabilités de curl, du compte rendu de Daniel Stenberg sur l'analyse de Mythos (11 mai 2026) et de l'article de ZDNET (4 septembre 2026). AISLE est un éditeur qui décrit son propre résultat ; les avis de sécurité de curl constituent la vérification indépendante. L'interprétation, à partir de la section 3, est la mienne.
La chronologie est assez courte pour être donnée en entier.
Anthropic et Alpha-Omega ont passé Mythos sur le code. Il a signalé cinq « vulnérabilités de sécurité confirmées ». L'équipe sécurité de curl les a examinées et en a gardé une, de gravité faible. Trois étaient des faux positifs décrivant un comportement documenté de l'API, une n'était « qu'un bug », et l'analyse a fait ressortir une vingtaine d'autres bugs sans lien avec la sécurité. Le verdict de Stenberg : l'engouement autour du modèle relevait « surtout du marketing », et Mythos était peut-être « un peu meilleur » que les outils précédents, sans plus.
Mythos ne trouve plus rien. Codex Security : liste vide. ZDNET précise que ZeroPath, un autre scanner à base d'IA, n'avait rien trouvé de nouveau non plus.
Au 28 août, le nombre de CVE en attente chez curl était passé de trois à dix, dont six venant d'AISLE.
Le tableau de curl liste les six : un use-after-free dans le provider OpenSSL, un contournement du pinning OpenSSL, une réutilisation de connexion avec le magasin de CA natif, un contournement de l'attribut secure des cookies au moyen d'une tabulation, un succès de cache de CA wolfSSL qui écrase un callback, et un cookie de domaine posé sur un suffixe public. Les six sont de gravité faible. Certaines remontent loin : le contournement du pinning touche toutes les versions depuis la 7.45.0.
AISLE affirme par ailleurs s'être vu attribuer six CVE dans la version de juin, la 8.21.0, dont une qu'elle présente comme la plus ancienne vulnérabilité jamais signalée dans curl, introduite en mars 2001. Je n'ai pas pu vérifier cette attribution sur les pages de curl lui-même ; je la laisse donc hors de l'argument.
Greg Kroah-Hartman, mainteneur de la branche stable du noyau Linux, a ajouté la phrase qui a fait sortir l'histoire du seul cas de curl : « Je vois la même chose pour Linux. Aucune idée de ce qu'Aisle fait différemment, mais waouh… »
Voici les deux passes sur curl pour lesquelles assez de chiffres ont été publiés pour comparer :
Ce n'est pas la même mesure. Les cinq de Mythos étaient déjà présentées comme des vulnérabilités confirmées, alors que les 29 d'AISLE étaient des rapports, et une partie des 23 autres pouvaient être de vrais bugs plutôt que du bruit. Mais l'idée générale résiste à cette réserve : AISLE n'a pas gagné sur la précision. Les deux systèmes ont soumis au mainteneur environ quatre rapports non confirmés pour chaque découverte réelle.
La différence n'est pas qu'AISLE avait raison plus souvent. C'est qu'AISLE cherchait encore quand les autres outils s'étaient arrêtés.
Cela change le sujet de l'histoire. Un modèle de pointe qui tourne, rapporte ce qu'il a trouvé puis déclare qu'il ne reste rien vous indique où sa recherche s'est arrêtée. Le résultat d'AISLE montre que les bugs de curl ne s'arrêtaient pas là. La capacité décisive a été la couverture, pas le jugement porté sur chaque découverte.
C'est la partie qui vous concerne, même si vous ne touchez jamais à curl.
Quand un scanner dit n'avoir rien trouvé, vous apprenez ce que cet outil pouvait voir depuis l'endroit où il a regardé. Vous n'apprenez pas que le code est sain. C'était déjà vrai des analyseurs statiques et des fuzzers, et c'est précisément pour cela que les ingénieurs sécurité en utilisent plusieurs. Le risque nouveau, c'est que les scanners à base d'IA expliquent leurs résultats avec aisance, et que « j'ai examiné le code et n'ai trouvé aucune autre vulnérabilité » sonne comme une conclusion plutôt que comme une limite de couverture.
Deux lectures du même zéro
Lu comme un verdict : le code ne contient plus de problème de ce type. On livre.
Lu comme une limite : cet outil, avec ce prompt, ce budget de contexte et cette stratégie de recherche, a cessé de produire des résultats. Un autre, avec une stratégie différente, n'aurait peut-être pas cessé.
curl en août est un cas net où la seconde lecture était la bonne, sur l'une des bases de code C les plus fuzzées et auditées qui soient.
Si un projet mature doté d'un processus de sécurité à plein temps peut abriter six vraies CVE derrière deux listes vides, un SaaS de douze mois qui a passé une analyse IA avant son audit SOC 2 n'a pas démontré grand-chose.
Aucun des deux billets d'AISLE ne décrit son architecture ; tout détail sur son fonctionnement relèverait donc de la spéculation, et je m'en abstiens. Deux éléments sont publics, et ils suffisent.
Le premier est la formule d'AISLE elle-même : « Les capacités en cybersécurité sont inégales : sur des tâches de sécurité bien définies, des modèles plus petits peuvent surpasser des LLM bien plus grands et plus coûteux. » Cela correspond à ce que nous observons en construisant des agents spécialisés. Un modèle généraliste est réglé pour être raisonnablement bon partout. Un système conçu pour une seule tâche peut consacrer tout son budget à l'espace de recherche de cette tâche — quels sous-systèmes, quelles configurations, quelles interactions entre backends TLS et réutilisation de connexion — et les six découvertes d'août se logent précisément dans ce genre de recoin.
Le second est ce qu'a remarqué le mainteneur. Les éloges de Stenberg ne portaient pas sur la puissance brute. Il a dit qu'AISLE « consacre un vrai temps d'ingénierie à s'assurer que nous recevons des résultats triés, de toute première qualité ». Jim Fuller, chez Red Hat, a dit à peu près la même chose : l'outil « a fait bien plus que lancer un scanner ».
Mis bout à bout, cela dessine clairement le produit :
Ce n'est pas un meilleur modèle. C'est une stratégie de recherche ciblée sur un seul domaine, plus un tri de niveau humain avant que quoi que ce soit n'atteigne la personne qui doit agir. Mythos et Codex Security sont des outils généralistes mis à la disposition de tous. AISLE est un système que quelqu'un a conçu pour ce travail, et qu'il a accepté de laisser tourner une fois le terrain évident couvert.
Cet épisode est sans doute la preuve publique la plus nette à ce jour dans un débat que les fondateurs ont sans cesse avec les investisseurs : qu'est-ce qui empêche le laboratoire de faire la même chose ?
L'outil du laboratoire s'arrête là où il est généraliste. Mythos et Codex Security sont conçus pour fonctionner sur n'importe quel dépôt. C'est justement cette largeur qui explique qu'ils aient abandonné curl les premiers. Votre angle d'attaque, c'est la profondeur qu'ils ne peuvent pas justifier pour un seul vertical.
Vendez des résultats acceptés, pas une production brute. curl ne se souciait pas de 29 rapports. Il se souciait de six CVE et du temps de mainteneur qu'il a fallu pour y arriver. Si votre produit génère des découvertes, des brouillons ou des leads, le chiffre que ressent votre client, c'est ce qui survit à sa relecture, par heure de son temps.
Le tri fait partie du produit, ce n'est pas un coût annexe. Le même taux de réussite de 20 % est un cadeau quand quelqu'un l'a vérifié en amont, et une charge quand personne ne l'a fait. Stenberg qualifie l'état actuel des rapports de sécurité générés par IA d'« ère du chaos de haute qualité ». Un produit qui absorbe ce chaos vaut plus qu'un produit qui le transmet.
Choisissez une vérité de terrain notée par quelqu'un d'autre. L'affirmation d'AISLE est crédible parce que ce sont les mainteneurs de curl, et non AISLE, qui ont décidé de ce qui comptait. Trouvez l'équivalent dans votre domaine — un auditeur, un régulateur, une pull request fusionnée — et rendez des comptes par rapport à lui plutôt qu'à votre propre tableau de bord.
La moitié inconfortable de la même leçon : si votre produit est une fine surcouche qui appelle une fois un modèle de pointe et met la réponse en forme, voilà à quoi ressemble votre concurrent.
Quatre changements, tous peu coûteux :
Deux outils généralistes de pointe partagent souvent les mêmes angles morts. Associez l'un d'eux à un analyseur statique classique, à un fuzzer sur vos parseurs ou à un outil spécialisé. C'est la diversité des méthodes qui trouve la deuxième couche.
Notez l'outil, la version, les chemins analysés et la date. Un résultat vide sans périmètre finit cité dans un questionnaire de sécurité comme la preuve de quelque chose qu'il n'a jamais mesuré.
À une vraie découverte sur cinq, une analyse qui renvoie quarante éléments représente une semaine d'ingénierie. Décidez qui relit, et en combien de temps, avant d'activer l'outil, sans quoi les rapports resteront en souffrance.
Quatre des six découvertes d'août dans curl concernent le comportement des backends TLS, et les deux autres des cas limites d'analyse des cookies : des interactions de configuration, pas le chemin évident de la requête. Dans votre produit, l'équivalent se trouve généralement dans les cas limites d'authentification, les frontières entre clients d'un système multi-tenant et tout ce qui met des identifiants en cache.
AISLE est la source de l'essentiel de l'histoire. La chronologie, les 29 rapports et le cadrage viennent du billet d'AISLE. Le tableau de curl confirme de manière indépendante les six CVE et leur gravité ; rien d'indépendant ne confirme la quantité de calcul, de temps ou d'effort humain qu'il a fallu pour les produire.
La comparaison n'est pas contrôlée. Mythos a tourné en mai, AISLE fin août, sur un code qui a changé entre-temps et qui avait déjà intégré les découvertes de Mythos. Cela rend le résultat d'AISLE plutôt plus difficile que plus facile, mais ce n'est toujours pas un benchmark.
Les six sont de gravité faible. C'est habituel pour curl, où il reste rarement autre chose à trouver, mais cela signifie que l'épisode démontre une couverture, et non la capacité à trouver des failles critiques que d'autres auraient manquées.
La comparaison entre 20 % et 21 % est approximative. Les deux dénominateurs n'étaient pas étiquetés de la même façon, comme le précise la section 2. Je m'en sers pour montrer que la précision n'était pas la différence évidente, pas pour affirmer que les deux sont aussi précis l'un que l'autre.
La remarque de Kroah-Hartman sur Linux tient en une phrase. « Je vois la même chose » est un signal à surveiller, pas un résultat publié.
La version facile de cette histoire, c'est David contre Goliath. La version utile porte sur ce que signifie un résultat vide.
Deux des systèmes d'IA les mieux financés au monde ont examiné un code très audité et déclaré qu'il ne restait rien. L'un comme l'autre décrivaient fidèlement leur propre recherche. Un système plus étroit, doté d'une autre stratégie et de personnes qui vérifiaient ses résultats avant de les envoyer, a trouvé six vraies vulnérabilités en quelques jours. Son taux de réussite n'était pas meilleur. Il a simplement continué, et fait le ménage derrière lui.
Pour un fondateur qui construit sur des modèles de pointe, c'est l'avantage concurrentiel énoncé sans fard : de la profondeur dans un domaine, et un tri avant que quoi que ce soit n'atteigne un humain. Pour un fondateur qui livre du code, c'est un avertissement tout aussi direct.
Traitez chaque « aucun résultat » comme la limite de la recherche d'un outil, et notez par écrit où se situait cette limite.
Sources : AISLE, « AISLE Discovered Six curl CVEs After OpenAI and Anthropic Found Zero », Stanislav Fort, 2 septembre 2026 — les citations de Stenberg des 24 et 25 août, les 29 rapports, le passage de trois à dix CVE en attente et la citation de Kroah-Hartman, tels que publiés. Tableau des vulnérabilités de curl pour la 8.21.0 — les six identifiants (CVE-2026-80229, -80230, -80231, -80255, -82208, -82209), leurs intitulés, les plages de versions concernées et leur gravité faible. Daniel Stenberg, « Mythos finds a curl vulnerability », 11 mai 2026 — les cinq annoncées, la seule confirmée, les trois faux positifs, la vingtaine de bugs et le jugement « surtout du marketing ». Steven Vaughan-Nichols, ZDNET, via Yahoo Tech, 4 septembre 2026 — la mention de ZeroPath, les citations de Stenberg sur l'« ère du chaos de haute qualité » et les « résultats triés », et la remarque de Jim Fuller. Les affirmations d'AISLE pour juin proviennent de son billet sur la 8.21.0, y compris la citation sur les capacités « inégales ». La comparaison des ratios de la section 2 et tout ce qui suit la section 3 sont de moi. Pour un autre cas où le propre rapport de l'agent était justement ce qu'il ne fallait pas croire, voir votre agent de code a épinglé le commit. Pour l'argument selon lequel les petits modèles l'emportent sur les décisions étroites, voir l'essentiel de ce que votre agent demande à un LLM est un oui ou un non.
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.
