J’ai trouvé une vulnérabilité à 2 418 $ avec un prompt à 5 $

Résumé général en une ligne

• Un pipeline peu coûteux combinant des prompts LLM et le bundling du code source a permis de découvrir trois vulnérabilités de type denial-of-service dans Django et FastAPI (Starlette) (CVE-2025-64458, CVE-2025-64460, CVE-2025-62727)

Résumé

• En voyant les équipes les mieux classées à DEF CON LiveCTF et au DARPA AIxCC exploiter des binaires avec des LLM et même trouver de nouveaux 0-day, l’auteur a eu le sentiment que, dans la recherche offensive réelle, les LLM pouvaient aussi se montrer plus efficaces que les humains
• En disséquant les archives GitHub des équipes participantes à l’AIxCC (Team Atlanta, Theori) et la conception de RoboDuck, il a estimé qu’une approche consistant à « trouver des bugs avec des LLM plutôt qu’avec du fuzzing » pouvait être intégrée à un workflow de découverte de vulnérabilités
• En s’appuyant sur le contexte accumulé en signalant plusieurs problèmes de sécurité dans Django, DRF et Python, il s’est fixé comme objectif principal de trouver, à l’aide d’un LLM, de nouvelles vulnérabilités de type denial-of-service dans le framework Django
• Contrairement aux modèles participants à l’AIxCC qui automatisent aussi l’analyse binaire et les correctifs, il a conçu une structure ciblant Django, basé sur des scripts, où seule l’étape consistant à « rassembler des candidats de segments de code paraissant vulnérables » est automatisée, afin de limiter le coût à quelques dollars
• En donnant au LLM le rôle de « chercheur en sécurité qui trouve des vulnérabilités dans Django », il a créé un long prompt regroupant des diff de CVE DoS en exemple, des contraintes <tips> et des exemples de format de sortie, de manière à éviter les propositions de patch inutiles et à réduire le taux de faux positifs
• Le code source de Django a été regroupé en XML par répertoire, découpé en blocs de moins de 40K tokens puis envoyé à GPT-5, de façon à maintenir le coût d’exécution autour de 5 $ même pour parcourir l’ensemble du framework
• En examinant les candidats faux positifs trouvés par le workflow, l’auteur a parfois découvert des motifs vulnérables passés inaperçus pendant des années. Même dans l’évaluation de leur validité, le modèle a montré d’excellentes capacités pour expliquer la root cause des problèmes de sécurité et rédiger des PoC
• Ensuite, au lieu de l’API OpenAI, il a utilisé Codex CLI avec un prompt AGENTS.md pour faire parcourir activement le code source de Django, ce qui a abouti à la découverte d’une vulnérabilité DoS en O(n²) dans le traitement du hostname d’URL par HttpResponseRedirectBase, enregistrée sous le CVE-2025-64458
• En appliquant le même prompt à FastAPI (plus précisément Starlette), il a révélé que la logique de fusion de l’en-tête Range de FileResponse pouvait provoquer un ReDoS via un traitement en O(n²) basé sur des expressions régulières, ce qui a été publié sous le CVE-2025-62727 et évalué à CVSS 8.7 (High) selon Snyk

[kdy1234]

Quelle énergie d’action… c’est impressionnant.

[princox]

C’est un cas suffisamment parlant pour être cité dans des documents de présentation externes. Je devrais le sauvegarder.

[heycalmdown]

Du point de vue du capital, je pense que plus il s’agit d’un travail à fort contexte qui exige des prompts longs et minutieux, plus le moment de son remplacement ne peut qu’être tardif.

Je pense que ce passage aussi est un excellent insight.

[gguimoon]

Moi aussi, ça m’intéressait sans que j’aie vraiment creusé le sujet, mais ce texte apporte à la fois de la motivation et des insights. Je le recommande.

[heycalmdown]

Le contenu de l’article est bien meilleur que ce que son résumé laissait croire et que mes préjugés initiaux (accroche un peu putassière..) me faisaient penser. Si le sujet vous intéresse, je vous recommande de lire l’original.