wp2shell (CVE-2026-63030): een pre-auth RCE in WordPress Core, en wat u nu moet doen

wp2shell is een remote code execution-lek zonder authenticatie in WordPress Core, wat betekent dat een anonieme aanvraag, zonder login en zonder dat een kwetsbare plugin nodig is, code kan uitvoeren op een standaardinstallatie. Het lek koppelt twee bugs die op 17 juli 2026 werden onthuld aan elkaar: een SQL-injectie in WordPress' WP_Query (CVE-2026-60137) en een verwarring rond de batch-route van de REST API (CVE-2026-63030). Binnen enkele uren verschenen publieke exploits, binnen enkele dagen werden aanvallen in de praktijk bevestigd, en CISA voegde beide bugs toe aan zijn Known Exploited Vulnerabilities-catalogus. Als u een zelf gehoste WordPress-site draait op 6.9.x of 7.0.x, kunt u alleen veilig aannemen dat u een doelwit bent: werk onmiddellijk bij naar 6.9.5 of 7.0.2 en controleer daarna of iemand binnen is gekomen voordat u patchte.

Wat is wp2shell, en waarom is het zo ernstig?

wp2shell is de naam die onderzoekers van Searchlight Cyber gaven aan een keten van twee bugs in WordPress Core zelf, niet in een plugin of thema. Dat onderscheid maakt het zo ernstig. Een pluginlek treft de sites die die plugin hebben geïnstalleerd; een Core-lek treft een kale, vers geïnstalleerde WordPress zonder toevoegingen. WordPress draait naar schatting op meer dan 500 million sites, en elke daarvan op een getroffen versie stelt het kwetsbare eindpunt standaard bloot.

De ernst zit in de keten. Tenable beoordeelt de bug in de REST-batch-route, CVE-2026-63030, op CVSS 9.8, en de SQL-injectie, CVE-2026-60137, op 5.9. Op zichzelf is elk een probleem; samen laten ze een niet-geauthenticeerde aanvaller vanaf één enkele HTTP-aanvraag doorstoten naar een volledige overname als administrator. Geen inloggegevens, geen gebruikersinteractie, geen tweede houvast nodig.

Hoe de exploitketen werkt

Het slimme eraan is hoe de twee bugs elkaar afdekken. WordPress' queryparameter author__not_in wordt rechtstreeks in ruwe SQL geïnterpoleerd wanneer die als scalaire string wordt doorgegeven — een klassieke injectie, ware het niet dat de normale aanvraagvalidatie de misvormde invoer weigert voordat die de database bereikt.

En daar komt de batch-API om de hoek kijken. Het eindpunt /wp-json/batch/v1 valideert en voert subaanvragen uit in twee gescheiden lussen. Wanneer wp_parse_url() faalt op een geprepareerd subaanvraagpad, wordt de fout wel geregistreerd in de validatie-array, maar wordt de aanvraag niet uit de uitvoerings-array verwijderd. De twee lijsten raken uit synchronisatie, de validatie wordt overgeslagen en een recursieve batch-aanroep smokkelt een UNION-gebaseerde SQL-injectie er dwars doorheen. Van daaruit koppelt de exploit interne WordPress-onderdelen aan elkaar om een administrator-account aan te maken, logt daarmee in en uploadt een kwaadaardige plugin, en die plugin is de payload voor code-uitvoering. Eén aanvraag erin, een webshell eruit.

Welke WordPress-versies zijn getroffen?

De volledige RCE-keten werkt alleen waar de batch-route bestaat, die WordPress in 6.9 introduceerde. De SQL-injectie alleen reikt verder terug. Er zijn gepatchte releases uitgebracht voor alle drie de ondersteunde branches.

Branch	Getroffen versies	Gepatcht in	Blootstelling
7.0.x	7.0.0 – 7.0.1	7.0.2	Volledige pre-auth RCE
6.9.x	6.9.0 – 6.9.4	6.9.5	Volledige pre-auth RCE
6.8.x	6.8.0 – 6.8.5	6.8.6	Alleen SQL-injectie (CVE-2026-60137)

Omdat het lek in Core zit en het risico kritiek is, heeft het beveiligingsteam van WordPress.org geforceerde automatische updates ingeschakeld voor sites op getroffen versies. Dat helpt, maar geforceerde updates worden geleidelijk uitgerold en kunnen in wp-config.php worden uitgeschakeld, dus wacht niet tot u wordt bijgewerkt; haal de update zelf binnen.

Wordt wp2shell nu actief misbruikt?

Ja, en snel. Binnen enkele uren na de onthulling verschenen er meerdere proof-of-concept-exploits op GitHub, sommige met AI-ondersteuning. Vrijwel meteen daarna volgde aanvalstelemetrie: beveiligingsbedrijf watchTowr meldde dat zijn honeypots tienduizenden misbruikpogingen registreerden vanaf 13 verschillende aanvaller-IP's in Europa en Azië, met succesvolle compromitteringen binnen een dag. Op 21 juli 2026 werden beide CVE's toegevoegd aan CISA's Known Exploited Vulnerabilities-catalogus, het duidelijkste signaal dat dit actief is, niet theoretisch.

Het gedrag na de exploitatie is wat er voor verdedigers toe doet. Aanvallers hebben meer dan 100 administrator-accounts als achterdeur aangemaakt, een PHP-webshell van ongeveer 150 KB geplaatst, vermomd als een beveiligingsplugin genaamd "CMSmap", beheerdersgebruikersnamen en databasegegevens verzameld en in sommige gevallen geprobeerd een op Go gebaseerde remote access trojan genaamd Overlord RAT te installeren. Met andere woorden: het patchen van een machine die al geraakt was, zet de aanvaller er niet uit, omdat die een sleutel voor zichzelf heeft achtergelaten.

Patch nu: de oplossing van vijftien minuten

Voor iedereen die zijn eigen WordPress draait, is de prioriteitsvolgorde eenvoudig:

1. Werk Core bij naar 6.9.5, 7.0.2 of 6.8.6. Vanuit het dashboard is dit één klik; via WP-CLI is het wp core update && wp core update-db. Dit is de enige echte oplossing; al het onderstaande is een noodverband.
2. Blokkeer het batch-eindpunt als u niet op dit moment kunt bijwerken. Weiger aanvragen naar /wp-json/batch/v1 en het equivalente ?rest_route=/batch/v1 op uw webserver of WAF. Cloudflare heeft een beheerde WAF-regel uitgerold naar alle abonnementen, inclusief het gratis abonnement, zodat sites die erachter draaien automatisch basisdekking krijgen.
3. Beperk anonieme REST-toegang met een plugin of een klein must-use-filter dat authenticatie vereist op de REST API, waarmee u het injectiepad sluit.
4. Bevestig achteraf de versie. Controleer Dashboard → Updates of voer wp core version uit, zodat een vastgelopen automatische update u niet in de waan laat dat u veilig bent terwijl dat niet zo is.

Als u servers beheert, is de echte les hier dat u Core-updates behandelt als een beveiligingsgebeurtenis voor dezelfde dag in plaats van als een maandelijkse klus; onze gids over het veilige eerste uur op een nieuwe VPS legt uit hoe u die discipline vanaf het begin inbakt. Wij draaien de infrastructuur van deze site via WaseerHost, ons hostingbedrijf, en lekken op Core-niveau zoals dit zijn precies de reden waarom beheerde WordPress-abonnementen beveiligingsreleases forceren zodra ze worden uitgebracht.

Al gepatcht? Controleer eerst of u geraakt bent

Dit is de stap die de meeste artikelen overslaan, en het is degene die u redt. Elk beveiligingsbedrijf dat wp2shell volgt, herhaalt dezelfde waarschuwing: inspecteer uw site op tekenen van compromittering, ongeacht of u hebt gepatcht, want het bijwerken van Core doet niets aan een reeds geplante achterdeur. Loop dit door op elke server die blootgesteld was:

• Controleer de administrator-accounts. wp user list --role=administrator zou alleen mensen moeten tonen die u herkent. Het handtekening van deze aanval is onverwachte beheerdersgebruikers, soms tientallen. Verwijder alle die u niet hebt aangemaakt en reset de wachtwoorden van degene die u behoudt.
• Grep uw toegangslogs. Zoek naar treffers op de batch-route: grep -E "batch/v1" access.log. Aanvragen naar /wp-json/batch/v1 of ?rest_route=/batch/v1 vanaf onbekende IP's, vooral geclusterd vóór het moment van uw patch, vormen de vingerafdruk van de exploitatie.
• Ga op jacht naar de webshell. Zoek naar recent gewijzigde of buitensporig grote PHP-bestanden onder wp-content/plugins en wp-content/uploads, en naar een plugin die u nooit hebt geïnstalleerd (de naam "CMSmap" is waargenomen, maar ga ervan uit dat die hernoemd kan worden). find wp-content -name '*.php' -mtime -7 is een snelle eerste controle.
• Roteer uw geheimen. Als er enig teken van compromittering is, vervang dan de authenticatiesleutels en salts in wp-config.php, forceer een wachtwoordreset voor alle gebruikers en roteer de databasegegevens die de aanvaller mogelijk heeft buitgemaakt.

Als u een achterdeur vindt, is patchen geen herstel: zet terug vanaf een betrouwbare back-up die vóór de onthullingsdatum is gemaakt en werk daarna bij. Een compromittering die zo netjes is, lijkt qua aard meer op een supply-chain-inbraak dan op een pluginbug: de vertrouwensgrens was het platform zelf.

Veelgestelde vragen

Ben ik getroffen als mijn site geen extra plugins heeft? Ja, en dat is precies de kern. wp2shell misbruikt WordPress Core, dus een standaardinstallatie met nul plugins op een getroffen versie (6.9.0–6.9.4 of 7.0.0–7.0.1) is kwetsbaar voor de volledige remote code execution-keten. Het toevoegen of verwijderen van plugins verandert niets aan uw blootstelling aan het Core-lek.

Verwijdert bijwerken een aanvaller die al binnen is? Nee. Patchen sluit de deur, maar als iemand er doorheen liep voordat u patchte, kan die een administrator-account als achterdeur of een webshell hebben achtergelaten die de update overleeft. Dat moet u apart opsporen en verwijderen, of terugzetten vanaf een back-up van vóór de onthulling.

Wat als ik niet meteen kan bijwerken? Blokkeer /wp-json/batch/v1 en ?rest_route=/batch/v1 op uw firewall of WAF, en plaats de site achter een dienst zoals Cloudflare die een beheerde regel heeft uitgerold. Dit zijn mitigaties, geen oplossingen, dus plan de Core-update zo snel mogelijk in en controleer achteraf de versie.

Is een volledig beheerde WordPress-host veilig? Grotendeels, als de host de Core-beveiligingsrelease geforceerd heeft doorgevoerd, wat betrouwbare beheerde aanbieders binnen enkele uren deden. Het blijft de moeite waard om uw versie te bevestigen en te controleren op verdachte beheerdersaccounts, want een beheerd bedieningspaneel ruimt niet automatisch een compromittering op die vóór de patch plaatsvond.

Houdt dit verband met de patchgolf van juni 2026? Nee, het is een apart probleem in WordPress Core, maar het valt in een toch al lelijke periode. Zie onze samenvatting van de recordbrekende Patch Tuesday van juni 2026 voor de bredere context over hoe snel kritieke bugs in 2026 worden bewapend.

Sources

• Strobes — wp2shell: Pre-Auth RCE in WordPress Core: onthullingsdatum en overzicht van de keten.
• Tenable — wp2shell (CVE-2026-63030, CVE-2026-60137) FAQ: CVSS-scores, getroffen/gepatchte versies en WAF-mitigatie.
• Rapid7 — CVE-2026-63030: wp2shell RCE in WordPress Core: werking van de exploitketen en toevoeging aan CISA KEV.
• BleepingComputer — WordPress Core "wp2shell" RCE flaws get public exploits: ontdekker, geforceerde automatische updates en schaal.
• The Hacker News — WordPress wp2shell exploitation grows: in-the-wild indicatoren van compromittering en activiteit na exploitatie.