Codex découvre une faille WordPress critique : l’IA change-t-elle la cybersécurité ?

Codex faille WordPress : cette association aurait encore semblé improbable il y a peu. Pourtant, en 2026, un test mené dans un environnement de recherche autorisé montre jusqu’où un agent IA peut désormais aller dans l’analyse de vulnérabilités.

Avec GPT-5.6 Sol, Codex a participé à l’identification d’une vulnérabilité WordPress accessible avant authentification, puis à la construction d’une chaîne menant à une exécution de code à distance, ou RCE.

Cette expérience autour de Codex faille WordPress ne signifie pas qu’une intelligence artificielle peut désormais pirater n’importe quel site automatiquement. Elle montre en revanche qu’une partie de la recherche de vulnérabilités complexes devient progressivement automatisable.

Codex faille WordPress : pourquoi cette expérience est importante

Le cas Codex faille WordPress montre que les agents IA deviennent capables d’explorer un code complexe, de tester plusieurs hypothèses et d’enchaîner différentes primitives jusqu’à une vulnérabilité critique. L’enjeu n’est pas seulement technique : il concerne directement l’avenir du bug bounty, du pentest et de la cybersécurité défensive.

Codex, c’est quoi exactement ?

Codex est l’environnement agentique de programmation d’OpenAI.

Il permet notamment à un modèle de :

• analyser un projet ;
• modifier des fichiers ;
• exécuter des commandes ;
• tester du code ;
• utiliser des outils ;
• travailler sur des tâches longues ;
• coordonner plusieurs sous-agents selon le mode utilisé.

GPT-5.6 Sol est aujourd’hui l’un des modèles les plus performants d’OpenAI pour les tâches complexes de programmation et de cybersécurité. OpenAI indique notamment que le modèle a fortement progressé sur les tâches de recherche de vulnérabilités et d’exploitation à long horizon.

OpenAI précise cependant que ces capacités restent accompagnées de protections renforcées destinées à préserver les usages défensifs tout en limitant les usages offensifs dangereux.

Que s’est-il réellement passé avec WordPress ?

L’exemple le plus marquant cité par YesWeHack provient du chercheur HashKitten, également identifié comme Adam Kues dans les publications de Searchlight Cyber.

Son objectif était ambitieux :

analyser le code source de WordPress et rechercher un chemin accessible sans authentification pouvant mener à une exécution de code à distance.

L’environnement de recherche était volontairement contraint.

Codex ne devait pas :

• comparer avec une version corrigée ;
• consulter l’historique Git pour retrouver le patch ;
• chercher directement la vulnérabilité sur Internet.

L’objectif était de forcer l’IA à raisonner à partir du code lui-mêm

Plusieurs agents IA travaillaient en parallèle

Le workflow utilisé est particulièrement intéressant.

Codex pouvait faire travailler jusqu’à quatre agents simultanément.

Mais ils ne devaient pas simplement chercher tous la même chose.

Le système imposait notamment :

• des pistes différentes ;
• le suivi des hypothèses déjà explorées ;
• des agents chargés de contester les résultats ;
• une validation avant d’accepter une nouvelle piste.

Autrement dit, certains agents jouaient le rôle de chercheurs.

D’autres jouaient presque celui de relecteurs adversariaux.

Le but était d’éviter un défaut classique des modèles IA :

s’enfermer dans une hypothèse séduisante mais fausse.

YesWeHack souligne précisément l’importance de cette organisation pour obtenir des résultats fiables sur un grand codebase comme WordPress.

Codex trouve d’abord une injection SQL

Au cours de l’analyse, Codex a identifié une incohérence dans l’API REST batch de WordPress.

Cette piste a été transformée en une injection SQL accessible avant authentification.

Mais le chercheur humain n’a pas immédiatement considéré le résultat comme valide.

Une installation WordPress standard a été utilisée afin de vérifier indépendamment que la primitive fonctionnait réellement.

Ce n’est qu’après cette confirmation qu’une deuxième phase de recherche a été lancée.

Cette étape est essentielle.

Elle montre que la recherche assistée par IA ne consiste pas simplement à accepter tout ce qu’un modèle affirme.

La validation expérimentale reste indispensable.

Puis l’IA cherche si la faille peut conduire à une RCE

Une injection SQL est déjà sérieuse.

Mais l’objectif du test était plus ambitieux :

peut-elle être transformée en exécution de code à distance ?

Codex a alors repris la primitive confirmée et exploré d’autres comportements de WordPress.

Les agents ont fini par relier plusieurs mécanismes éloignés du code afin de construire une chaîne complète conduisant à la RCE recherchée.

C’est ce passage qui rend l’expérience particulièrement intéressante.

Trouver un bug isolé est une chose.

Construire une chaîne exploitable exige davantage :

identifier une faiblesse

↓

prouver qu’elle fonctionne

↓

chercher comment elle interagit avec d’autres mécanismes

↓

assembler plusieurs primitives

↓

valider le résultat final

C’est exactement le type de raisonnement complexe qui faisait jusqu’ici largement appel à l’expérience humaine.

Environ 10 heures de calcul pour 25 dollars

Autre chiffre spectaculaire :

Searchlight Cyber indique que la recherche complète a demandé un peu plus de dix heures, pour un coût estimé à environ 25 dollars de calcul.

Le montant doit cependant être interprété correctement.

Cela ne signifie pas :

« Pour 25 dollars, n’importe qui peut pirater WordPress. »

L’expérience reposait sur :

• un chercheur expérimenté ;
• un environnement préparé ;
• le code source ;
• des instructions précises ;
• un workflow multi-agents ;
• une validation humaine.

Le coût de calcul ne représente donc pas le coût total du travail de recherche.

Mais il révèle tout de même quelque chose d’important :

le coût marginal de l’exploration automatisée de très grands volumes de code peut devenir extrêmement faible.

Pourquoi cette expérience est importante pour la cybersécurité

La recherche traditionnelle de vulnérabilités demande énormément de temps.

Un chercheur doit :

• lire du code ;
• comprendre l’architecture ;
• identifier les entrées utilisateur ;
• suivre les flux de données ;
• tester des hypothèses ;
• éliminer les faux positifs ;
• construire une preuve de concept.

Une IA agentique peut désormais automatiser une partie croissante de ces opérations.

Cela ne remplace pas totalement l’expertise humaine.

Mais cela peut considérablement augmenter la quantité de code qu’un chercheur est capable d’examiner.

Codex peut-il réellement travailler seul ?

Jusqu’à un certain point.

YesWeHack a voulu tester précisément cette question.

Après l’expérience WordPress, l’entreprise a confronté Codex à deux laboratoires PortSwigger en boîte noire.

Cette fois, l’agent ne connaissait même pas le type de vulnérabilité à rechercher.

Premier test : une faille DOM XSS

Le premier laboratoire contenait une vulnérabilité DOM XSS.

Codex a d’abord pris une mauvaise direction.

Il a cherché certaines pages et fonctionnalités qui n’existaient pas.

C’est intéressant parce que cela montre que l’IA peut toujours :

• faire de mauvaises suppositions ;
• perdre du temps ;
• explorer des impasses.

Mais l’agent a ensuite corrigé sa trajectoire.

Il a identifié la vulnérabilité, construit la démonstration nécessaire et validé le résultat.

Temps total annoncé :

moins de quatre minutes.

YesWeHack précise également que Codex a vérifié que l’exercice était bien considéré comme résolu plutôt que de s’arrêter dès qu’une réponse semblait prometteuse.

Deuxième test : une vulnérabilité JWT

Le second laboratoire concernait un mécanisme d’authentification JWT mal sécurisé.

Codex a commencé par essayer une approche qui a échoué.

Plutôt que de rester bloqué, il a :

1. constaté l’échec ;
2. changé d’hypothèse ;
3. testé une nouvelle méthode ;
4. validé l’accès obtenu.

Le résultat a été obtenu en :

1 minute et 14 secondes

selon YesWeHack.

L’intérêt n’est pas seulement la vitesse.

C’est surtout la boucle de raisonnement :

hypothèse → test → échec → nouvelle hypothèse → validation

qui ressemble de plus en plus à la démarche d’un pentesteur humain.

L’IA est-elle devenue un hacker autonome ?

Pas encore au sens fort du terme.

OpenAI classe GPT-5.6 Sol comme disposant d’une capacité élevée en cybersécurité, mais en dessous du niveau critique de son Preparedness Framework.

Dans ses propres évaluations, OpenAI explique que GPT-5.6 Sol peut :

• mener des campagnes de recherche longues ;
• reproduire des crashes ;
• trouver de véritables vulnérabilités ;
• produire des preuves de concept ;
• identifier certaines primitives d’exploitation.

Mais le modèle n’a pas réussi, dans les évaluations décrites par OpenAI, à produire de manière autonome une chaîne d’exploitation complète fonctionnelle contre les cibles réelles durcies testées.

Cela ne contredit pas nécessairement l’expérience WordPress.

Les conditions ne sont pas identiques.

Et c’est précisément ce qui montre à quel point :

le contexte + les outils + l’orchestration + les prompts + la validation

peuvent changer les performances d’un agent.

YesWeHack détaille dans son analyse consacrée à Codex et au bug bounty comment l’agent a été utilisé dans plusieurs scénarios de recherche de vulnérabilités.

Le chercheur humain reste indispensable

C’est probablement le message le plus important de l’étude.

Dans l’expérience WordPress, le chercheur :

• définit l’objectif ;
• organise le workflow ;
• fixe les limites ;
• valide la première vulnérabilité ;
• analyse la chaîne finale ;
• prépare ensuite la divulgation.

YesWeHack résume donc l’évolution non comme la disparition du chercheur, mais comme une transformation de son rôle.

Le chercheur passe progressivement de :

« Je dois moi-même essayer toutes les pistes. »

à :

« Je dois organiser les recherches, challenger les résultats et valider les preuves. »

Pourquoi les agents critiques sont une idée importante

Un détail mérite particulièrement l’attention.

Certains sous-agents n’étaient pas chargés de trouver davantage de vulnérabilités.

Ils devaient au contraire essayer de démontrer que les résultats des autres étaient faux.

C’est une stratégie intéressante pour limiter :

• hallucinations ;
• faux positifs ;
• raisonnements circulaires ;
• biais de confirmation.

Une architecture multi-agents peut donc utiliser l’IA non seulement pour générer des idées, mais aussi pour effectuer une forme de revue contradictoire automatisée.

Qu’est-ce que cela change pour le bug bounty ?

Le bug bounty repose sur des chercheurs indépendants qui cherchent des failles dans un périmètre autorisé en échange d’une récompense lorsqu’une vulnérabilité valide est découverte.

Les agents IA pourraient considérablement modifier ce modèle.

Un chercheur pourrait faire travailler plusieurs agents simultanément sur :

• reconnaissance ;
• analyse du code ;
• APIs ;
• authentification ;
• JavaScript ;
• logique métier.

Le chercheur humain concentrerait ensuite son temps sur les résultats réellement prometteurs.

Les chasseurs de bugs vont-ils disparaître ?

Probablement pas.

Mais leur productivité pourrait augmenter considérablement.

Les compétences les plus importantes pourraient progressivement évoluer vers :

• définition du scope ;
• orchestration des agents ;
• analyse critique ;
• compréhension métier ;
• validation ;
• créativité ;
• divulgation responsable.

L’IA devient donc moins un remplacement qu’un multiplicateur de capacité.

Et pour les entreprises ?

Les conséquences sont également importantes.

Si les défenseurs peuvent utiliser l’IA pour rechercher automatiquement des vulnérabilités, il faut supposer que des attaquants chercheront eux aussi à exploiter ce type de technologie.

OpenAI reconnaît d’ailleurs explicitement que les capacités cyber des modèles augmentent et a renforcé ses mécanismes de sécurité pour les usages à risque.

L’entreprise a également lancé et étendu son programme Daybreak, destiné à fournir des capacités avancées aux défenseurs autorisés.

La fenêtre entre découverte et exploitation pourrait encore raccourcir

C’est probablement la conséquence la plus importante.

Aujourd’hui, lorsqu’une vulnérabilité est corrigée, les administrateurs disposent parfois de quelques heures ou quelques jours avant qu’un exploit réellement opérationnel soit largement disponible.

Avec des agents capables d’analyser :

• patch ;
• code ;
• comportement ;
• architecture ;

cette fenêtre peut se réduire.

Dans le cas de WP2Shell, Searchlight Cyber indique que des preuves de concept publiques sont apparues rapidement après publication du correctif et qu’une exploitation armée a été observée moins de deux jours après.

La conséquence pour les administrateurs WordPress est simple :

la vitesse de mise à jour devient encore plus importante.

Quel impact pour WordPress ?

WordPress représente une cible particulièrement intéressante.

Pourquoi ?

Parce qu’un même logiciel est déployé sur un nombre immense de sites.

Une vulnérabilité dans WordPress Core ou dans une extension très populaire peut donc toucher :

• blogs ;
• boutiques ;
• médias ;
• sites institutionnels ;
• entreprises.

L’automatisation de la recherche de vulnérabilités pourrait donc augmenter la pression sur tout l’écosystème.

Mais l’IA peut aussi renforcer WordPress

Il ne faut pas voir uniquement le côté offensif.

Les mêmes outils peuvent servir aux défenseurs pour :

• analyser des plugins ;
• relire du code ;
• rechercher des entrées non filtrées ;
• détecter des erreurs d’autorisation ;
• vérifier des correctifs ;
• produire des tests ;
• auditer des dépendances.

Une agence WordPress pourrait donc utiliser des agents IA pour réaliser automatiquement une première analyse de sécurité avant une mise en production.

C’est probablement l’un des usages les plus intéressants pour les années à venir.

OpenAI mise justement sur la cybersécurité défensive

OpenAI présente GPT-5.6 Sol comme son modèle généraliste le plus performant à ce jour pour les tâches de cybersécurité.

Selon l’entreprise, ses capacités sont particulièrement améliorées sur :

• recherche de vulnérabilités ;
• exploitation dans des environnements autorisés ;
• secure code review ;
• analyse de malware ;
• validation de correctifs.

Mais ces progrès ont également conduit OpenAI à renforcer ses garde-fous.

La société indique que les protections cyber de GPT-5.6 Sol bloquent beaucoup plus d’activités potentiellement dangereuses que celles de la génération précédente.

L’IA réduit-elle le coût d’une cyberattaque ?

Potentiellement, oui.

C’est probablement l’une des implications les plus importantes à long terme.

Ce qui coûtait auparavant :

• plusieurs journées d’analyse ;
• une forte expertise ;
• énormément d’essais ;

peut progressivement être assisté par plusieurs agents travaillant en parallèle.

Cela ne transforme pas un débutant en chercheur expert instantanément.

Mais cela réduit certains coûts :

• temps d’analyse ;
• exploration ;
• répétition ;
• recherche documentaire ;
• test des hypothèses.

Le rapport coût/capacité de la recherche offensive et défensive est donc en train de changer.

La vraie question : qui trouvera la vulnérabilité en premier ?

C’est probablement une meilleure manière de regarder le problème.

La question n’est plus uniquement :

« Une IA peut-elle trouver une vulnérabilité ? »

Nous savons désormais que oui.

La question devient :

« Le défenseur pourra-t-il la trouver et la corriger avant l’attaquant ? »

Et cela pourrait provoquer une course à l’automatisation entre :

chercheurs

contre

attaquants

contre

éditeurs logiciels

Les correctifs devront-ils eux aussi devenir plus rapides

Probablement.

Une conséquence logique de l’accélération de la découverte est l’accélération nécessaire du patching.

Les éditeurs devront améliorer :

• analyse automatique du code ;
• CI/CD sécurité ;
• tests ;
• triage des vulnérabilités ;
• création de correctifs ;
• déploiement automatique.

Autrement dit, l’IA offensive pourrait indirectement accélérer également les défenses.

Ce que les propriétaires de sites WordPress doivent retenir

Vous n’avez évidemment pas besoin de devenir spécialiste du bug bounty.

Mais cette évolution change certaines bonnes pratiques.

1. Installez rapidement les mises à jour de sécurité

Attendre plusieurs semaines devient de plus en plus risqué.

2. Maintenez également les plugins à jour

Les extensions constituent une grande partie de la surface d’attaque WordPress.

3. Supprimez les plugins inutilisés

Moins de code signifie moins de surface potentielle.

4. Activez la MFA

Protégez au minimum :

• WordPress ;
• hébergement ;
• registrar ;
• email.

5. Conservez des sauvegardes externes

Une sauvegarde présente uniquement sur le serveur compromis ne constitue pas une stratégie suffisante.

6. Surveillez les modifications

Logs, fichiers, utilisateurs et extensions doivent pouvoir être contrôlés rapidement après une alerte.

L’IA va-t-elle remplacer les pentesteurs ?

Probablement pas, mais elle va modifier leur métier.

Les agents sont particulièrement efficaces pour :

• tâches répétitives ;
• exploration de grande ampleur ;
• analyse de code ;
• tests systématiques.

Les humains restent supérieurs lorsqu’il faut :

• comprendre un contexte métier ;
• définir les limites ;
• juger l’impact réel ;
• identifier un faux positif ;
• prendre une décision responsable.

Nous allons donc probablement vers des équipes où :

humain + agents IA

seront plus performants que l’un ou l’autre isolément.

FAQ – Codex, WordPress et cybersécurité

Conclusion : Codex ne remplace pas le hacker, il change son échelle

L’expérience menée autour de Codex et WordPress marque une étape intéressante dans l’évolution de la cybersécurité.

Un agent IA peut désormais :

• explorer un grand codebase ;
• formuler des hypothèses ;
• lancer plusieurs pistes parallèles ;
• rejeter certains échecs ;
• confirmer des vulnérabilités ;
• relier plusieurs primitives.

Ce qui change vraiment n’est donc pas l’apparition d’un « hacker IA autonome » capable de tout faire sans supervision.

C’est autre chose :

la recherche de vulnérabilités devient beaucoup plus automatisable, rapide et économique.

Pour les chercheurs et les défenseurs, c’est une opportunité considérable.

Pour les entreprises qui repoussent encore leurs correctifs pendant plusieurs semaines, c’est aussi un avertissement.

À mesure que les agents IA deviennent plus performants, le temps disponible entre :

vulnérabilité → découverte → exploitation

risque de diminuer.

En cybersécurité, la vitesse de réaction pourrait donc devenir aussi importante que la qualité des protections.

Ces articles pourraient aussi vous intéresser

WP2Shell WordPress : une faille critique dans le cœur du CMS
Comprenez pourquoi cette vulnérabilité a marqué la sécurité WordPress en 2026.

Faille All-in-One WP Migration : 5 millions de sites concernés
Une vulnérabilité importante dans l’un des plugins de migration les plus utilisés.

Agents IA : comment ils transforment déjà le travail
Découvrez pourquoi les agents capables d’utiliser des outils représentent une évolution majeure de l’intelligence artificielle.