wp2shell: Comment une session d'IA de 25 $ fait trembler des millions de sites WordPress

Imaginez que vous vous asseyez tranquillement autour d'un café, que vous avez votre modèle d'IA préféré ouvert, que vous jetez 25 $ de crédits API et que 10 heures plus tard, vous tenez entre vos mains une exécution de code à distance (RCE) non authentifiée pour le CMS le plus utilisé au monde. YAY!

C'est exactement ce qui est Adam Kues (Analyste de sécurité chez Searchlight Cyber) se passe. Le résultat écoute le nom souple wp2shell Il s'agit d'une chaîne d'exploits activement exploitée qui fonctionne actuellement sur des millions d'instances WordPress. Security-Insider.de a déjà En détail le 27.7.

Si vous utilisez WordPress et que vous n'avez pas fait de mise à jour depuis la mi-juillet, maintenant Le moment est venu d'éteindre le café et d'ouvrir le terminal.

L'établissement brûle: Qu'est-ce que wp2shell?

En ce qui concerne: wp2shell Il ne s'agit pas d'un simple bug, mais d'une Chaîne d'exploits Deux vulnérabilités dans le cœur de WordPress. Ensemble, ils permettent Unauthenticated RCE, ce qui signifie qu'un attaquant n'a pas besoin d'un identifiant ou d'un statut spécial sur votre site. Une requête HTTP préparée suffit pour exécuter n'importe quel code PHP et reprendre complètement le serveur.

Les attaquants ne perdent pas de temps: Déjà 13 minutes après publication du Correctifs de sécurité par WordPress sur 17.7 Des sociétés de sécurité telles que Defiant ont enregistré les premières sondes d'injection SQL automatisées sur le réseau.

Anatomie de l'exploit: Ce qui se passe sous le capot

Pour ceux qui veulent savoir comment marche le lapin: L'interaction entre les deux failles de sécurité est simplifiée:

[ Unauth Request ] │ ▼ [ REST API Batch-Endpoint ] (CVE-2026-63030: Route Mapping Flaw) │ ├─ Bypass de Auth / Routing-Restrictions ▼ [ WP _Query Engine ] (CVE-2026-60137: Injection SQL via 'author __not _in') │ ├─ Le paramètre non corrigé lève l'assainissement SQL de ▼ [Exécution de code à distance / Webshell ] │ └─ Stockage dans /wp-content/cache/ avec nom de hachage aléatoire

Vous trouverez tous les détails techniques dans les contributions de Searchlight Cyber et wizz.io

L'ouvre-porte: REST-API Batch Routing (CVE-2026-63030)

• Score CVSS: 9.8 (critique)
• Versions concernées: WP 6.9.x (< 6.9.5) & 7.0.x (< 7.0.2)

WordPress offre la possibilité de regrouper plusieurs requêtes en un seul appel via son point de terminaison REST API Batch. Il y a eu une erreur logique dans la Mappage d'itinéraire (Route Mapping). Cela permettait aux attaquants de faire passer des requêtes vers des points de terminaison internes/protégés qui nécessiteraient normalement une authentification.

Le fournisseur de charge utile: Injection SQL dans WP _Query (CVE-2026-60137)

• Score CVSS: 5.9 (moyens)
• Versions concernées: WP 6.8.x (< 6.8.6), 6.9.x (< 6.9.5) & 7.0.x (< 7.0.2)

Le classique: Le paramètre author __not _in dans la classe d'interrogation centrale WP _Query n'a pas été correctement sanctifiée. Si ce paramètre est alimenté avec des entrées non filtrées (par exemple, déclenchées par un plug-in ou l'écart d'API REST mentionné ci-dessus), une injection SQL classique est créée.

La combinaison: Le principe des 2 étapes

Chercheurs en sécurité Jean-Baptiste Ullrich (Institut SANS) A l'aide d'un exemple, Comment la vague d’attaques se déroule-t-elle dans la pratique?

1. Échantillon / recon: L'attaquant envoie une première charge utile via SQLi pour vérifier si la base de données est en écriture et si l'écart est comblé.
2. Dropper de Webshell: SQLi appuie sur un webshell PHP dans le système de fichiers, généralement dans le répertoire /wp-content/cache/ sous un nom MD5/SHA généré aléatoirement (par exemple: a8f3b...php).
3. Mécanisme furtif: Le nom de fichier sert également de jeton d'authentification. Si vous gonflez le Webshell sans le paramètre d'URL approprié, il donnera un faux HTTP 404 Not Found Retour en arrière. Smart!

Une fois que le shell est installé, les bots rechargent les plugins malveillants, lisent les wp-config.php (Bonjour les identifiants de base de données !), introduisent de nouveaux utilisateurs administrateurs ou introduisent du code malveillant via des scripts CDN manipulés.

L'IA dans le jeu Bug Bounty: Le Joker à 25 dollars

Un détail épicé sur le bord: Adam Kues a qualifié son Writeup de provocateur:

«Les courtiers en exploit paient 500 000 $ pour un RCE WordPress. J'en ai un avec GPT-5.6 Sol Ultra et 25 $ trouvé.»

Il a utilisé le Large Language Model de manière ciblée pour l'analyse de code statique et le sifting à travers les diff commits du noyau WordPress. Ce qui occupait autrefois des équipes de chercheurs en sécurité pendant des semaines, une IA spécialisée le fait aujourd'hui en quelques heures pour de la monnaie.

Pour les admins, cela signifie: Le time-to-exploit se rétrécit. Le laps de temps entre la sortie du patch et les scans de masse entièrement automatisés est maintenant de l'ordre de quelques minutes.

Premiers secours: Êtes-vous concerné & que faire?

Quick Check via le site web: https://wp2shell.com/

Étape 1: Mise à jour (MAINTENANT!)

WordPress a mis à jour sa version le 17 juillet 2026 7.0.2 (ou les backports) 6.9.5 et 6.8.6) publié. Si votre mise à jour automatique n'a pas fonctionné: Démarrer manuellement immédiatement.

Étape 2: IoC-Check (Indicateurs de compromission)

Si vous voulez savoir si quelqu'un s'est déjà installé chez vous, vérifiez votre instance pour les anomalies suivantes:

1. /wp-content/cache/ Rechercher: Attention à la fraîcheur .php-fichiers avec des noms cryptiques dans le dossier cache. Les dossiers de cache devraient généralement néant Contient du code PHP exécutable.
   
2. Vérification de l'utilisateur admin: Voir dans la liste de modèles WordPress (/wp-admin/users.php?role=administrateur) Comptes inconnus. Les attaquants aiment créer des administrateurs discrets.
   
3. Analyse des fichiers journaux: Filtrez vos journaux de serveur Web (Nginx/Apache) pour les requêtes suspectes admin-ajax.php, appel à /wp-json/wp/v2/batch ainsi que l'accès aux fichiers PHP dans cache/Répertoire.

Étape 3: Outils utiles

• Ce qui a déjà été mentionné ci-dessus Searchlight Cybervérificateur wp2shell« : Fournit un contrôle à distance rapide pour votre domaine.
• Tableau de bord Macnica Live (Yutaka Sejiyama): Suit le taux de patch global. Aujourd'hui, c'est ~81,6 % Les systèmes étudiés ont été corrigés. Mais cela signifie aussi: Presque une personne sur cinq Le site est toujours ouvert à l'attaque!

Conclusion & Astuce pour la pratique

wp2shell montre une fois de plus de manière impressionnante où va le voyage dans le domaine de la cybersécurité: Si les analyses basées sur l'IA démocratisent la découverte de 0-Days, les défenseurs doivent également mettre à niveau.

3 règles d'or pour votre serveur WP:

1. Protection des répertoires pour les téléchargements/cache: Dans votre configuration Nginx/Apache, incluez une règle qui .php-fichiers dans /wp-content/uploads/ et /wp-content/cache/ strictement interdites (location ~* /wp-content/(uploads |cache)/.*\.php$ { deny all; }).
   
2. Utilisation de Fail2Ban / WAF: Configurez un pare-feu d'application Web (par exemple, Cloudflare, Wordfence ou ModSecurity) pour intercepter les modèles d'injection connus à la périphérie.
   
3. Vérifier les sauvegardes: Si vous aviez un interpréteur de commandes dans le système, le «sur-patching» n’est souvent plus suffisant. Dans ce cas: Restaurer le système à partir d'une sauvegarde propre avant le 17 juillet et restaurer toutes les clés wp-config.php Rotation!

Restez en sécurité & happy patching! Qu'en est-il de vous? Avez-vous déjà corrigé toutes les instances ou avez-vous déjà détecté des accès suspects dans le journal? Alors, allez-y!