Op 17 juli 2026 bracht WordPress.org versie 7.0.2 uit, een noodpatch voor een kwetsbaarheid die inmiddels bekendstaat als wp2shell. De ernst was zo hoog dat WordPress.org besloot geforceerde automatische updates te activeren voor alle kwetsbare installaties, iets wat maar zelden gebeurt bij een kernupdate. Wie zelf niets deed, kreeg de patch toch binnen, althans in theorie. In de praktijk bleek dat lang niet elke website automatisch is bijgewerkt.
Dit soort noodpatches raakt direct aan een vraag die we bij MonkeySoft geregeld van klanten krijgen: is patchen niet gewoon een kwestie van “automatische updates aanzetten en klaar”? Dit lek laat precies zien waarom dat te kort door de bocht is, en waarom doorlopende monitoring, zoals we die bij MonkeySoft via ons SitesMonkey-platform inrichten, minstens zo belangrijk is als de patch zelf.
Wat gebeurde er?
Beveiligingsonderzoekers ontdekten een keten van twee kwetsbaarheden in de WordPress-kern die samen leiden tot remote code execution zonder dat een aanvaller hoeft in te loggen. De eerste, CVE-2026-60137, is een SQL-injectiekwetsbaarheid. De tweede, CVE-2026-63030, betreft een verwarring in de manier waarop de REST API batch-routes verwerkt, specifiek rond het endpoint /wp-json/batch/v1. Gecombineerd stelt deze keten een aanvaller in staat om met één enkel, anoniem verzoek eigen code op een kwetsbare server uit te voeren.
Volgens beveiligingsonderzoek van Aikido werkt de aanval al op een volledig standaard WordPress-installatie, zonder dat er een kwetsbare plugin bij nodig is. Dat maakt dit lek zeldzaam: kernkwetsbaarheden in WordPress zijn ongebruikelijk. Uit cijfers van Patchstack, aangehaald door 84EM, blijkt dat 91 procent van de gemelde WordPress-kwetsbaarheden in plugins zit, en slechts een handvol in de kern zelf. Precies daarom werd dit lek serieus genomen en volgde er binnen een dag een noodpatch, met een dag voorsprong voor hostingpartijen en CDN’s voordat het lek publiek werd gemaakt.
De getroffen versies: WordPress 6.9.0 tot en met 6.9.4, en 7.0.0 tot en met 7.0.1. Voor deze versies zijn respectievelijk 6.9.5 en 7.0.2 uitgebracht. WordPress 6.8 is kwetsbaar voor alleen de SQL-injectie en is gepatcht in 6.8.6. Versies ouder dan 6.8 zijn niet geraakt door deze specifieke keten, maar lopen doorgaans wel tegen andere, oudere kwetsbaarheden aan.
Waarom is dit belangrijk?
De reflex bij dit soort nieuws is vaak: “WordPress.org heeft toch automatische updates ingeschakeld, dus dit lost zichzelf op.” Die aanname is precies het risico. Geforceerde auto-updates werken alleen op sites waar automatische updates technisch ook daadwerkelijk zijn ingeschakeld en functioneren. In de praktijk staat dit bij een aanzienlijk deel van de MKB-websites om uiteenlopende redenen uit: een beheerplugin die updates blokkeert tot handmatige goedkeuring, een hostingpartij die eigen updatebeleid voert, of een eerdere update die faalde en de site sindsdien in een inconsistente staat achterliet.
Daarnaast zegt “de update is binnengekomen” niets over wat er vóór dat moment is gebeurd. Tussen het uitkomen van een kwetsbaarheid en het daadwerkelijk patchen van een site zit vrijwel altijd een venster waarin geautomatiseerde scanners actief op zoek gaan naar kwetsbare installaties. Bij een ongeautoriseerde RCE-keten zoals wp2shell is dat venster het gevaarlijkst moment van de hele cyclus, en precies het moment waarop reactieve “we werken wel een keer bij” processen tekortschieten.
Wat zijn de risico’s?
Een succesvolle remote code execution op een WordPress-server is zelden het eindstation van een aanval. Vanaf dat punt kan een aanvaller:
- Een webshell plaatsen, een verborgen stukje code waarmee de aanvaller op elk gewenst moment terug kan komen, ook nadat de oorspronkelijke kwetsbaarheid allang is gepatcht.
- Klantgegevens en formulierdata stelen uit de database, inclusief eventuele persoonsgegevens die onder de AVG vallen.
- De website gebruiken voor phishing of malware-verspreiding, waarbij bezoekers van de site zelf slachtoffer worden, met reputatieschade voor het bedrijf als gevolg.
- Zijwaarts bewegen naar andere sites of applicaties op dezelfde server, zeker bij gedeelde hosting of meerdere WordPress-installaties op één omgeving.
- De site inzetten voor cryptomining of botnetactiviteit, wat vaak pas opvalt door trage laadtijden of een plotselinge stijging in serverbelasting.
Voor MKB-bedrijven die eerder dit jaar te maken kregen met de Cyberbeveiligingswet of die NIS2-verplichtingen hebben, telt hier ook mee dat een gecompromitteerde website met klantgegevens onder de meldplicht kan vallen. En zoals we al aanhaalden bij het vorige patch-nieuws over Microsoft SharePoint: hoe sneller een kwetsbaarheid publiek wordt, hoe sneller geautomatiseerde aanvallers hem oppikken. Bij wp2shell was er een verificatietool (wp2shell.com) beschikbaar binnen dagen na de release, wat betekent dat ook minder ervaren aanvallers snel konden testen welke sites nog kwetsbaar waren.
Wat moet een MKB-bedrijf nu doen?
Vijf concrete stappen voor wie een WordPress-website beheert of laat beheren:
- Controleer de daadwerkelijke versie. Log in op het WordPress-dashboard en controleer onder Updates of de site echt op 7.0.2 (of 6.9.5, 6.8.6) draait. Ga niet uit van de aanname dat de geforceerde update is aangekomen.
- Controleer of automatische updates functioneren. Sommige beheerplugins of hostingconfiguraties zetten automatische kernupdates standaard uit. Zet deze aan voor kernupdates, of regel een proces waarin iemand expliciet verantwoordelijk is voor het snel doorvoeren van beveiligingsreleases.
- Scan op sporen van misbruik. Controleer op onbekende bestanden in de uploads-map, onverwachte beheeraccounts, en ongebruikelijke uitgaande verzoeken vanaf de server, zeker als de update pas na enkele dagen is doorgevoerd.
- Zorg voor een actuele, geteste back-up. Een back-up van vóór een mogelijke inbraak is de enige betrouwbare manier om een gecompromitteerde site volledig schoon te herstellen. Zie ook onze aanpak voor back-up en continuïteit.
- Beperk wat publiek toegankelijk is. Blokkeer, waar mogelijk, ongeauthenticeerde toegang tot REST API-routes die niet functioneel nodig zijn voor bezoekers, via een maatwerk beveiligingsplugin of serverconfiguratie.
Deze stappen klinken voor de hand liggend, maar vragen in de praktijk om structureel eigenaarschap. Precies dat eigenaarschap is waar veel MKB-bedrijven op vastlopen: er is geen vaste persoon die WordPress-beveiligingsreleases volgt, laat staan binnen enkele uren beoordeelt en doorvoert.
Waarom SitesMonkey hier het verschil maakt
Dit is precies de reden waarom we SitesMonkey hebben ontwikkeld: een platform dat WordPress-installaties (en Laravel-applicaties) centraal beheert, in plaats van te vertrouwen op de geforceerde achtergrondupdates van WordPress.org zelf. Waar een geforceerde auto-update reactief is en afhankelijk van de configuratie van elke individuele site, werkt SitesMonkey proactief: we volgen beveiligingsreleases van WordPress-kern en veelgebruikte plugins actief, en rollen kritieke patches zoals 7.0.2 gericht en gecontroleerd uit zodra ze beschikbaar zijn, in plaats van te wachten op een achtergrondmechanisme dat kan falen.
Na iedere update controleren we automatisch of de site nog functioneert zoals verwacht, zodat een patch niet per ongeluk een andere kwetsbaarheid introduceert of een integratie breekt. Daarnaast monitort SitesMonkey continu op uptime, ongebruikelijke bestandswijzigingen en afwijkend gedrag, precies het soort signalen dat verraadt of een site al is aangevallen in het venster tussen bekendmaking en patch. Dat sluit aan bij het principe dat we eerder beschreven in ons artikel over Zero Trust voor het MKB: ga ervan uit dat een aanvaller ooit een opening vindt, en zorg dat je dat moment ziet gebeuren in plaats van het pas weken later te ontdekken.
Voor bedrijven met meerdere WordPress-sites, of een combinatie van WordPress en maatwerk-applicaties, is dit verschil des te groter. Een los WordPress-installatie die “zichzelf wel bijwerkt” is precies het scenario waarin een kritiek lek als wp2shell dagenlang onopgemerkt open kan staan.
Hoe kan MonkeySoft hierbij helpen?
MonkeySoft beheert WordPress-websites voor MKB-bedrijven via het SitesMonkey-platform, inclusief updates, back-ups, security-monitoring en performance-optimalisatie. Bij een kritiek lek zoals wp2shell controleren we direct of jouw site is geraakt, voeren we de patch gericht door, en checken we op sporen van eerder misbruik. Voor bedrijven die hun WordPress-site willen laten koppelen aan andere systemen, kijken we ook naar de beveiliging van die koppelingen, zodat een kwetsbaarheid in één schakel niet de rest van de omgeving raakt.
Neem contact op met MonkeySoft voor een gratis check of jouw WordPress-site daadwerkelijk op de laatste, veilige versie draait.
Veelgestelde vragen
Wat is wp2shell precies?
Wp2shell is de naam die aan een keten van twee kwetsbaarheden in WordPress-kern is gegeven: een SQL-injectie (CVE-2026-60137) en een REST API batch-route verwarring die daarmee gecombineerd tot remote code execution leidt (CVE-2026-63030). Een aanvaller heeft geen inloggegevens nodig om code op een kwetsbare site uit te voeren.
Welke WordPress-versies zijn kwetsbaar?
WordPress 6.9.0 tot en met 6.9.4 en 7.0.0 tot en met 7.0.1 zijn kwetsbaar voor de volledige RCE-keten. WordPress 6.8 is kwetsbaar voor de SQL-injectie op zichzelf en is gepatcht in 6.8.6. Versies ouder dan 6.8 zijn niet geraakt.
Is mijn website automatisch bijgewerkt?
WordPress.org heeft geforceerde auto-updates ingeschakeld voor kwetsbare installaties vanwege de ernst van het lek. Sites waarop automatische updates zijn uitgeschakeld, bijvoorbeeld via een beheerplugin of hostingconfiguratie, zijn niet automatisch bijgewerkt en blijven kwetsbaar totdat er handmatig wordt bijgewerkt.
Waarom is monitoring net zo belangrijk als patchen?
Een patch verhelpt de kwetsbaarheid, maar zegt niets over wat er is gebeurd in de dagen tussen het uitkomen van het lek en het daadwerkelijk bijwerken van de site. Monitoring maakt zichtbaar of een site al is aangevallen, of de update daadwerkelijk is doorgekomen, en of er ongebruikelijke bestanden of processen op de server zijn verschenen.
Wat doet SitesMonkey concreet bij een lek zoals dit?
SitesMonkey houdt WordPress-kern, plugins en thema’s continu in de gaten, rolt updates gecontroleerd uit, controleert na iedere update of de site nog correct werkt, en monitort de omgeving op verdachte bestanden, processen en uptime. Bij een kritiek lek zoals wp2shell wordt er direct en gericht gepatcht in plaats van te wachten op een automatische achtergrondupdate.
Bronnen: WordPress.org, 7.0.2 Release | Aikido Security, Unauthenticated RCE in WordPress (wp2shell)