Op vrijdag 17 juli kwam de patch voor wp2shell uit. Binnen een paar uur zagen securitybedrijven de eerste aanvallen in hun honeypots, en dat weekend hielpen ze al bij echte incidenten. Op dinsdag 21 juli zette CISA het lek op de lijst van kwetsbaarheden die aantoonbaar misbruikt worden.
Bijna iedereen schreef toen hetzelfde artikel: update nu. Terecht. Maar er zit een vraag achter die veel minder vaak beantwoord is, en die voor jou belangrijker is als je pas in het weekend of de week erna hebt geüpdatet.
Want een update dicht het gat. Een update haalt niet weg wat er eventueel al binnen is gekomen.
Als een aanvaller in dat venster een beheerdersaccount heeft aangemaakt of een plugin met een webshell heeft geüpload, dan werkt dat gewoon door nadat je naar 6.9.5 of 7.0.2 bent gegaan. De voordeur zit dicht, maar het raam aan de achterkant staat nog open. Dit artikel loopt langs de sporen die je zelf kunt controleren.
Eerst: val jij überhaupt in het risicovenster?
Niet iedere WordPress-site liep gevaar. Je hoeft alleen verder te lezen als beide dingen kloppen.
Je draaide een kwetsbare versie. De volledige aanvalsketen, dus overname zonder in te loggen, werkte op WordPress 6.9.0 tot en met 6.9.4 en op 7.0.0 tot en met 7.0.1. Ook 7.1 Beta was kwetsbaar. Gepatcht in 6.9.5, 7.0.2 en 7.1 Beta 2.
Zit je nog op de 6.8-branch? Dan lig je er niet automatisch uit. Versies 6.8.0 tot en met 6.8.5 bevatten wel de SQL-injectie (CVE-2026-60137), maar niet het lek in de batch-route waarmee die zonder login te bereiken was. Het risico is daar dus veel kleiner, maar 6.8.6 dicht het alsnog. Draai je nog iets ouders dan 6.8, dan heb je een groter probleem dan alleen wp2shell.
Je site was tussen 17 juli en jouw update publiek bereikbaar. Hoe langer dat venster, hoe serieuzer je moet kijken. Een site die vrijdagavond automatisch is bijgewerkt, loopt weinig risico. Een site die pas eind juli is bijgewerkt, zat ruim een week in een periode waarin er actief en geautomatiseerd gescand werd.
Weet je niet meer wanneer je hebt geüpdatet? Kijk in je WordPress-beheerscherm bij Updates, of vraag het je hostingpartij. Wij leggen dat vast, dus bij ons is dat één vraag aan support.
Wat wp2shell technisch precies doet, hebben we uitgelegd in ons artikel wp2shell: kritiek WordPress-lek, dit moet je nu doen. Kort samengevat zijn het twee lekken die elkaar versterken. In WordPress zat een SQL-injectie (CVE-2026-60137) die normaal alleen bereikbaar was als je al ingelogd was. Een fout in de REST API batch-verwerking (CVE-2026-63030) haalde die drempel weg, waardoor een willekeurige bezoeker erbij kon. Vanaf daar was het een kwestie van een beheerdersaccount aanmaken, inloggen en een eigen plugin uploaden.
Die laatste stap is precies wat sporen achterlaat.
Check 1: onbekende beheerders in je gebruikerslijst
Dit is de snelste controle en meteen de belangrijkste. Ga naar Gebruikers in je WordPress-beheerscherm en filter op de rol Beheerder.
Staat daar iemand die je niet kunt plaatsen? Dan stop je met lezen en bel je meteen hulp in.
De aanvalstools die publiek circuleerden gebruikten herkenbare patronen: gebruikersnamen die beginnen met wp2_ of w2s_ gevolgd door willekeurige tekens, en e-mailadressen op domeinen als wp2shell.invalid en wp2shell.shellcode.lol. Kijk ook naar de kolom met registratiedatum. Een beheerder die is aangemaakt op een dag waarop jij niemand hebt toegevoegd, is verdacht, ongeacht hoe de naam eruitziet.
Belangrijk: dit zijn de patronen van kant-en-klare tools. Een aanvaller die zijn best doet, kiest een naam die lijkt op die van jou of je webbouwer. Dus let vooral op het aantal beheerders en de datums, niet alleen op rare namen.
Controleer meteen ook de applicatiewachtwoorden. Die vind je per gebruiker onderaan het profiel. Een applicatiewachtwoord blijft werken als je het gewone wachtwoord wijzigt, en is daarmee een populaire manier om binnen te blijven. Alles wat je niet zelf hebt aangemaakt, verwijder je.
Check 2: PHP-bestanden die zijn gewijzigd sinds 16 juli
Een webshell is uiteindelijk gewoon een PHP-bestand dat er eerder niet was. Als je bij je hosting toegang hebt tot SSH, geeft dit commando je een lijst met alle PHP-bestanden die sinds middernacht op 16 juli zijn aangemaakt of gewijzigd. Dat is bewust een dag ruimer dan de patchdatum, zodat je een marge hebt:
find /pad/naar/je/website -name "*.php" -newermt "2026-07-16" -printf "%TY-%Tm-%Td %TH:%TM %p\n"Je krijgt bijna altijd een aantal treffers, en de meeste zijn onschuldig: de WordPress-update zelf raakt honderden bestanden aan. Waar je op let, zijn bestanden buiten die update. Denk aan losse PHP-bestanden in wp-content/uploads, waar helemaal geen PHP hoort te staan. Of een enkel bestand in je thememap met een tijdstempel dat afwijkt van de rest.
Geen SSH? Dan kun je in je bestandsbeheerder sorteren op wijzigingsdatum. Dat werkt trager maar levert hetzelfde inzicht op.
Check 3: de pluginmap
Kijk in wp-content/plugins naar mappen die je niet kent. De publieke exploitcode maakte mappen aan met een naam in de vorm wp2shell_ gevolgd door een reeks tekens. Ook zag men schrijftests met namen als temp-write-test- ergens onder wp-content, en losse zip-bestanden in de uploadmap.
Let op één ding dat incident responders expliciet benadrukken: het ontbreken van zo’n map bewijst niet dat je schoon bent. Aanvallers ruimen op, of hernoemen de map. Deze check kan een hack aantonen, maar nooit uitsluiten.
Vergelijk daarom liever je pluginlijst in het beheerscherm met de mappen op schijf. Een map zonder bijbehorende plugin in de lijst is precies het soort afwijking dat je zoekt. Hetzelfde geldt andersom: een plugin die actief staat maar die jij nooit hebt geïnstalleerd.
Check 4: je serverlogs
Als je toegang hebt tot je access logs, zoek dan op deze twee paden:
/wp-json/batch/v1/?rest_route=/batch/v1
Dat zijn de endpoints waar de aanval binnenkwam. Wat je zoekt zijn POST-verzoeken naar die paden, vaak beantwoord met statuscode 207. Verzoeken die daarna naar /wp-admin/update.php?action=upload-plugin gaan, zijn het duidelijkste signaal dat de aanval geslaagd is: dat is het moment waarop de kwaadaardige plugin geüpload werd.
De vroege, geautomatiseerde aanvallen gebruikten user agents die zichzelf niet eens verstopten, zoals wp2shell en cve-2026-63030/1.0. Handig, maar reken er niet op.
Twee praktische kanttekeningen. De inhoud van een POST staat meestal niet in je logs, dus je ziet dát er een verzoek was en niet wat erin zat. En veel hostingpakketten bewaren logs maar een paar weken, dus als je dit half augustus doet, kan 17 juli al buiten je bewaartermijn vallen. Vraag het na bij je hostingpartij voordat je concludeert dat er niets te zien is.
Check 5: wat je bezoekers zien
Een gehackte site gedraagt zich vaak normaal als je ingelogd bent, en anders voor iedereen anders. Doe deze drie dingen:
Open je site in een privévenster, zonder ingelogd te zijn, en klik een paar pagina’s door. Doe hetzelfde op je telefoon via mobiele data. Bezoekers van gecompromitteerde sites kregen nepinlogschermen van Microsoft 365 of hun bank te zien, doorstuurpagina’s naar nepprijzen en betaalverzoeken, of downloads met malware.
Zoek daarna in Google op site:jouwdomein.nl en kijk of er pagina’s tussen staan die je niet herkent. Spamcontent die onder jouw domein wordt geplaatst is een klassieke vervolgstap, en die pagina’s staan vaak verborgen voor gewone bezoekers.
Kijk tot slot in Google Search Console bij Beveiligingsproblemen. Als Google iets heeft gevonden, staat het daar. Dit is ook de plek waar de echte schade zichtbaar wordt: een waarschuwing in de zoekresultaten kost je vindbaarheid en vertrouwen, en dat blijft nog een tijd hangen nadat het probleem is opgelost.
Je vindt iets. Wat doe je dan?
Niet meteen opruimen. Dat is de reflex, en het is de verkeerde volgorde.
Maak eerst een kopie van je bestanden en database zoals ze nu zijn, en raak die kopie niet meer aan. Zonder dat bewijsmateriaal kun je later niet vaststellen wanneer het is begonnen en wat er precies is gebeurd. En dat heb je nodig als er persoonsgegevens in het spel zijn.
Daarna, in deze volgorde: haal de site offline of achter onderhoudsmodus, verwijder de onbekende beheerders en applicatiewachtwoorden, reset alle wachtwoorden en vervang API-sleutels, en zet een schone backup terug van vóór 17 juli. Werk die backup meteen bij naar een gepatchte versie voordat je hem weer online zet, anders sta je opnieuw open.
Twee artikelen die hier dieper op ingaan: malware en backdoors opsporen na een hack en veilig een backup terugzetten na een hack.
En dan het stuk dat mensen vergeten: als er klant- of ledengegevens op die site stonden, is een hack mogelijk een datalek. Dan gaat er een klok van 72 uur lopen richting de Autoriteit Persoonsgegevens. Hoe dat werkt staat in datalek melden voor het MKB. Met de Cyberbeveiligingswet die op 15 augustus ingaat komt daar voor een deel van de bedrijven nog een meldplicht bovenop.
Hoe je de volgende keer sneller bent
wp2shell is niet het laatste lek in WordPress core. Wat het pijnlijk maakte, was niet de kwetsbaarheid zelf, maar de snelheid. De eerste aanvalspogingen kwamen dezelfde avond nog binnen. Toen dat weekend de publieke exploitcode verscheen, liep het op naar tienduizenden pogingen. Handmatig updaten op maandagochtend is bij dat tempo structureel te laat.
Drie dingen die het verschil maken. Continue malwarescanning op serverniveau, die verdachte PHP-bestanden opmerkt zonder dat jij ergens hoeft in te loggen. Backups met genoeg historie, want een backup van gisteren is waardeloos als de hack drie weken oud is. En iemand die dit soort meldingen daadwerkelijk volgt op een vrijdagavond.
Bij onze managed WordPress hosting scant Imunify360 continu en zitten er dagelijkse backups op met 7 tot 60 dagen historie, afhankelijk van je pakket. Wil je dat iemand het volledige onderhoud overneemt inclusief het testen van updates op staging, kijk dan naar WordPress onderhoud uitbesteden.
Veelgestelde vragen
Ik heb pas eind juli geüpdatet. Ben ik gehackt?
Niet automatisch. De aanvallen waren geautomatiseerd en op grote schaal, maar dat betekent niet dat elke kwetsbare site is geraakt. Loop de checks hierboven langs. Vind je niets bij de gebruikerslijst, de bestandsdatums en de pluginmap, dan is de kans klein.
Mijn beveiligingsplugin meldt niets. Is dat genoeg?
Nee. Een plugin draait binnen WordPress zelf, en dat is precies de omgeving die de aanvaller controleert. Scanning op serverniveau en handmatige controle van je gebruikerslijst zijn onafhankelijk van wat er in WordPress gebeurt.
Kan ik gewoon een backup terugzetten en klaar zijn?
Alleen als die backup van vóór 17 juli is, en je hem bijwerkt naar een gepatchte versie voordat je hem online zet. Zet je een backup terug van na de hack, dan zet je de backdoor er netjes weer bij.
Ik heb het lek nog steeds niet gedicht.
Doe dat vandaag. Werk bij naar minimaal 6.9.5, 7.0.2 of 6.8.6, en ga er daarna van uit dat je site mogelijk gecompromitteerd is. Het venster staat inmiddels ruim twee weken open.
Ik weet niet hoe ik dit moet controleren.
Dat hoeft ook niet zelf. Neem contact op, dan kijken we mee. Bij sites die bij ons draaien kunnen we de logs en bestandswijzigingen direct nakijken.