Draaien jullie WordPress 6.9 of hoger? Update. Nu.

Gisteren zijn twee kwetsbaarheden in WordPress-core bekendgemaakt. Elk op zichzelf al vervelend, maar niet het einde van de wereld.

Door beide kwetsbaarheden te combineren, laten ze iedere bezoeker een site overnemen. Zonder inlog.

Dat is 'wp2shell': WordPress zelf schaalt de melding in als de zwaarste categorie die er is.

Voor Core-gebruikers

Op Core is het grootste gevaar geweken. Vanmiddag hebben we alle requests naar /wp-json/batch/v1 en ?rest_route=/batch/v1 geblokkeerd. De 'ingang' van de kwetsbaarheid is daarmee niet meer bereikbaar. Dit is ook van toepassing op sites op het WebOps-platform. Meer informatie over deze URL's lees je in dit artikel.

Voor andere platforms (DirectAdmin & managed VPS) bestaat deze mogelijkheid niet.

Update desalniettemin direct.

Achtergrond: twee bugs, één keten

Bug 1: SQL-injectie in WP_Query (CVE-2026-60137)

WP_Query is de functie die WordPress overal gebruikt om artikelen, gebruikers en instellingen uit de database te halen. Vrijwel elke plug-in en elk thema roept die aan.

Eén van de parameters, author__not_in, verwacht een lijst met gebruikers-ID's. Geeft een plug-in of thema in plaats van een lijst tekst mee, dan slaat WordPress zijn controle over en propt de tekst rechtstreeks in de databasequery. Een aanvaller kan zo 'meeschrijven' aan die query, en bijvoorbeeld wachtwoord-hashes van beheerders uitlezen. Dat noemen we SQL-injectie.

Dit lek is er vanaf WordPress 6.8. Op zichzelf is de schade beperkt: om author__not_in überhaupt te kunnen aanroepen, moest je al 'binnen' zijn. Als kwaadwillende gebruiker, plug-in of thema. Dat is een flinke drempel.

Bug 2: het REST API batch-endpoint gaat de mist in (CVE-2026-63030)

WordPress heeft een 'batch-endpoint' op /wp-json/batch/v1. Bedoeld voor ontwikkelaars die meerdere API-verzoeken in één keer willen versturen. WordPress werkt ze achter elkaar af.

Tijdens die afhandeling houdt WordPress twee lijstjes bij: de binnenkomende sub-verzoeken, en de 'handlers' die ze mogen uitvoeren. Zodra één van de sub-verzoeken misgaat, lopen die lijsten één positie uit de pas. Vanaf dat punt draaien de resterende verzoeken onder de verkeerde handler.

Gevolg: waar een sub-verzoek normaliter een inlog zou vereisen, kan die nu per abuis worden uitgevoerd door een handler die die eis niet heeft. De drempel van de eerste bug is daarmee weg. SQL-injectie zonder inlog, dus.

Van webverzoek naar shell

Samen leveren de twee bugs een 'pre-auth RCE' op: een willekeurige buitenstaander kan zonder inlog code draaien op je server. Vandaar de naam wp2shell.

Welke versies zijn kwetsbaar?

  • Ouder dan 6.8: geen last van deze bugs.
  • 6.8.x: alleen de SQL-injectie. Update naar 6.8.6.
  • 6.9.x: beide bugs. Update naar 6.9.5.
  • 7.0.x: beide bugs. Update naar 7.0.2.
  • 7.1 Beta 2: fix aanwezig.

Draai je 6.9 of hoger, dan zit je sowieso in de gevarenzone.

WordPress duwt updates door, maar…

WordPress heeft de melding zelf als hoogste prioriteit gemarkeerd en forceert automatische updates naar getroffen sites. Voor het gros van de sites gaat dat vanzelf goed.

WordPress bevestigt niet dat de 'forced push' óók sites bereikt waar automatische updates zijn uitgezet. Ga er dus niet vanuit dat jullie site(s) geüpdatet zijn. Kijk in je dashboard welke versie er nu écht draait, in plaats van te vertrouwen op dat het wel is opgepakt.

← Terug naar Insights