Op vrijdag 17 juli 2026 bracht WordPress een noodupdate uit. Versie 7.0.2 dicht twee kwetsbaarheden in de kern van WordPress zelf, en die combinatie is ernstig genoeg dat het WordPress-team iets deed wat ze bijna nooit doen: de update geforceerd doorzetten naar alle getroffen websites.
Als jij een WordPress website hebt, is de kans groot dat je site inmiddels vanzelf is bijgewerkt. Maar "grote kans" is geen zekerheid, en dat verschil is precies waarom deze blog bestaat. Hieronder lees je wat er aan de hand is, waarom het anders is dan de zoveelste update-melding, en hoe je in vijf minuten controleert of jouw site in orde is.
Wat is er precies gebeurd?
De kwetsbaarheid heeft van de ontdekkers de bijnaam wp2shell gekregen. Het gaat om twee losse problemen die aan elkaar geknoopt kunnen worden:
- CVE-2026-63030, een fout in de manier waarop de REST API van WordPress bepaalde verzoeken afhandelt. Dit probleem is ontstaan in WordPress 6.9.
- CVE-2026-60137, een SQL-injectie in de
author__not_inparameter van WP_Query. Deze raakt WordPress 6.8 en hoger.
Los van elkaar zijn ze al vervelend. Gecombineerd leveren ze een aanvaller remote code execution op, oftewel de mogelijkheid om eigen code te draaien op de server van je website.
Het venijn zit in de voorwaarden, of eigenlijk het gebrek daaraan. Er is geen inlogaccount nodig. Er hoeft geen specifieke plug-in geïnstalleerd te zijn. Geen bijzondere configuratie. Een standaard WordPress-installatie zonder enige toevoeging was kwetsbaar via één anoniem verzoek vanaf het internet.
Waarom dit geval anders is
Ik ga hier normaal niet over schrijven, want er is elke week wel iets. Het overgrote deel van de WordPress-lekken die voorbijkomen zit in plug-ins, niet in WordPress zelf. In het meest recente Patchstack-rapport zat 91 procent van de nieuw gemelde kwetsbaarheden in plug-ins.
De kern van WordPress heeft juist een sterke reputatie. Die code wordt zwaar gereviewd en snel gepatcht, en serieuze fouten daarin zijn zeldzaam. Dit is er een.
Twee dingen maken het extra urgent. WordPress heeft geforceerde automatische updates aangezet, iets wat alleen gebeurt als het team inschat dat wachten op handmatige actie te riskant is. En er zijn inmiddels publieke proof-of-concept exploits verschenen, waarna meerdere securitybedrijven daadwerkelijk misbruik in de praktijk hebben gezien.
Welke versies zijn getroffen?
| Jouw versie | Status | Wat je nodig hebt |
|---|---|---|
| 7.0.0 tot en met 7.0.1 | Kwetsbaar voor de volledige aanvalsketen | Update naar 7.0.2 |
| 6.9.0 tot en met 6.9.4 | Kwetsbaar voor de volledige aanvalsketen | Update minimaal naar 6.9.5 |
| 6.8.x | Alleen kwetsbaar voor de SQL-injectie | Update minimaal naar 6.8.6 |
| Ouder dan 6.8 | Buiten deze meldingen, maar sowieso achterstallig | Plan een upgrade |
Dit is een detail dat in veel berichten misgaat: 7.0.2 is niet de enige juiste uitkomst. Zat je site op de 6.9-lijn, dan is 6.9.5 net zo goed gepatcht.
Actieplan: controleer je site in vijf minuten
Stap 1. Kijk welke versie je draait. Log in op je WordPress dashboard en ga naar Dashboard, dan Updates. Bovenaan staat welke versie actief is. Je kunt ook rechtsonder in het dashboard kijken, daar staat het versienummer standaard vermeld.
Stap 2. Vergelijk met de tabel hierboven. Zit je op 7.0.2, 6.9.5 of 6.8.6 of hoger? Dan is de patch binnen. Zie je een lager nummer of staat er een update klaar, ga door naar stap 3.
Stap 3. Maak eerst een back-up. Bestanden én database. De bestanden bevatten je thema, plug-ins, uploads en configuratie. De database bevat je pagina's, gebruikers, instellingen en eventuele bestellingen. Veel hostingpartijen maken dagelijks een back-up, maar controleer dat je er ook daadwerkelijk bij kunt.
Stap 4. Voer de update uit. Klik op 'Nu bijwerken'. Het is een minor release, geen grote platformmigratie, dus de kans op problemen is klein. Heb je een webshop of een site met maatwerk, test dan eerst op een staging-omgeving.
Stap 5. Controleer of het gelukt is. Ververs de updatepagina en kijk of het versienummer klopt. Loop daarna even door je site: homepage, contactformulier, inlogpagina, en bij een webshop het afrekenproces.
Stap 6. Kijk of je site niet al geraakt is. Het versienummer alleen is niet genoeg. Was je site vóór de update aangevallen, dan kan een aanvaller met admin-toegang een keurig, up-to-date versienummer laten zien terwijl hij een achterdeurtje heeft achtergelaten. Loop voor de zekerheid ook deze checks langs:
- Beheerdersaccounts. Ga naar Gebruikers, filter op de rol Beheerder en kijk of je iedereen herkent. Let op accounts die je niet zelf hebt aangemaakt of rare gebruikersnamen.
- Plug-inlijst. Staan er plug-ins tussen die jij niet hebt geïnstalleerd, of die actief zijn maar niet in de officiële map te vinden zijn? Aanvallers verstoppen hun toegang graag als een onopvallende plug-in.
- Gewijzigde bestanden. Via je hosting of FTP zie je wanneer bestanden voor het laatst zijn aangepast. Bestanden die rond het aanvalsvenster wijzigden terwijl jij niets deed, of losse PHP-bestanden in je uploads-map, zijn een rode vlag.
- Security-scan. Een plug-in als Wordfence of Sucuri Security doet een malwarescan en vergelijkt je core-bestanden met de originelen. Dat vangt aangepaste kernbestanden die je met het blote oog mist.
Als je ergens vastloopt
Sommige hostingpartijen hebben de patch al voor je toegepast op platformniveau, waaronder een aantal managed WordPress-omgevingen. Twijfel je of dat bij jou het geval is, dan is één mailtje naar je host sneller dan zelf uitzoeken.
Wat je vooral niet moet doen is dit doorschuiven naar het volgende onderhoudsmoment. Bij een lek waar publieke exploitcode voor rondgaat, is de tijd tussen "dat doe ik volgende week" en "mijn site is overgenomen" korter dan je zou willen.
Wat dit zegt over websiteonderhoud
Deze update is een uitzondering, maar het onderliggende punt niet. Een website is geen ding dat je één keer oplevert en daarna vergeet. Zolang je site online staat, verandert de omgeving eromheen continu: WordPress zelf, je plug-ins, je PHP-versie, en de mensen die geautomatiseerd het internet afstruinen op zoek naar sites die achterlopen.
Automatische updates worden vaak genoemd als de oplossing, maar dat is precies de valkuil. Een update die vanzelf binnenkomt kan net zo goed je contactformulier slopen, je opmaak verschuiven of een conflict met een plug-in veroorzaken. Zonder dat er iemand kijkt, ontdek je dat pas als een klant je belt dat hij geen offerte kan aanvragen. En dat kan weken later zijn. Automatisch bijwerken zonder controle achteraf is geen onderhoud, dat is hopen dat het goed gaat.
Wat wél werkt is ritme en verantwoordelijkheid. Iemand die maandelijks of wekelijks de updates doorloopt in de juiste volgorde, controleert of de site daarna nog doet wat hij moet doen, een back-up heeft die getest is en niet alleen bestaat, en die bij een melding als deze binnen een dag weet welke van zijn sites geraakt worden. Dat laatste is het verschil dat je bij dit soort weekenden merkt: niet zelf uitzoeken of je erbij zit, maar een bericht krijgen dat het al geregeld is.
Daarom werk ik met onderhoudsabonnementen. Geen dienst die je afsluit en waar je vervolgens nooit meer iets van hoort, maar iemand die je site kent en weet waar de gevoeligheden zitten. Kom je er niet uit, of wil je gewoon dat iemand anders hier naar kijkt? Neem gerust contact op.
Bronnen
- WordPress.org, WordPress 7.0.2 Release, 17 juli 2026: https://wordpress.org/news/2026/07/wordpress-7-0-2-release/
- SecurityWeek, WP2Shell WordPress Vulnerabilities Exploited in the Wild, 20 juli 2026 https://www.securityweek.com/wp2shell-wordpress-vulnerabilities-exploited-in-the-wild/
- BleepingComputer, WordPress Core "wp2shell" RCE flaws get public exploits, patch now, 18 juli 2026 https://www.bleepingcomputer.com/news/security/wordpress-core-wp2shell-rce-flaws-get-public-exploits-patch-now/
- Rapid7, CVE-2026-63030: wp2shell, a Critical Remote Code Execution Vulnerability in WordPress Core, 18 juli 2026 https://www.rapid7.com/blog/post/etr-cve-2026-63030-wp2shell-a-critical-remote-code-execution-vulnerability-in-wordpress-core/
- VulnCheck, WP2Shell Vulnerabilities: CVE-2026-60137 and CVE-2026-63030, 18 juli 2026 https://www.vulncheck.com/blog/wp2shell
Laatst bijgewerkt op 20 juli 2026.
