wp2shell: het kritieke WordPress-lek dat je site zonder wachtwoord overneemt

Op 17 juli 2026 bracht WordPress een noodupdate uit. Niet voor een obscure plugin, maar voor de kern zelf. Twee kwetsbaarheden, door de onderzoekers gedoopt tot wp2shell, maakten het samen mogelijk om zonder wachtwoord en zonder ook maar een plugin code uit te voeren op een standaard WordPress-installatie. Nog dezelfde avond werd er op gescand, en dertien minuten na die eerste scans volgden de eerste injectiepogingen.

Wordfence noemt het een van de grootste WordPress-problemen in bijna tien jaar. In dit artikel lees je wat wp2shell precies is, welke versies kwetsbaar zijn, wat aanvallers achterlaten op een besmette website en welke stappen je nu moet zetten. Ook als je denkt dat automatische updates het al voor je hebben opgelost.

Wat is wp2shell?

wp2shell is niet een bug, maar een keten van twee. Los van elkaar zijn ze al vervelend, aan elkaar geknoopt vormen ze een aanval waar geen wachtwoord aan te pas komt:

• CVE-2026-63030 (kritiek): een logische fout in de REST API batch-endpoint van WordPress. De controle en de uitvoering raken uit de pas, waardoor een verzoek onder de verkeerde handler wordt afgehandeld.
• CVE-2026-60137 (hoog): een SQL-injectie via de parameter author__not_in. Die wordt normaal netjes tegengehouden, maar via de batch-route glipt hij er alsnog doorheen.

Samen leveren ze wat in securitytaal een pre-auth RCE heet: remote code execution zonder authenticatie. Een aanvaller heeft geen account nodig, geen wachtwoord en geen bijzondere configuratie. Een anoniem verzoek naar een kwetsbare website is genoeg om een beheerdersaccount aan te maken, een plugin te uploaden of code uit te voeren.

De SQL-injectie werd gemeld door de onderzoekers TF1T, dtro en haongo. De REST API-kwetsbaarheid kwam van Adam Kues van Assetnote, onderdeel van Searchlight Cyber. WordPress bedankt ze allebei in de release-aankondiging van 7.0.2.

Welke WordPress-versies zijn kwetsbaar?

• Volledige aanvalsketen, dus code-uitvoering: WordPress 6.9.0 tot en met 6.9.4 en 7.0.0 tot en met 7.0.1.
• Alleen de SQL-injectie: WordPress 6.8.0 tot en met 6.8.5.
• Gerepareerd in: 7.0.2, 6.9.5 en 6.8.6, alle drie uitgebracht op 17 juli 2026. Ook 7.1 beta 2 kreeg de fix.

Versies ouder dan 6.8 zijn niet kwetsbaar voor wp2shell. Dat is geen geruststelling: wie nog op zo’n oude versie draait, heeft een rijtje andere lekken openstaan waar dit artikel niet eens over gaat.

Waarom dit zwaarder weegt dan de gemiddelde beveiligingsmelding

Er verschijnen wekelijks kwetsbaarheden in het WordPress-ecosysteem. Bijna altijd zit er een voorwaarde aan: je moet een specifieke plugin gebruiken, of de aanvaller moet al ingelogd zijn. wp2shell heeft geen van die remmen.

• Geen inlog nodig, geen plugin nodig. Een kale WordPress-installatie is genoeg.
• WordPress draait op ruim veertig procent van alle websites, dus het aanvalsoppervlak is gigantisch.
• Toen de CVE’s verschenen had zestig procent van de onderzochte organisaties minstens een kwetsbare installatie draaien, en een kwart had een kwetsbare server direct aan het internet hangen.
• Publieke exploitcode was er binnen enkele dagen, dus het bleef niet bij specialisten.

Van patch naar misbruik in dertien minuten

Het tempo is het echte verhaal. Een patch is namelijk ook een routebeschrijving: aanvallers lezen de wijziging en weten daarmee waar het gat zat.

• 17 juli, 23:29 UTC: de eerste verkennende verzoeken op het batch-endpoint, een paar uur na de patch.
• Dertien minuten later: de eerste SQL-injectiepogingen.
• 19 juli: VulnCheck telt ruim twee dozijn unieke, publiek beschikbare proof-of-concepts.
• 21 juli: CISA zet CVE-2026-63030 in de lijst van kwetsbaarheden waarvan misbruik is bevestigd.
• 22 juli: de volledige technische details gaan naar buiten.

WordPress.org zette geforceerde automatische updates aan voor getroffen versies. Dat gebeurt alleen als de nood echt hoog is.

Een kijkje in een besmette website

Johannes Ullrich van het SANS Internet Storm Center beschreef op 20 juli wat hij aantrof op een site die het niet had gered. Dat verslag is leerzamer dan welke waarschuwing ook, want het laat zien hoe onzichtbaar zo’n inbraak is.

• Er stond een webshell in /wp-content/cache/ met een willekeurige bestandsnaam, in dit geval 94uh9ubh6e1x.php. Die naam is meteen het wachtwoord: wie hem niet kent, komt er niet in.
• Het bestand geeft een 404 terug terwijl het er gewoon staat. Een vluchtige controle ziet dus niets bijzonders.
• Via parameters in de URL voert de shell commando’s uit, achter elkaar proberend met system, passthru, exec, shell_exec en popen tot er een werkt.
• Daarna verschenen er nieuwe beheerdersaccounts in de database.
• In de logs vielen user agents op als cve-2026-63030/1.0, en elders werden ook wp2shell en rezwp2shell gezien.

Onderzoekers van Wiz zagen daarnaast kwaadaardige plugins die via de gewone uploadfunctie werden geinstalleerd, REST API-verzoeken om beheerdersnamen en e-mailadressen op te halen, en pogingen om wp-config.php uit te lezen. De aangetroffen webshells liepen uiteen van een regel code tot uitgebreide, versluierde beheerpanelen van 150 kB.

Het venijn zit in de volgorde. De update dicht het gat, maar ruimt niet op wat er al binnen is. Een website die op 18 juli netjes is bijgewerkt kan sinds 17 juli een achterdeur hebben waar de update niets aan verandert.

Wat je nu moet doen

Loop deze stappen langs, ook als je vermoedt dat het al geregeld is. De controle kost een kwartier, het alternatief kost een week.

1. Controleer je versie. Je vindt hem rechtsonder in je WordPress-dashboard. Alles onder 6.8.6, 6.9.5 of 7.0.2 is niet in orde.
2. Update meteen, en controleer daarna of het echt is gelukt. Geforceerde updates slaan soms over bij aangepaste of afgeschermde installaties. Vertrouw niet op de belofte, kijk naar het versienummer.
3. Kun je niet direct updaten? Blokkeer dan tijdelijk de batch-endpoints /wp-json/batch/v1 en /?rest_route=/batch/v1 via je firewall of WAF. Dat is een pleister, geen oplossing.
4. Controleer je gebruikers. Staat er een beheerder die je niet kent of niet zelf hebt aangemaakt, dan heb je je antwoord.
5. Zoek naar vreemde PHP-bestanden. Kijk in /wp-content/cache/ en in je uploadmappen. Daar hoort geen PHP te staan, en zeker geen bestand met een willekeurige naam en een recente datum.
6. Loop je plugins na. Alles wat je niet zelf hebt geinstalleerd, is verdacht. Ook als het een geloofwaardige naam heeft.
7. Doorzoek je logbestanden. Let op verzoeken naar de batch-endpoints en op de user agents hierboven. Zie je die, ga er dan van uit dat het raak was tot het tegendeel blijkt.

Vind je iets, doe dan niet alleen het gevonden bestand weg. Zet de website terug vanaf een back-up van voor 17 juli, vernieuw je wachtwoorden en beveiligingssleutels, en controleer daarna opnieuw. Een aanvaller die binnen is geweest, laat zelden maar een deur open staan.

Bijgewerkt is niet hetzelfde als veilig

Dagen na de patch stond de teller op ongeveer 81,6 procent bijgewerkte websites. Een op de vijf stond dus nog open, terwijl de exploits allang rondzwierven. Dat komt zelden door onwil. Het komt doordat niemand zich eigenaar voelt van het onderhoud: de bouwer is klaar, de hosting doet alleen de server en de eigenaar heeft een bedrijf te runnen.

Automatische updates helpen, maar ze testen niets, ze slaan soms over en ze zeggen niets over plugins die al jaren geen onderhoud meer krijgen. Bij een lek als dit is de vraag niet of je een update krijgt, maar of iemand controleert dat hij is doorgevoerd en of er intussen niets is achtergebleven.

Dat is precies wat wij doen met WordPress onderhoud: updates in een vast ritme en bij kritieke lekken direct, controle achteraf, dagelijkse back-ups en monitoring op wat er binnenkomt. Wil je liever eerst het bredere plaatje, lees dan waarom je website onderhouden geen kostenpost maar een investering is.

Bronnen

• WordPress.org, WordPress 7.0.2 Release, de officiele beveiligingsrelease met de credits en getroffen versies.
• SANS Internet Storm Center, WordPress Exploitation Underway, het verslag van Johannes Ullrich over een besmette website.
• Wiz, Exploitation in the Wild of wp2shell, met de waargenomen aanvalspatronen en indicatoren.
• Rapid7, CVE-2026-63030 wp2shell, de technische duiding van de keten.
• BleepingComputer, Critical wp2shell WordPress flaws exploited to install webshells, met de tijdlijn van het misbruik.
• Security.NL, de Nederlandse berichtgeving over het misbruik kort na de patch.