WP2Shell: WordPress Core Pre-Auth RCE Exploited in the Wild — CVE-2026-60137 + CVE-2026-63030 Patch & Response GuideWP2Shell : RCE Pré-Auth dans le Core WordPress Exploitée Massivement — Guide Patch & Réponse CVE-2026-60137 + CVE-2026-63030

The Weekend WordPress Core Stopped Being the Safe Part

For years, the standard advice held: WordPress core is the safe part — worry about your plugins. Patchstack's State of WordPress Security 2026 report counted just 6 core vulnerabilities out of 11,334 disclosed across the ecosystem in 2025. Then came the weekend of July 18–19, 2026.

Late on Friday, July 17, WordPress shipped security releases 7.0.2, 6.9.5 and 6.8.6, fixing two core flaws that researchers quickly demonstrated could be chained into unauthenticated remote code execution on a default WordPress install. The chain was nicknamed WP2Shell. Public proof-of-concept code appeared overnight. By early Saturday morning UTC, honeypots were recording successful exploitation. By Monday, July 20, Patchstack, Hexastrike and watchTowr had all confirmed in-the-wild attacks — and on July 21, CISA added both CVEs to its Known Exploited Vulnerabilities catalog.

The scale is hard to overstate. According to WordPress's own version statistics cited by TechCrunch, more than 400 million websites run the affected version branches, and post-patch estimates still put the number of vulnerable installations in the tens of millions. This guide explains how the chain works, exactly which versions are affected, how to verify you're patched — and, critically, how to check whether you were compromised before the patch reached you.

CVE-2026-60137 — SQL Injection in WP_Query's author__not_in

The first link in the chain is a SQL injection in WP_Query, the internal class that builds nearly every database query WordPress runs. The vulnerable parameter is author__not_in: unsanitized input reaches the SQL string that WordPress assembles, allowing an attacker to inject arbitrary SQL into the query.

On its own, WP_Query is an internal API — an attacker can't call it directly from the internet. That's why CVE-2026-60137 affects a wider range of versions (6.8.0–6.8.5, 6.9.0–6.9.4 and 7.0.0–7.0.1) but wasn't immediately catastrophic by itself. The danger comes from any code path that forwards attacker-controlled input into those query arguments. Which is exactly what the second CVE provides.

CVE-2026-63030 — REST API Batch-Route Confusion

The second flaw sits in the WordPress REST API batch endpoint, which lets clients submit multiple API operations in a single HTTP request. A route-confusion bug allows a crafted batch request to reach internal query handling with attacker-controlled parameters that should never have been exposed — including the vulnerable author__not_in argument of WP_Query.

Chained together, the two bugs become WP2Shell: an unauthenticated attacker sends crafted HTTP requests to the REST API, the batch-route confusion smuggles their input into WP_Query, and the SQL injection fires. From there, observed attacks follow a consistent multi-stage playbook documented by Rapid7, Wiz and BleepingComputer:

• Stage 1 — Inject: exploit the batch-route confusion to deliver SQL through the vulnerable parameter;
• Stage 2 — Escalate: extract password hashes from the database or push directly toward code execution;
• Stage 3 — Persist: deploy PHP webshells, install fake plugins, and create rogue administrator accounts to survive patching.

The RCE chain affects WordPress 6.9.0–6.9.4 and 7.0.0–7.0.1 — default installs, no vulnerable plugin required. That is what makes WP2Shell categorically different from the plugin CVEs that dominate WordPress security news: there is no niche install base to hide behind. If you run WordPress, you were in scope.

Sources: Tenable WP2Shell FAQ, VulnCheck, Rapid7

Timeline: A Disclosure-to-Exploitation Window Measured in Hours

• Friday, July 17 (late): WordPress ships 7.0.2, 6.9.5 and 6.8.6; forced automatic updates begin rolling out where hosts allow them.
• Overnight July 17–18: public proof-of-concept exploit code appears.
• Saturday, July 18 (early UTC): KEVIntel telemetry shows successful exploitation already underway; Hexastrike honeypots record weekend attacks.
• Monday, July 20: Patchstack, Hexastrike and watchTowr publicly confirm in-the-wild exploitation; TechCrunch reports millions of sites at risk.
• Tuesday, July 21: CISA adds both CVEs to the KEV catalog. The Hacker News reports exploitation expanding into broad internet-wide mass scanning.

watchTowr CEO Benjamin Harris summed up the structural shift: the disclosure-to-exploitation window has collapsed — PoCs now appear within hours rather than the day-plus that was historically typical. A Friday-night patch release meant thousands of teams started their weekend unaware that exploit code was already circulating. By the time CISA's KEV listing landed on Tuesday, attackers had enjoyed an exposure window of at least three days.

Sources: TechCrunch, The Hacker News, SecurityWeek, KEVIntel

Am I Affected? Versions & Patch Verification

CVE	Flaw	Affected	Fixed in
CVE-2026-60137	SQL injection in WP_Query (author__not_in)	6.8.0–6.8.5, 6.9.0–6.9.4, 7.0.0–7.0.1	6.8.6 / 6.9.5 / 7.0.2
CVE-2026-63030	REST API batch-route confusion (RCE chain)	6.9.0–6.9.4, 7.0.0–7.0.1	6.9.5 / 7.0.2

Verify every site in your portfolio — do not assume the forced auto-update reached them:

# Check core version on each site
wp core version

# If below 6.8.6 / 6.9.5 / 7.0.2 on its branch — update NOW
wp core update

# Confirm auto-updates were not disabled
grep -rn "AUTOMATIC_UPDATER_DISABLED\|WP_AUTO_UPDATE_CORE" wp-config.php

Sites commonly missed by forced updates: hosts that disable auto-updates, Composer-managed WordPress (Bedrock), version-pinned containers, staging clones, and sites with filesystem permissions that block self-updates. For agencies, these "special" sites are exactly where WP2Shell compromises will still be found weeks from now.

Patched Is Not Clean: Post-Exploitation Forensics

Because exploitation began before most sites were patched, updating to 7.0.2 / 6.9.5 / 6.8.6 closes the door but does not evict anyone who already walked through it. Every security firm tracking WP2Shell — Rapid7, Wiz, Rescana, BleepingComputer — stresses the same point: inspect every site that ran a vulnerable version, even if it is patched today.

Indicators of compromise to hunt for

• Rogue administrator accounts created since July 17;
• PHP webshells — recently modified or added .php files, especially in wp-content/uploads/;
• Fake plugins installed as a code-execution foothold — directories in wp-content/plugins/ you don't recognize;
• Unexpected database changes — new rows in wp_users, modified siteurl/home options, injected content.

# List administrators — verify each one is legitimate
wp user list --role=administrator --fields=ID,user_login,user_registered

# PHP files modified in the last 10 days (exploitation began July 18)
find . -name "*.php" -mtime -10 -not -path "./wp-includes/*" \
  -not -path "./wp-admin/*"

# PHP files inside uploads — should be zero
find wp-content/uploads -name "*.php"

# Verify core file integrity against wordpress.org checksums
wp core verify-checksums

# List plugins — investigate anything you didn't install
wp plugin list --fields=name,status,version

If you find any of the above: treat the site as fully compromised. Rotate all credentials (WordPress admins, database, SFTP, hosting panel, API keys stored in wp-config.php), restore from a pre-July-17 backup where feasible, and rebuild rather than spot-clean — webshell operators routinely plant multiple redundant backdoors.

Why This Keeps Happening: The 5-Hour Reality

WP2Shell is the core-level proof of a trend Patchstack quantified for plugins: the median gap between disclosure and first observed exploitation of high-value WordPress vulnerabilities is about 5 hours, and roughly half of high-impact flaws are attacked within 24 hours. Attackers industrialized their pipeline — advisory feeds, automated diffing of patches, exploit generation, mass scanning — while most site owners still rely on weekly maintenance windows and email newsletters.

KEVIntel's telemetry on WP2Shell showed 13 unique attacker IPs across Switzerland, Germany, the U.K., Indonesia, Lithuania, the Netherlands and Singapore within days, hitting organizations of every size and vertical. The Hacker News reported that once the public exploit stabilized, activity expanded from WordPress-specific sensors to broad, internet-wide scanning. In that environment, the only defense posture that works is: know your exposure within hours, patch within hours, verify within hours.

Hardening beyond the patch

• Keep forced auto-updates enabled for core security releases — WP2Shell is the argument that settles this debate;
• Restrict the REST API surface where you can: authentication requirements, WAF rules on /wp-json/ batch requests, rate limiting;
• Monitor versions continuously across your whole portfolio — a CVE feed tied to what each site actually runs turns "did you see the news?" into an actionable per-site alert;
• File-integrity monitoring so a planted webshell triggers an alert instead of sitting quietly for months.

Frequently Asked Questions

Le week-end où le core WordPress a cessé d'être la partie sûre

Pendant des années, le conseil standard tenait : le core WordPress est la partie sûre — inquiétez-vous de vos plugins. Le rapport State of WordPress Security 2026 de Patchstack ne comptait que 6 vulnérabilités core sur 11 334 divulguées dans l'écosystème en 2025. Puis est arrivé le week-end du 18-19 juillet 2026.

Tard le vendredi 17 juillet, WordPress a publié les versions de sécurité 7.0.2, 6.9.5 et 6.8.6, corrigeant deux failles du core que des chercheurs ont rapidement démontré pouvoir être chaînées en exécution de code distant non authentifiée sur une installation WordPress par défaut. La chaîne a été surnommée WP2Shell. Du code d'exploitation public est apparu dans la nuit. Tôt samedi matin (UTC), les honeypots enregistraient déjà des exploitations réussies. Lundi 20 juillet, Patchstack, Hexastrike et watchTowr confirmaient tous des attaques dans la nature — et le 21 juillet, la CISA ajoutait les deux CVE à son catalogue Known Exploited Vulnerabilities.

L'échelle est difficile à surestimer. Selon les statistiques de versions de WordPress citées par TechCrunch, plus de 400 millions de sites exécutent les branches de versions affectées, et les estimations post-patch chiffrent encore les installations vulnérables en dizaines de millions. Ce guide explique le fonctionnement de la chaîne, les versions exactes affectées, comment vérifier que vous êtes patché — et surtout, comment vérifier si vous avez été compromis avant que le patch ne vous atteigne.

CVE-2026-60137 — Injection SQL dans author__not_in de WP_Query

Le premier maillon de la chaîne est une injection SQL dans WP_Query, la classe interne qui construit presque toutes les requêtes base de données de WordPress. Le paramètre vulnérable est author__not_in : une entrée non assainie atteint la chaîne SQL assemblée par WordPress, permettant à un attaquant d'injecter du SQL arbitraire.

Seule, WP_Query est une API interne — un attaquant ne peut pas l'appeler directement depuis internet. C'est pourquoi CVE-2026-60137 affecte une plage de versions plus large (6.8.0–6.8.5, 6.9.0–6.9.4 et 7.0.0–7.0.1) sans être immédiatement catastrophique en isolation. Le danger vient de tout chemin de code qui transmet des entrées contrôlées par l'attaquant vers ces arguments de requête. Ce que la seconde CVE fournit précisément.

CVE-2026-63030 — Confusion de routes du batch REST API

La seconde faille réside dans le endpoint batch de l'API REST WordPress, qui permet de soumettre plusieurs opérations API dans une seule requête HTTP. Un bug de confusion de routes permet à une requête batch forgée d'atteindre le traitement interne des requêtes avec des paramètres contrôlés par l'attaquant qui n'auraient jamais dû être exposés — dont l'argument vulnérable author__not_in de WP_Query.

Chaînés, les deux bugs deviennent WP2Shell : un attaquant non authentifié envoie des requêtes HTTP forgées vers l'API REST, la confusion de routes fait passer ses entrées dans WP_Query, et l'injection SQL se déclenche. Ensuite, les attaques observées suivent un scénario en trois étapes documenté par Rapid7, Wiz et BleepingComputer :

• Étape 1 — Injecter : exploiter la confusion de routes batch pour livrer du SQL via le paramètre vulnérable ;
• Étape 2 — Escalader : extraire les hashes de mots de passe de la base ou pousser directement vers l'exécution de code ;
• Étape 3 — Persister : déployer des webshells PHP, installer de faux plugins et créer des comptes administrateurs pirates pour survivre au patch.

La chaîne RCE affecte WordPress 6.9.0–6.9.4 et 7.0.0–7.0.1 — installations par défaut, aucun plugin vulnérable requis. C'est ce qui rend WP2Shell catégoriquement différent des CVE de plugins qui dominent l'actualité sécurité WordPress : il n'y a pas de base d'installation de niche derrière laquelle se cacher. Si vous exécutez WordPress, vous étiez dans le périmètre.

Chronologie : une fenêtre divulgation-exploitation mesurée en heures

• Vendredi 17 juillet (tard) : WordPress publie 7.0.2, 6.9.5 et 6.8.6 ; les mises à jour automatiques forcées commencent à se déployer.
• Nuit du 17 au 18 juillet : du code d'exploitation public apparaît.
• Samedi 18 juillet (tôt UTC) : la télémétrie KEVIntel montre une exploitation déjà en cours ; les honeypots Hexastrike enregistrent des attaques tout le week-end.
• Lundi 20 juillet : Patchstack, Hexastrike et watchTowr confirment publiquement l'exploitation ; TechCrunch rapporte des millions de sites à risque.
• Mardi 21 juillet : la CISA ajoute les deux CVE au catalogue KEV. The Hacker News rapporte une expansion vers du scan de masse à l'échelle d'internet.

Benjamin Harris, CEO de watchTowr, résume le changement structurel : la fenêtre divulgation-exploitation s'est effondrée — les PoC apparaissent désormais en heures plutôt qu'en jour et plus. Une publication de patch un vendredi soir signifiait que des milliers d'équipes ont commencé leur week-end sans savoir que du code d'exploitation circulait déjà. Au moment où l'inscription au KEV de la CISA est tombée mardi, les attaquants avaient bénéficié d'une fenêtre d'exposition d'au moins trois jours.

Suis-je affecté ? Versions & vérification du patch

CVE	Faille	Versions affectées	Corrigé dans
CVE-2026-60137	Injection SQL dans WP_Query (author__not_in)	6.8.0–6.8.5, 6.9.0–6.9.4, 7.0.0–7.0.1	6.8.6 / 6.9.5 / 7.0.2
CVE-2026-63030	Confusion de routes batch REST API (chaîne RCE)	6.9.0–6.9.4, 7.0.0–7.0.1	6.9.5 / 7.0.2

Vérifiez chaque site de votre portefeuille — ne supposez pas que la mise à jour forcée les a atteints :

# Vérifier la version du core sur chaque site
wp core version

# Si inférieure à 6.8.6 / 6.9.5 / 7.0.2 sur sa branche — mettre à jour MAINTENANT
wp core update

# Confirmer que les mises à jour auto ne sont pas désactivées
grep -rn "AUTOMATIC_UPDATER_DISABLED\|WP_AUTO_UPDATE_CORE" wp-config.php

Sites souvent manqués par les mises à jour forcées : hébergeurs qui désactivent les mises à jour auto, WordPress géré par Composer (Bedrock), conteneurs avec versions épinglées, clones de staging, et sites avec des permissions de fichiers bloquant l'auto-mise à jour. Pour les agences, ces sites « spéciaux » sont exactement là où des compromissions WP2Shell seront encore découvertes dans plusieurs semaines.

Patché ne veut pas dire propre : forensique post-exploitation

Parce que l'exploitation a commencé avant que la plupart des sites soient patchés, mettre à jour vers 7.0.2 / 6.9.5 / 6.8.6 ferme la porte mais n'expulse pas celui qui l'a déjà franchie. Toutes les sociétés de sécurité qui suivent WP2Shell — Rapid7, Wiz, Rescana, BleepingComputer — insistent sur le même point : inspectez chaque site ayant exécuté une version vulnérable, même s'il est patché aujourd'hui.

Indicateurs de compromission à rechercher

• Comptes administrateurs pirates créés depuis le 17 juillet ;
• Webshells PHP — fichiers .php récemment modifiés ou ajoutés, surtout dans wp-content/uploads/ ;
• Faux plugins installés comme point d'ancrage d'exécution de code — répertoires inconnus dans wp-content/plugins/ ;
• Changements inattendus en base — nouvelles lignes dans wp_users, options siteurl/home modifiées, contenu injecté.

# Lister les administrateurs — vérifier chacun
wp user list --role=administrator --fields=ID,user_login,user_registered

# Fichiers PHP modifiés ces 10 derniers jours
find . -name "*.php" -mtime -10 -not -path "./wp-includes/*" \
  -not -path "./wp-admin/*"

# Fichiers PHP dans uploads — il ne devrait y en avoir aucun
find wp-content/uploads -name "*.php"

# Vérifier l'intégrité du core contre les checksums wordpress.org
wp core verify-checksums

# Lister les plugins — investiguer tout inconnu
wp plugin list --fields=name,status,version

Si vous trouvez l'un des éléments ci-dessus : traitez le site comme entièrement compromis. Faites tourner tous les identifiants (admins WordPress, base de données, SFTP, panneau d'hébergement, clés API dans wp-config.php), restaurez depuis une sauvegarde antérieure au 17 juillet si possible, et reconstruisez plutôt que de nettoyer au cas par cas — les opérateurs de webshells plantent systématiquement plusieurs backdoors redondantes.

Pourquoi ça continue : la réalité des 5 heures

WP2Shell est la preuve au niveau du core d'une tendance que Patchstack a quantifiée pour les plugins : l'écart médian entre divulgation et première exploitation observée des vulnérabilités WordPress à forte valeur est d'environ 5 heures, et environ la moitié des failles à fort impact sont attaquées sous 24 heures. Les attaquants ont industrialisé leur pipeline — flux d'advisories, diffing automatisé des patches, génération d'exploits, scan de masse — pendant que la plupart des propriétaires de sites comptent encore sur des fenêtres de maintenance hebdomadaires.

La télémétrie KEVIntel sur WP2Shell a montré 13 IP d'attaquants uniques réparties entre Suisse, Allemagne, Royaume-Uni, Indonésie, Lituanie, Pays-Bas et Singapour en quelques jours, frappant des organisations de toutes tailles et tous secteurs. Dans cet environnement, la seule posture de défense qui fonctionne est : connaître son exposition en heures, patcher en heures, vérifier en heures.

Durcissement au-delà du patch

• Gardez les mises à jour automatiques forcées activées pour les releases de sécurité du core — WP2Shell est l'argument qui clot le débat ;
• Restreignez la surface de l'API REST quand c'est possible : exigences d'authentification, règles WAF sur les requêtes batch /wp-json/, rate limiting ;
• Surveillez les versions en continu sur tout votre portefeuille — un flux CVE lié à ce que chaque site exécute réellement transforme « tu as vu la news ? » en alerte actionnable par site ;
• Monitoring d'intégrité des fichiers pour qu'un webshell planté déclenche une alerte au lieu de rester silencieux des mois.

Questions fréquentes