WordPress n’était plus censé être piratable comme ça. Puis est arrivé WP2Shell.

Deux vulnérabilités du cœur même de WordPress ont permis de construire une chaîne d’exploitation capable d’aboutir à une exécution de code à distance… sans authentification, sans plugin et, dans certains cas, sur une installation quasiment par défaut.

Le nom de cette chaîne d’attaque : WP2Shell.

Et si cette faille est spectaculaire, elle raconte surtout une histoire beaucoup plus importante : celle d’un Internet devenu dépendant d’une poignée de logiciels open source dont la moindre erreur peut avoir des conséquences mondiales.

Depuis près de vingt ans, WordPress s’est construit une réputation paradoxale.

D’un côté, il est souvent associé aux attaques informatiques.

De l’autre, les spécialistes savent qu’une immense majorité des compromissions proviennent de thèmes, plugins ou extensions mal maintenus, beaucoup plus que du cœur du CMS lui-même.

Cette distinction est essentielle.

Le cœur de WordPress est audité depuis des années par une communauté immense.

Découvrir une vulnérabilité critique dans le core reste exceptionnel.

Découvrir une chaîne permettant une Remote Code Execution (RCE) pré-authentification l’est encore davantage.

C’est précisément ce qui s’est produit avec WP2Shell.

WordPress a publié en urgence les versions 6.8.6, 6.9.5 et 7.0.2, déclenchant également les mises à jour automatiques de sécurité pour limiter la fenêtre d’exploitation. (VulnCheck)

Ce qui rend WP2Shell fascinant d’un point de vue technique, ce n’est pas une vulnérabilité unique.

C’est leur combinaison.

La première, CVE-2026-60137, concerne une injection SQL dans le paramètre author__not_in de WP_Query.

Isolée, cette faiblesse n’était pas catastrophique.

Elle supposait généralement qu’un plugin ou un thème transmette directement des données non filtrées à cette fonction. (NVD)

La seconde, CVE-2026-63030, touche le système de requêtes par lots de l’API REST.

Une confusion dans le routage des permissions permettait à certaines requêtes anonymes d’être validées contre le mauvais contrôleur.

Autrement dit : un mécanisme chargé de vérifier les autorisations regardait parfois... la mauvaise porte. (NVD)

En reliant ces deux défauts, les chercheurs ont créé une véritable chaîne d’exploitation.

L’authentification est contournée.

L’injection SQL devient exploitable.

La base de données peut être compromise.

Puis vient la récupération ou le contournement des identifiants administrateur.

Enfin, l’exécution de code devient possible grâce aux fonctionnalités natives de WordPress.

Pas besoin d’un plugin vulnérable.

Le CMS suffit.

WP2Shell illustre parfaitement une idée souvent mal comprise.

Les grandes attaques modernes ne reposent plus nécessairement sur une seule faille spectaculaire.

Elles exploitent plusieurs imperfections qui, individuellement, paraissent limitées.

C’est exactement le même principe qu’un cambriolage.

Une fenêtre mal fermée n’est pas dramatique.

Une alarme mal configurée non plus.

Mais lorsque les deux existent simultanément, la maison devient soudainement vulnérable.

La cybersécurité fonctionne désormais selon cette logique.

Les chercheurs ne cherchent plus seulement des bugs.

Ils recherchent des combinaisons.

Le qualificatif “critique” est souvent galvaudé.

Cette fois, il est largement justifié.

WordPress alimente environ 40 % du Web.

Chaque vulnérabilité du cœur du CMS possède donc une portée exceptionnelle.

Mais surtout, WP2Shell présente plusieurs caractéristiques rarement réunies :

• aucune authentification requise ;

• aucun plugin nécessaire ;

• exploitation via le cœur de WordPress ;

• possibilité d’aboutir à une exécution de code ;

• chaîne applicable sur des installations standards selon les versions concernées. (NVD)

Les chercheurs parlent souvent de “one-click RCE”.

Ici, on pourrait presque parler de “zero-click administrateur”.

Il faut également souligner la réponse.

Contrairement aux années 2010, où les correctifs mettaient parfois plusieurs jours à se diffuser, l’équipe WordPress a :

• coordonné la divulgation ;

• publié les correctifs simultanément ;

• déclenché des mises à jour automatiques ;

• travaillé avec les hébergeurs et certains fournisseurs d’infrastructure pour limiter les attaques avant même la publication complète des détails techniques. (Planet WordPress)

Cette capacité de réaction devient aujourd’hui presque aussi importante que la découverte de la faille elle-même.

À chaque vulnérabilité majeure, le même débat ressurgit.

“WordPress est-il devenu dangereux ?”

La réponse est probablement non.

Le vrai problème est ailleurs.

Il réside dans la concentration.

Lorsqu’un logiciel équipe des centaines de millions de sites, chaque faille devient automatiquement un événement mondial.

Le risque n’est plus seulement technique.

Il est statistique.

Même avec un taux de mise à jour très élevé, des millions d’instances resteront vulnérables pendant plusieurs jours, voire plusieurs semaines.

Certaines ne seront jamais corrigées.

Ce sont elles qui deviennent les cibles privilégiées des campagnes automatisées.

Autrefois, les chercheurs conservaient souvent leurs preuves de concept privées pendant plusieurs semaines.

Aujourd’hui, la chronologie est beaucoup plus brutale.

Quelques heures après la publication des correctifs, les premières analyses de patch apparaissent.

Puis viennent les reverse engineers.

Puis les chercheurs indépendants.

Puis les preuves de concept publiques.

Enfin arrivent les scanners automatisés.

Selon plusieurs observateurs, des tentatives d’exploitation ont commencé à émerger très rapidement après la divulgation, et des PoC publics circulent déjà, réduisant fortement le délai dont disposent les administrateurs pour appliquer les correctifs. (VulnCheck)

Autrement dit :

Le “Patch Tuesday” appartient progressivement au passé.

Nous sommes entrés dans l’ère du “Patch Today”.

Pour les équipes techniques, le message est relativement simple :

• vérifier que le site exécute au minimum WordPress 6.8.6, 6.9.5 ou 7.0.2 ;

• confirmer que la mise à jour automatique s’est effectivement appliquée ;

• examiner les comptes administrateurs créés récemment ;

• contrôler les modifications inhabituelles dans les thèmes, plugins ou fichiers PHP ;

• envisager une rotation des secrets si une exposition prolongée est suspectée. (NVD)

L’important n’est pas seulement de corriger.

Il faut aussi vérifier qu’aucune compromission n’a eu lieu avant le correctif.

WP2Shell dépasse largement WordPress.

Cette affaire rappelle que les logiciels open source les plus populaires sont devenus des infrastructures critiques de l’économie numérique.

Ils alimentent des commerces, des médias, des collectivités, des hôpitaux, des associations et des entreprises de toutes tailles.

Le moindre bug dans leur cœur ne concerne plus seulement leurs utilisateurs.

Il concerne une partie du fonctionnement d’Internet.

C’est peut-être la véritable information de cette semaine.

Pas qu’une nouvelle faille ait été découverte.

Mais qu’une immense partie du Web repose désormais sur quelques briques logicielles dont la robustesse est devenue un enjeu de sécurité mondiale.

WP2Shell restera probablement comme l’un des événements majeurs de la sécurité WordPress de ces dernières années.

Non parce qu’il s’agit de la première faille critique.

Mais parce qu’il rappelle une vérité souvent oubliée :

La sécurité moderne ne dépend plus uniquement de la qualité d’un logiciel.

Elle dépend de la vitesse à laquelle tout un écosystème est capable de réagir.

Et dans un monde où des centaines de millions de sites partagent les mêmes fondations, quelques heures peuvent désormais faire la différence entre un simple correctif… et une vague mondiale de compromissions.