POURQUOI

Problème

• Les gens veulent embarquer dans la hype autour de l’IA
• Les programmes de bug bounty sont inondés de rapports écrits par IA, majoritairement des faux positifs ou des impacts grandement exagérés
• Dans les projets plus larges, les bug bounty hunters rencontrent des difficultés avec :
  • Trouver de vraies vulnérabilités avec des impacts réels
  • Gérer le contexte des agents
  • Éviter les faux positifs
  • Empêcher les agents de travailler sur des vecteurs d’attaque qui ont déjà été couverts
  • Empêcher les agents d’être paresseux et de conclure trop rapidement qu’une cible est sécure

Cela mène à une perception commune dans le domaine du pentest / de la recherche de vulnérabilités selon laquelle l’IA ne peut pas trouver de vulnérabilités avec de vrais impacts ou qu’elle ne peut trouver que des low hanging fruits.

Ce talk présente un pipeline complet avec des agents spécialisés, des outils, des environnements de test distincts, une structure et des processus qui ont trouvé des vrais CVE de manière entièrement autonome.

Portée

Cette présentation traite de la recherche automatisée de vulnérabilités à l’aide d’agents IA. Elle ne couvre pas le pentest black-box, l’énumération d’actifs, etc. Il s’agit de trouver des CVE dans des projets open source.

Public cible

Pentesters white-box, chercheurs en sécurité, bug bounty hunters

COMMENT

Vue d’ensemble

Le pipeline a nécessité environ 2 mois de travail pour être conçu et implémenté, en corrigeant les problèmes et irritants de manière itérative jusqu’à atteindre un pipeline capable de trouver des CVE de manière autonome dans des plugins WordPress. Les plugins WordPress ont été choisis comme cible pour ce projet parce que :
- Le code source est toujours accessible
- Il existe des programmes de bug bounty pour les plugins WordPress
- Ils partagent une structure similaire (toujours en PHP, facile à automatiser le déploiement, etc.)

Cependant, ce design de pipeline pourrait être appliqué à n’importe quelle autre code source.

À haut niveau, la présentation décrit un pipeline d’agents spécialisés avec différents rôles, incluant un Manager, un agent Recon, un agent CPG, un Code Reviewer, un Exploiter, un générateur de PoC, ainsi que plusieurs petits agents spécialisés qui empêchent les doublons, évaluent les scores CVSS, etc.

Ces agents disposent d’outils et d’accès spécifiques, basés sur le principe du moindre privilège, non pas pour des raisons de sécurité, mais pour les empêcher de dévier de leur objectif principal. Ces outils incluent l’accès (lecture et/ou écriture) à certaines tables de la base de données, différents environnements conteneurisés pour les tests, la revue de code et la documentation de PoC, l’accès à un fuzzer basé sur un fork de PHP, ainsi que l’accès à un Code Property Graph (CPG) pour l’analyse de code source.

Toute la structure du pipeline repose sur le schéma de base de données, qui classifie les résultats en Attack Vectors ou Findings. Chaque type possède plusieurs états possibles comme Open, Reviewed, Verified, Dismissed, etc., permettant aux agents avec différents rôles de soumettre des "idées" ou des "concepts" de attack chain qui seront ensuite examinés par d’autres agents, ou de prendre en note des parties potentielles d’une attack chain même si celle-ci n’est pas encore exploitable.

Détails techniques

Vue d’ensemble

• Workflows n8n
• Claude Sonnet ou Opus pour les agents
• Conteneurs pour les environnements de test
• Fork du projet WPGarlic pour le fuzzing de plugins WordPress
• Code Property Graph (CPG) utilisant php-parser, puis adapté à la recherche en sécurité avec priorisation des chemins via scripts Python et stocké dans des graph tables Postgres
• Serveur MCP pour permettre aux agents d’utiliser les conteneurs, le fuzzer, le CPG, etc.
• Base de données Postgres
• Application web pour visualiser le pipeline, revoir manuellement les findings, consulter les PoC, etc.

Agents

Si vous essayez de partir de zéro pour trouver des bugs dans des projets open source avec des agents, le premier problème que vous rencontrerez est la taille du contexte. Lorsqu’un agent enquête sur une vulnérabilité potentielle, il lit du code, raisonne, etc., jusqu’à ce que sa limite de contexte soit atteinte. Il compresse ensuite l’historique et continue sa tâche. Le problème est que ce contexte compressé ne conserve pas les détails de ce qui a déjà été testé, donc l’agent réexplore les mêmes choses. C’est pour cela qu’il faut plusieurs agents.

Manager

Le Manager suit l’état du projet. Il appelle des sous-agents pour leur assigner des tâches et s’assure que tout fonctionne de manière autonome.

C’est aussi ici que l’on peut corriger le problème de "l’agent paresseux”. En donnant des instructions spécifiques au Manager, en marquant explicitement un projet comme "stale” ou "active”, l’agent ne considère jamais que le projet est "terminé” et relance le pipeline si toutes les pistes ont été explorées.

Recon Agent

Le Recon Agent est conçu pour être créatif. Il n’a accès qu’au code source, mais il ne doit pas être trop rigoureux dans sa revue de code. À la place, il génère des vecteurs d’attaque créatifs, en produisant autant d’idées que possible sans vérifier si elles sont réellement légitimes.

Ce comportement imite la manière dont un pentester pense à haut niveau. Il part d’idées larges comme : "Est-ce qu’un utilisateur peut injecter du code PHP sérialisé ici pour qu’il soit exécuté lorsque l’admin charge cette page ?”

Il peut uniquement créer des Attack Vectors et les marquer comme "Open”.

CPG Agent

Le CPG Agent a un rôle similaire au Recon Agent mais se spécialise dans l’utilisation des outils MCP qui interagissent avec le CPG. Il génère des Attack Vectors ouverts basés sur les résultats du CPG.

Code Reviewer

Le Code Reviewer est le premier filtre du pipeline. Il prend un Attack Vector "Open" et vérifie s’il est théoriquement exploitable dans le code. Il rejette les vecteurs d’attaque qui échouent à cause de filtres ou d’autres restrictions dans le code source. Il marque ensuite les Attack Vectors valides comme "Confirmed”.

Exploiter

C'est là où la magie opère: l'Exploiter sélectionne des Attack Vectors "Confirmed" depuis la base de données et tente de les chaîner pour atteindre l’impact le plus élevé possible. Ensuite, dans un conteneur avec WordPress et le plugin installé, il tente d’exploiter la chaîne de bout en bout.

S’il réussit, il crée un Finding. Les Findings sont des combinaisons d’un ou plusieurs Attack Vectors qui produisent un impact tangible. Il écrit les étapes de reproduction et un résumé expliquant où et pourquoi le bug apparaît dans le code.

PoC Generator

Le PoC Generator a accès à un environnement PoC séparé, reconstruit pour chaque test. Cet environnement contient uniquement une installation WordPress et une configuration par défaut du plugin cible, basé sur le WPScan Vulnerability Test Bench.

Le PoC Agent interagit avec cet environnement via un outil MCP qui envoie des requêtes HTTP. Ces requêtes passent par un proxy Caido, permettant d’auditer l’historique HTTP et de documenter plus rapidement.

Cela empêche les agents de "tricher”, ce qui est une source majeure de faux positifs. Les agents modifient parfois le code source ou la configuration avant de soumettre une vulnérabilité. Par exemple : supprimer un filtre et prétendre avoir trouvé une SSRF qui peut atteinre des IPs internes. Le PoC Generator empêche ce comportement en limitant les modifications, et Caido conserve l’historique.

Il écrit ensuite un rapport complet basé sur un template, prêt à être copié-collé et soumis.

Personnellement, je ne soumets jamais un bug sans le reproduire manuellement, mais jusqu’à présent, je n’ai pas rencontré de faux positif ayant passé l’étape du PoC Generator.

Autres agents

Les autres agents incluent :
- Un Fuzzer Agent, pouvant être appelé par le Manager lorsqu’un Attack Vector peut bénéficier de fuzzing
- Des agents de détection de doublons, qui vérifient chaque insertion pour éviter les Attack Vectors ou Findings dupliqués

Schéma de base de données

• Projects
• CPG Graphs

• Attack Vectors (AVs)

  • State [Open, Confirmed, Verified, Dismissed, Reviewing, Verifying, Fuzzing]
  • Title
  • Hypothesis
  • Fichier(s) affecté(s)
  • CWE
  • Notes

• Findings

  • State [Ready, Dismissed, Submitted]
  • Title
  • CVSS vector
  • Description
  • Report
  • Date de soumission
  • Notes

n8n

Tout fonctionne maintenant sur n8n dans la dernière version du système.

1. L’utilisateur démarre une conversation avec le Manager Agent
2. Le Manager crée ou consulte un projet, évalue son état et appelle les sous-agents
   • Ce pipeline peut s'exécuter de manière autonome pendant 12h+
   • Même après 12h, il continue de découvrir de nouveaux Attack Vectors et Findings
   • Il produit des bugs complexes à impact élevé issus de chaînes d’attaque

Innovation

Ce pipeline a été construit en utilisant les meilleures pratiques partagées par Anthropic.

Contrairement à la croyance populaire, cela démontre que l’IA peut découvrir des vulnérabilités complexes et créatives lorsqu’on lui donne les bons outils, instructions et encadrements.

CVE-2026-39465 Editor+ Remote Code Execution dans ML Slider

Exemple de attack chain :

1. Arbitrary Post Meta Write (CWE-284) — endpoint REST save_single_slideshow_setting (api.php:810)

2. Unrestricted File Upload + Race Condition (CWE-434) — process_uploads() dans Image.php

3. Local File Inclusion (CWE-98) — Themes::load_theme() (Themes.php:801)

TL;DR :
- LFI permettant à un Editor de choisir un fichier arbitraire comme thème
- Upload temporaire d’un polyglot GIF+PHP via race condition
- Chaînage des deux menant à du RCE
- CVE-2026-39465 (CVSS 7.2)

Marché

Le potentiel est évident. L’objectif est de démontrer des choix de design qui améliorent fortement la détection de vulnérabilités par IA.

En mai 2026, beaucoup d’annonces de zero-days "IA” manquent de transparence. Cette présentation montre une implémentation concrète avec des résultats réels.

QUOI

À ce jour (mai 2026), 2 CVE ont été publiés : CVE-2026-39465 et CVE-2026-32460.

Plusieurs autres vulnérabilités sont en cours de correction et en attente de divulgation.

Toutes ces zero-days ont été trouvées en exécutant ce pipeline en arrière-plan pendant que je travaillais.