Wat wp2shell werkelijk doet

Toen Adam Kues van Assetnote een speciaal opgesteld verzoek naar een gewone WordPress-installatie stuurde, voerde de server zijn code uit. Geen account, geen wachtwoord, geen plugin, geen ongebruikelijke instelling. De onderzoekers noemden de keten wp2shell, WordPress kende er CVE-2026-63030 aan toe, en beide partijen beoordeelden die als kritiek.

De exploit rijgt twee zwakheden in de batchroute van de REST-API aaneen: een routeringsverwarring die een niet-geauthenticeerde beller toegang geeft tot codepaden die afgeschermd zouden moeten zijn, en een daardoor bereikbare SQL-injectie. Aaneengeregen maken ze van een anoniem HTTP-verzoek code-uitvoering, het zwaarste gevolg dat een weblek kan hebben.

Waarom de automatische patch niet de finish is

WordPress bracht 6.9.5 en 7.0.2 uit op 17 juli 2026 en dwong de updates gezien de ernst af op getroffen sites in plaats van te wachten op een klik van de eigenaar. Dat is de juiste keuze en de meeste sites zijn nu dicht. Het verhult ook de moeilijkere vraag.

Een lek zonder authenticatie betekent dat iedereen op internet het kon gebruiken voordat u patchte, en de correctie installeren draait dat niet terug. Was uw site tijdens het blootstellingsvenster bereikbaar en ongepatcht, dan haalde de update de deur weg maar niet wat er al door was gegaan: een ingeschoven beheerdersaccount, een geplande taak, een webshell in de uploadmap.

Waarom vrijwel elke eigenaar onder de reikwijdte valt

Dit zat in de kern, de software die elke WordPress-site draait, dus de blootstelling hing niet af van een niche-plugin of thema. WordPress draait bijna 40 procent van het web, en daarom is een enkel kernlek van deze klasse een massale gebeurtenis en geen randgeval.

De versies 6.9.0 tot en met 6.9.4 en 7.0.0 tot en met 7.0.1 waren kwetsbaar voor wp2shell. Het tweede lek, een SQL-injectie in de parameter author__not_in van WP_Query met CVSS 9.1, gaat terug tot 6.8, zodat een site die enkele maanden geen update installeerde het grootste van de twee blootstellingsvensters droeg.

Wat EU-regels ervan maken

Voor een Europees bedrijf is het lek niet alleen technisch. Staan er persoonsgegevens achter die site, dan geeft de AVG u 72 uur om uw toezichthouder te melden zodra u kennis krijgt van een inbreuk, en 'we kunnen het niet uitsluiten' ligt dichter bij die kennis dan bij geruststelling.

Voor essentiële en belangrijke entiteiten onder NIS2 zet een incident van deze ernst zijn eigen vroegwaarschuwings- en meldklok in gang, en toezichthouders verwachten steeds vaker bewijs van detectie, niet alleen een patchlogboek. Een afgedwongen automatische update is een verdediging die u niet koos; of u daarna op compromittering controleerde, staat wel in uw logboek.

De controle die nu moet gebeuren

Bevestig dat de site op 6.9.5 of 7.0.2 draait en behandel dan het blootstellingsvenster als het echte werk. Bekijk beheerdersaccounts en applicatiewachtwoorden die in juli zijn aangemaakt, inspecteer geplande taken en recent gewijzigde PHP-bestanden, en haal de webserverlogs op voor ongewone POST-verzoeken aan de REST-API rond de datum van openbaarmaking.

Draait u beheerde WordPress, vraag uw host dan schriftelijk wanneer de patch binnenkwam en of hij misbruikpogingen tegen uw site zag. Het eerlijke antwoord op 'zijn we geraakt' komt zelden meteen, maar de eigenaren die deze week vragen zijn degenen die volgend kwartaal geen stille inbreuk hoeven uit te leggen.

Lees hierna: Een dood gebouw kost meer dan losgeld  |  Uw sandbox geraakt, een maand voor de waarschuwing