Wat gebeurt er als je WordPress niet onderhoudt — een tijdlijn

Op 13 februari 2024 bracht Bricks Builder een patch uit voor een kritiek beveiligingslek (CVE-2024-25600). Op 14 februari stond actieve exploitatie al in de logs van getroffen sites. Eén dag tussen patch en aanval. WordPress-onderhoud betekent het bijhouden van vier lagen: WordPress core, plugins, themes, en security-monitoring met backups. Doe je dat niet structureel, dan word je vroeg of laat het laaghangende fruit voor scanners die het hele web aflopen op verouderde versies. En ja — je hebt vast ook weleens een update gehad die iets brak. Dat is een terechte zorg, en die behandel ik verderop. Eerst de feiten op tafel.

Wat WordPress-onderhoud precies inhoudt

Vier lagen, kort samengevat. Eén: WordPress core, het CMS zelf. Twee: plugins, de uitbreidingen die functionaliteit toevoegen. Drie: themes, het visuele template. Vier: security-monitoring met backups, zodat je weet wat er gebeurt en kunt terugdraaien als het misgaat.

Van die vier is de plugin-laag het grootste aanvalsoppervlak. Patchstack registreerde in 2025 in totaal 11.334 nieuwe WordPress-kwetsbaarheden, waarvan 91% in plugins zat en 9% in themes. WordPress core had er zes. Zes. Het probleem ligt dus niet bij WordPress zelf — het ligt bij de optelsom van plugins die je installeert en daarna vergeet.

Nog een ongemakkelijk getal: 46% van de in 2025 gepubliceerde kwetsbaarheden had geen patch op het moment van publieke disclosure. Wachten op een update is in bijna de helft van de gevallen dus geen optie — er is op dat moment niets om naar te updaten. Monitoring en virtual patching worden dan de enige verdediging.

De tijdlijn: van CVE-publicatie tot gehackte site

1. Uur 0 — De CVE verschijnt publiek. De kwetsbaarheid wordt gepubliceerd in databases als NVD en Patchstack. Beveiligingsonderzoekers, plugin-developers en kwaadwillende actoren lezen op datzelfde moment hetzelfde overzicht. De race begint.
2. Uur 0–5 — Bots scannen het web. Geautomatiseerde tools fingerprinten miljoenen WordPress-sites op de versie van de kwetsbare plugin. De gewogen mediane tijd tot eerste exploitatie was in 2025 vijf uur — aanvallers scannen en exploiteren binnen dezelfde werkdag dat een kwetsbaarheid bekend wordt. Wordfence blokkeerde in 2024 gemiddeld 215 miljoen exploitpogingen per dag op beschermde sites. Dat is het volume waar je tegen aan zit als je site onbeschermd online staat.
3. Dag 1 — Eerste succesvolle exploitaties. Geen theorie. Bricks Builder kreeg op 13 februari 2024 een patch voor CVE-2024-25600 (CVSS 9.8, remote code execution); op 14 februari rapporteerde Wordfence actieve exploitatie. Sites die niet binnen 24 uur updateten, draaiden risico. En 43% van alle kwetsbaarheden vereist geen authenticatie — een aanvaller hoeft geen account te hebben om binnen te komen.
4. Dag 2–7 — Backdoor of slapende infectie. Een succesvolle exploit eindigt zelden in een defacement met “HACKED BY” in rode letters. Veel vaker plaatst de aanvaller een backdoor en wacht. Je site blijft gewoon werken. In de tussentijd kan hij worden ingezet als spam-relay, phishing-host of springplank naar andere sites. Eigenaren merken het soms maanden niet.
5. Maand 1–3 — SEO-vergiftiging en prestatieverval. Geïnjecteerde links naar dubieuze farma- of gokpagina's beschadigen je domeinautoriteit. Google kan je site markeren als misleidend, waarna organisch verkeer instort. Wil je weten of jouw domein al onzichtbare schade heeft opgelopen? Een SEO + GEO audit legt dat soort patronen bloot.
6. Maand 6+ — De plugin verdwijnt. Plugin-onderhoud is voor veel auteurs een hobby die uitdooft. In 2024 werden 1.614 plugins uit de WordPress.org-repository verwijderd wegens onopgeloste beveiligingsproblemen. Heb jij zo’n plugin actief en wordt hij verwijderd, dan komt er nooit meer een patch. De kwetsbaarheid wordt permanent — tenzij je migreert naar een alternatief of de functionaliteit elders onderbrengt.

Dat is de tijdlijn. Niet hypothetisch. Elke fase heeft een naam, een datum, een telbare uitkomst.

De update-paradox — en hoe je hem oplost

Nu het ongemakkelijke deel. Updaten is óók een risico. Op 16 februari 2024 documenteerde WooCommerce zelf dat versie 8.6 checkout-pagina’s brak bij sites die upgraden vanaf 8.5.2. Foutmelding: “Cannot read properties of undefined” — bovenop de Checkout block, midden in de productie-webshop. Een dag geen verkoop kost je meer dan een maand onderhoud.

Dit gebeurt regelmatig. Een plugin-update breekt compatibiliteit met een andere plugin. Een theme-update overschrijft een aanpassing. Een PHP-versiebump in WooCommerce werkt niet met je verouderde payment gateway. Niet-technische eigenaren die ooit zo’n kapotte upgrade hebben meegemaakt, vermijden updates daarna jarenlang. Begrijpelijk — maar niet houdbaar, gezien de tijdlijn hierboven.

De oplossing is geen mysterie: staging. Ik beheer geen enkele site zonder staging-omgeving. Updates landen daar eerst, ik klik door alle kritieke flows (checkout, formulieren, login), en pas als die werken gaat het naar productie. Breekt er iets op staging? Dan los ik het daar op of meld ik het bij de plugin-auteur, zonder dat je bezoekers er iets van merken. Dat is wat WordPress-onderhoud bij mij in de praktijk betekent — geen “Update All”-knop op vrijdagmiddag.

Wat herstel kost als het misgaat

Concrete prijzen helpen meer dan abstracte dreiging. Voor de Nederlandse markt: MissHack rekent €139 excl. BTW voor hack-verwijdering per WordPress-site, of €198 excl. BTW voor het gecombineerde pakket met basisbeveiliging. Internationaal: Sucuri rekent circa $499,99 per jaar voor hun cleanup-abonnement, met losse incident-cleanups die oplopen tot $500–$800.

Reken even mee. Onderhoud bij mij: €45 per maand, oftewel €540 per jaar — inclusief staging-tests, updates, backups en monitoring. Eén hackopruiming bij een NL-aanbieder: €139–€198 excl. BTW. Klinkt dat goedkoper? Tot je de uren downtime, eventuele SEO-schade, klantcommunicatie en het terugzetten van een schone backup meerekent. En als de aanvaller een slapende backdoor heeft achtergelaten die je over drie maanden pas merkt, ben je twee keer aan het opruimen.

Dan nog de juridische laag. AVG-artikel 32 verplicht je om “passende technische en organisatorische maatregelen” te nemen voor de bescherming van persoonsgegevens. Een verouderde WordPress-installatie waarvan al maanden bekend is dat hij kwetsbaar is, valt lastig te verdedigen als “passend”. Geen Nederlandse boetebesluit-jurisprudentie vond ik specifiek voor verwaarloosd CMS-onderhoud, dus claim ik geen automatische boete — maar het is een afweging die je als verwerkingsverantwoordelijke moet maken.

Wrap-up

Je site hoeft geen onneembare vesting te zijn. Hij hoeft alleen niet het laaghangende fruit te zijn dat een geautomatiseerde scanner als eerste vindt. Vijf uur tussen CVE-publicatie en eerste exploitatie geeft je geen tijd om er op een rustige zaterdag eens naar te kijken — die race verlies je. Updates testen op staging, plugins die uit de repository verdwijnen op tijd vervangen, en een backup binnen handbereik houden voor als het toch misgaat: dat is het werk. Ik doe het maandelijks voor een handvol WordPress-sites, zodat eigenaren zich met hun bedrijf kunnen bezighouden in plaats van met patch-notes.