Je website doet het nog prima. Dat zegt niets over hoe veilig ze is.

De meeste KMO's hebben een website die er gewoon staat. Ooit gebouwd door een bureau, sindsdien doet ze braaf haar werk, en niemand kijkt er nog naar om. Meestal is dat geen probleem. Sinds midden juli even wel.

Wat speelt er

Op 17 juli 2026 bracht WordPress drie noodversies uit: 7.0.2, 6.9.5 en 6.8.6. De reden: twee fouten in de software die onderzoekers samen "wp2shell" doopten (officieel CVE-2026-63030 en CVE-2026-60137). Zo'n fout waar een aanvaller misbruik van kan maken, heet een kwetsbaarheid.

Het venijn zit in de plek. Deze twee fouten zitten niet in een plugin — een extra module die je bovenop WordPress installeert, voor een contactformulier bijvoorbeeld — maar in WordPress zelf. Een kale installatie zonder één plugin is dus even lek als een site vol extra's.

Wat een aanvaller ermee kan: één verzoek naar de website sturen. Geen account nodig, niemand hoeft ergens op te klikken. Vanaf dat moment draait er vreemde code op de server achter die site. In de praktijk betekent dat: teksten aanpassen, bezoekers doorsturen naar valse pagina's, de databank uitlezen, stiekem een extra beheerder aanmaken, of een achterdeurtje openzetten voor later.

Theoretisch? Nee. Op 21 juli zette de Amerikaanse cyberveiligheidsdienst CISA beide kwetsbaarheden op haar lijst van lekken waarvan misbruik bewezen is. Het Centrum voor Cybersecurity België (CCB), de nationale overheidsdienst voor cyberveiligheid, vroeg om met de hoogste prioriteit te updaten. Kant-en-klare aanvalscode circuleert intussen openbaar.

Even scherpstellen op de versies. 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 aanval. 6.8.0 tot en met 6.8.5 enkel voor het kleinere van de twee lekken. Alles ouder dan 6.8 ontsnapt aan déze twee fouten — maar wie daar nog op draait, mist jaren aan andere updates. Geen reden tot gejuich dus.

Waarom dit KMO's raakt

WordPress draait op ongeveer 41,5% van alle websites ter wereld (W3Techs, juli 2026). De kans is dus groot dat ook de site van een Vlaamse KMO erop draait. En aanvallers kiezen hun slachtoffers niet uit: ze laten een script los op het hele internet en pikken eruit wat kwetsbaar is. Klein zijn helpt niet. Niemand kijkt eerst hoe groot je bent.

WordPress heeft de update geforceerd via het automatische updatesysteem. Mooi — maar dat mechanisme haalt niet elke site. Het slaat sites over waar automatische updates uitstaan, sites met strenge bestandsrechten, sites die via een ontwikkelomgeving beheerd worden, en sites met heel weinig bezoekers. Met andere woorden: precies de sites waar geen IT'er dagelijks naar kijkt.

Daar komt nog iets bij. De meeste bedrijven hebben meer online staan dan ze denken. De hoofdsite, ja. Maar ook die campagnesite van drie jaar geleden. De webshop op een subdomein. De testomgeving die het bureau destijds vergeten is offline te halen. Draait allemaal op dezelfde software. En voelt niemand zich verantwoordelijk voor.

Dat dit kleine ondernemingen effectief treft, bleek in juni nog: een internationale politieactie legde een netwerk plat dat gehackte WordPress-sites gebruikte om malware te verspreiden. In Nederland alleen al werden bijna 15.000 besmette sites opgeschoond. Onder de slachtoffers: restaurants, garages en andere zaken zonder eigen IT-afdeling.

En een gekaapte website is zelden "alleen maar de website". Bezoekers die op een frauduleuze pagina belanden. Een waarschuwing van Google naast je bedrijfsnaam in de zoekresultaten. Contactgegevens uit formulieren die op straat liggen — dat laatste is een datalek onder de GDPR, met meldingsplicht erbij.

Wat je er concreet aan doet

Kijk vandaag nog welke versie er draait. In het WordPress-dashboard staat ze op de startpagina onder "Op een oogopslag", of via Dashboard → Updates. Er moet 7.0.2, 6.9.5, 6.8.6 of hoger staan. Ga er niet van uit dat de automatische update gelukt is. Die controle kost dertig seconden.

Doe dat voor élke site, niet alleen de hoofdsite. Zet op papier wat er allemaal online staat: hoofdsite, webshop, campagnesites, subdomeinen, testomgevingen. Wat niet op dat lijstje staat, wordt ook niet bijgewerkt.

Vraag de webbouwer of hostingpartner om bevestiging op papier. Niet alleen dát de update erop staat, maar ook dat er gekeken is naar sporen van inbraak. Laat controleren op onbekende beheerdersaccounts, plugins die niemand geïnstalleerd heeft, en bestanden die er niet horen.

Een update sluit de deur. Ze zet niemand buiten die er al binnen was.

Lukt updaten echt niet meteen? Dan kan een firewall vóór de website het kwetsbare onderdeel tijdelijk afschermen. Dat is een noodverband voor een paar dagen, geen vervanging van de update.

Leg het daarna structureel vast. Eén naam per website. Een afspraak over hoe snel kritieke updates geplaatst worden. En tweestapsverificatie op elk beheerdersaccount: naast een wachtwoord ook een code op de gsm. Wie dit één keer goed regelt, hoeft bij het volgende lek niet te improviseren.

Hoe NetGuard helpt

Het lastigste aan zo'n lek is zelden de update zelf. Het is de vraag die eraan voorafgaat: waar staat er eigenlijk nog overal iets van dit bedrijf online? Daar dient External Attack Surface Management (EASM) voor — in kaart brengen welke websites, subdomeinen, inlogpagina's en servers van een organisatie vanaf het internet bereikbaar zijn, inclusief de vergeten exemplaren. Je weet dan wat er gecontroleerd moet worden, in plaats van te hopen dat er niets over het hoofd gezien wordt. Wie daarna wil weten of een kwetsbaarheid in de eigen omgeving ook echt uitbuitbaar is, komt uit bij een pentest: een gecontroleerde aanval door specialisten.

Benieuwd wat er vandaag van jouw bedrijf zichtbaar is vanaf het internet? Neem contact op met NetGuard voor een eerste analyse.

Meer info

• CCB — Warning: Critical, Actively Exploited Remote Code Execution in WordPress Core (CVE-2026-63030, CVE-2026-60137)

• Rapid7 — CVE-2026-63030: wp2shell, a Critical Remote Code Execution Vulnerability in WordPress Core

• SecurityWeek — WP2Shell WordPress Vulnerabilities Exploited in the Wild