WordPress-patchroutine voor het mkb: van noodpatch naar cadans

Je leest op een vrijdagavond dat er een gat in de WordPress-kern zit waarmee iemand zonder in te loggen code op je site kan draaien. Je opent wp-admin, ziet "Je site draait de nieuwste versie" en gaat opgelucht slapen. Daar stopt het onderzoek op de meeste mkb-sites. En daar gaat het mis, want gepatcht is niet hetzelfde als schoon.

Een update dicht het gat. Hij verwijdert geen beheerdersaccount dat er twee dagen eerder bij is gezet, en geen php-bestand dat in je uploads-map ligt te wachten. Toen een kritiek lek in de WordPress-kern actief werd misbruikt terwijl beheerders nog aan het bijwerken waren, lagen er twee vragen op tafel, niet een: ben ik al geraakt, en hoe zorg ik dat ik dit niet elke keer opnieuw handmatig zit uit te zoeken.

Een patchroutine is de vaste afspraak die bepaalt wat automatisch bijwerkt, wat je eerst op een testkopie probeert, wie er buiten kantooruren mag ingrijpen en waaraan je merkt dat er iets misging. Geen lijstje tips, maar een cadans met twee snelheden: een spoedbaan voor lekken die nu worden misbruikt, en een rustige baan voor al het andere.

Die tweedeling is het hele punt van deze gids. Zolang het venster tussen een kwetsbaarheidsmelding en een werkend exploit van dagen naar uren krimpt, verliest de vraag "wanneer patch ik" het van de vraag "wat loopt er zonder mij door". Hieronder staan ze allebei, in de volgorde waarin je ze echt afwerkt.

Wat je nodig hebt

Het meeste werk zit niet in dure software maar in toegang die je op het verkeerde moment niet blijkt te hebben. Zoek dit uit voordat er iets aan de hand is, want om half tien 's avonds ben je geen wachtwoord van je hostingpanel aan het terugvinden.

Reken op nul tot ongeveer 150 euro per site per jaar aan gereedschap. De grootste kostenpost is niet een licentie maar de afspraak dat iemand dit doet. Zonder naam achter die afspraak zakt elke routine binnen een kwartaal in.

Van noodpatch naar routine, in acht stappen

De eerste drie stappen zijn de brandweerstappen: ze horen bij het moment dat er nu iets speelt. De stappen vier tot en met acht zijn de routine die ervoor zorgt dat de brandweerstappen de volgende keer vrijwel leeg blijven.

1. Stel vast welke versie je draaide, en bevries het bewijs

Je begint bij de versie van vóór de update, niet bij de versie van nu. Dat getal bepaalt of je alleen data-uitlezing riskeerde of volledige code-uitvoering. Bij het wp2shell-lek zag die verdeling er zo uit:

Ook de smalle variant is geen vrijbrief: een SQL-injectie kan de wachtwoordhashes uit de wp_users-tabel lezen, dus wachtwoorden roteren hoort er sowieso bij. Het Nederlandse NCSC geeft CVE-2026-63030 de bijna maximale CVSS-score van 9,8 en adviseert de updates op korte termijn te installeren.

Maak vóór je iets aanraakt een volledige kopie: bestanden én database, en zet die apart. Een update overschrijft precies de tijdstempels waaraan je later wilt zien wanneer er iets veranderde. Dump de database vanuit die kopie, niet vanuit de live-omgeving.

2. Patch, of sluit de deur als patchen nu niet kan

Bijwerken via Dashboard, Updates, Nu bijwerken is de kortste route. Werkt dat niet, dan zet je de bestanden via SFTP neer.

Kun je niet direct updaten, bijvoorbeeld omdat een verouderde plugin de nieuwe kern niet aankan, dan is het blokkeren van /wp-json/batch/v1 en ?rest_route=/batch/v1 op je firewall de tijdelijke maatregel die de onderzoekers zelf noemen. Behandel dat als een pleister met een houdbaarheidsdatum, niet als oplossing: zo'n blokkade kan legitiem gebruik van je site raken.

Draai je bij een beheerde host, controleer dan of en wanneer die de patch uitrolde. WordPress.org zette voor deze release geforceerde updates aan via het auto-updatesysteem voor sites op de getroffen versies. Dat kanaal bestaat alleen voor sites die auto-updates niet hebben uitgezet, en dat is meteen het belangrijkste argument tegen ze uitzetten.

3. Zoek de sporen: ben je al binnen geweest?

Dit is de stap die de Nederlandse tipslijstjes overslaan. Loop vier plekken langs, in deze volgorde.

De database eerst. Kijk in wp_users en wp_usermeta naar beheerders die je niet kent. De aanvalsketen liet herkenbare resten achter: accountnamen met de prefix wp2_ of w2s_ en e-mailadressen op @wp2shell.invalid of @wp2shell.shellcode.lol. Controleer in wp_options of active_plugins, siteurl en home nog kloppen, let op vreemde _transient_-regels, op loopback-rijen in oembed_cache en op customize_changeset-records met absurd hoge parent-id's. Gaten in de reeks gebruikers-id's en verweesde usermeta wijzen op een account dat weer is opgeruimd.

Dan de bestanden. Zoek php-bestanden die zijn aangeraakt rond het moment dat het lek publiek werd:

find /pad/naar/je/webroot -name "*.php" -newermt "2026-07-16" -printf "%TY-%Tm-%Td %TH:%TM %p\n"

Let vooral op php in wp-content/uploads, op bestandsnamen die met wp2shell_ beginnen, en op wijzigingen in .htaccess, index.php, header.php, footer.php en functions.php. Draai vervolgens wp core verify-checksums, dat je kernbestanden vergelijkt met de checksums van WordPress.org en elk afwijkend bestand met naam noemt. Voor de rest van de installatie doe je hetzelfde met wp plugin verify-checksums --all, met de kanttekening dat dit alleen werkt voor plugins uit de officiële directory.

Dan de logs. Grep je access log op /wp-json/batch/v1 en /?rest_route=/batch/v1, en kijk in je php-fpm-log naar fatale fouten rond hetzelfde tijdvenster. Belangrijke nuance van het onderzoeksteam dat de responsgids schreef: een schone exploit-run laat vrijwel niets in de logs achter, dus het ontbreken van logregels is geen bewijs dat je veilig bent.

Tot slot de scanner. Er is een gratis scanner die alleen leest en de artefacten van deze aanvalsketen weegt tot een score en een verdict, zonder iets op je site te wijzigen. Handig als snelle tweede mening, maar lees de waarschuwing van de makers zelf: een schone uitslag is geen garantie, en een treffer is op zichzelf nog geen bewijs.

Vind je iets, dan is de volgorde: alle wachtwoorden resetten, en de secret keys in wp-config.php vervangen zodat elke actieve sessie eruit vliegt. Daarna pas opruimen. Ging er persoonsgegevens door je site heen, dan tellen de meldplicht en de eerste 72 uur na een datalek zwaar mee in wat het je uiteindelijk kost.

4. Zet auto-updates gelaagd aan, niet als één knop

Nu de routine. Auto-updates zijn geen alles-of-niets-schakelaar, en precies daar gaat het meestal fout: mensen zetten alles aan en draaien het na één kapotte pagina weer helemaal uit.

De kern. De constante WP_AUTO_UPDATE_CORE in wp-config.php kent drie waarden: true, false en 'minor'. Sinds WordPress 5.6 staan nieuwe installaties standaard op zowel kleine als grote kernupdates; installaties van vóór die versie doen alleen de kleine. Mijn advies is eenduidig: 'minor' is de absolute ondergrens en zet je nooit uit, want daar komen de beveiligingsreleases doorheen. Grote versies zet je automatisch aan als je een standaardthema draait, en handmatig plus staging-check als je eigen code of een zwaar aangepast thema hebt.

Plugins. Zet auto-updates per plugin aan, via de kolom in het pluginoverzicht, of per plugin met wp plugin auto-updates enable wordfence. Wel automatisch: beveiligingsplugins, back-upplugins, SEO- en cachingplugins, en alles wat je zonder nadenken zou bijwerken. Niet automatisch: de plugin die je afreken- of formulierproces aanstuurt, de pagebuilder waar je hele opmaak op hangt, en alles met een betaalde licentie die via een eigen updater loopt. Die drie categorieën breken je site op de vervelendste manier, namelijk stil.

Thema's. Een thema uit de directory mag automatisch. Een childthema of een thema waarin iemand ooit rechtstreeks bestanden bewerkte: nooit. Die wijzigingen verdwijnen zonder waarschuwing bij de eerste update.

Zet tot slot het beheerders-e-mailadres van WordPress op een postbus die daadwerkelijk gelezen wordt. Auto-updates melden zichzelf per mail, en een routine die rapporteert aan info@ waar niemand naar kijkt, is geen routine.

5. Bouw de staging-check die auto-updates onschadelijk maakt

De angst voor auto-updates is terecht, maar hij wijst naar het verkeerde gevaar. WordPress heeft sinds versie 6.3 een terugrol ingebouwd, maar die herstelt alleen wanneer het updateproces zelf faalt, niet wanneer de update slaagt en je site daarna stuk is. Precies dat tweede geval is wat jou raakt.

Daarom een testkopie. Drie manieren, oplopend in gemak:

1. Handmatig via je host. De meeste Nederlandse hostingpartijen maken met één knop een staging-kopie. Ververs die kopie voordat je test, anders test je op een site van vier maanden geleden en zegt de uitslag niets.
2. Geautomatiseerd via je hostingplatform. Cloudways SafeUpdates test elke update op een tijdelijke staging-omgeving met visuele regressie en rolt automatisch terug als er iets afwijkt, voor 3 dollar per site per maand tot vijf sites en 2 dollar daarboven (prijzen juli 2026). WP Engine biedt met Smart Plugin Manager een vergelijkbare opzet.
3. Geen staging. Dan maak je een verse back-up direct vóór elke batch en werk je in blokken van maximaal vijf plugins, zodat je bij een storing weet welke het was.

Wat je test is kort en altijd hetzelfde: de homepage, één inhoudspagina die je zwaarste template gebruikt, het inlogscherm, en de belangrijkste transactie op je site. Eén formulier echt versturen, één product echt in de winkelwagen leggen. Draait er een webshop op WooCommerce, dan is dat laatste geen luxe.

6. Doe de plugin-audit en spreek een afvoerbeleid af

Elke plugin is een voordeur met een eigen sleutel en een eigen onderhouder. Dat is geen theorie: van de 11.334 kwetsbaarheden die in 2025 in het WordPress-ecosysteem werden gemeld, zat 91 procent in plugins en 9 procent in thema's, tegen zes stuks in de kern zelf.

Loop je pluginlijst één keer per kwartaal langs met vier vragen per stuk. Wanneer kwam de laatste update? Staat er in de directory een waarschuwing dat hij niet getest is met jouw WordPress-versie, of is hij helemaal gesloten? Hoeveel actieve installaties heeft hij nog? En wat breekt er als je hem morgen verwijdert?

Maak van de antwoorden een hard afvoerbeleid, want zonder drempel blijft alles staan:

• Twaalf maanden zonder update: op de lijst, zoek een alternatief.
• Achttien maanden zonder update, of gesloten in de directory: vervangen of verwijderen binnen dat kwartaal.
• Verwijderen betekent verwijderen. Een gedeactiveerde plugin staat nog steeds op schijf en blijft in veel gevallen bereikbaar. Deactiveren is geen beveiligingsmaatregel.

Er is nog een reden om niet te wachten: 46 procent van de gemelde kwetsbaarheden had op het moment van publicatie helemaal geen patch van de maker. "Wachten op een update" is dan geen plan. Wie zelf software laat bouwen, herkent hier het patroon van versies vastpinnen en installatiescripts uitzetten: je bent zo veilig als het slechtst onderhouden onderdeel dat je installeerde.

7. Zet monitoring aan die je op tijd wakker maakt

Uit hetzelfde jaaronderzoek van Patchstack komt het getal dat je monitoring bepaalt: voor zwaar aangevallen kwetsbaarheden ligt de mediane tijd tot massale exploitatie op vijf uur. Dat maakt de vertraging in gratis pakketten tot een keuze, geen detail. Wordfence Free levert firewallregels en malwaresignatures met dertig dagen vertraging; Premium kost 149 dollar per site per jaar en levert ze in realtime (prijzen juli 2026).

Vier lagen die samen genoeg zijn voor een mkb-site:

• Kwetsbaarheidsmeldingen. Patchstack Personal is gratis en waarschuwt je per e-mail zodra er een lek in jouw plugins, thema's of kern bekend wordt; virtuele patches kosten daarbovenop 5 dollar per site per maand.
• Bestandsintegriteit. Zet wp core verify-checksums wekelijks in een cronjob en laat de uitkomst mailen, of gebruik de bestandswijzigingsdetectie van je beveiligingsplugin.
• Beschikbaarheid en reputatie. Een uptime-melder plus Google Search Console, die je waarschuwt zodra Google je site als besmet markeert. Die tweede melding komt vaak eerder binnen dan je eigen scanner.
• De officiële kant. Volg de security advisories van het NCSC voor de software die je echt draait. Bij een kans- en schade-inschatting hoog, hoog is de beslissing al genomen.

Laat elke melding op minstens twee mensen landen. Één vakantie is anders genoeg om je hele spoedbaan uit te schakelen.

8. Leg vast wie wat doet als er om 23.00 uur een noodpatch komt

Dit is het stuk dat bijna niemand opschrijft en dat het verschil maakt tussen vier uur en vier dagen. Je hebt een spoedbaan die op misbruik-signaal draait en een routebaan waarop de rest op cadans blijft. Zet er namen en grenzen bij.

Concreet betekent dat: één naam die mag beslissen en één vervanger, een trigger die geen discussie oplevert (actief misbruik, een vermelding op de KEV-lijst, of een leverancier die zegt "zet het uit"), en vooraf toestemming om zonder overleg te patchen, een eindpunt te blokkeren of de site tijdelijk offline te halen. Zet erbij hoeveel uur maximaal mag zitten tussen signaal en mitigatie. Vier uur is voor een actief misbruikt kernlek een verdedigbare norm; wat je kiest is minder belangrijk dan dat het getal bestaat.

De valkuilen die je routine alsnog ondermijnen

• Auto-updates uitzetten "voor de controle". Met AUTOMATIC_UPDATER_DISABLED sluit je ook het noodkanaal waarmee WordPress.org bij een kritiek kernlek geforceerd bijwerkt. Wil je grip, zet dan grote versies handmatig en laat de kleine lopen.
• Patchen en het daarbij laten. Een update sluit de deur, hij zet geen ongenode gast buiten die er al is. Zonder stap 3 weet je niet welke van de twee je hebt.
• Deactiveren in plaats van verwijderen. De bestanden blijven staan en blijven vaak bereikbaar. Verwijder wat je niet gebruikt.
• Testen op een verouderde staging-kopie. Een kopie van vier maanden oud draait niet jouw content, niet jouw plugins en niet jouw fout. Ververs eerst.
• Vertrouwen op de ingebouwde terugrol. Die vangt een mislukte update op, niet een geslaagde update die je site sloopt. Dat verschil is precies waar je nachtwerk begint.
• Alleen naar de kern kijken. Negen op de tien meldingen gaan over plugins en thema's. De kern is meestal je kleinste probleem.
• Alle meldingen naar één mailbox van één persoon. Vakantie, ziekte of een volle inbox maakt van je spoedbaan een routebaan.

Beslis-kader: hoeveel routine past bij jouw site

Er zijn drie assen die de keuze bepalen. Wie zet vandaag de updates: jij, een bureau of niemand? Loopt er omzet of leadverkeer over de site? En zit er maatwerkcode of een koppeling naar je backoffice in? Daaruit volgen vier profielen.

Zelfbeheer met auto-updates. Kleine kern automatisch, plugins gelaagd, een gratis kwetsbaarheidsmelder en een kwartaalaudit. Past bij een site die vooral een visitekaartje is. Kost je twee uur per kwartaal en nul euro.

Managed hosting met geteste automatische updates. Je host detecteert, test op staging met visuele regressie en rolt terug. Past zodra er omzet of leads over de site lopen en je die tijd niet zelf wilt kwijt zijn. Reken op een paar dollar per site per maand bovenop je hosting.

Vaste beheerder met staging en een afgesproken spoedbaan. Iemand met naam, een terugrolplan en toestemming om buiten kantooruren in te grijpen. Past bij maatwerkcode of koppelingen naar je administratie, waar een blinde auto-update meer kapotmaakt dan hij oplost.

Eigenaarschap beleggen. Herkent niemand zich in de vraag wie de updates doet, dan is dat je eerste actie, nog vóór alle techniek. Een routine zonder eigenaar is een routine die niet bestaat.

Wat kost welke aanpak, en wat krijg je ervoor:

De vuistregel: koop de lagen die de markt goed heeft opgelost (melden, scannen, testen) en steek je eigen tijd in het stuk dat uniek is voor jou, namelijk de afspraak wie wat wanneer doet. Daar zit het verschil tussen een vinkje en een site die maandagochtend nog staat.

Uitgewerkt voorbeeld: een webshop op 6.9.3

Neem een installatiebedrijf met twaalf medewerkers, een WooCommerce-shop op WordPress 6.9.3 en 24 plugins. Vrijdagavond 19.40 uur komt de melding binnen.

19.45 uur. Versie opgezocht: 6.9.3, dus de volledige keten naar code-uitvoering. Geen twijfel over de urgentie.

19.55 uur. Snapshot gemaakt via het hostingpanel, bestanden plus database, en apart weggezet. Nog niets bijgewerkt.

20.05 uur. Bijgewerkt naar 6.9.5 via wp-admin. Homepage, productpagina, winkelwagen en afrekenpagina getest. Werkt.

20.30 uur. Sporencheck. wp core verify-checksums geeft geen afwijkingen. Geen beheerders met een wp2_-prefix, geen php-bestanden in uploads die na 16 juli zijn aangeraakt, geen treffers op /wp-json/batch/v1 in het access log. Geen bewijs van inbraak, maar ook geen garantie: dat verschil wordt in de mail aan de directeur expliciet benoemd.

Zaterdag. Alle wachtwoorden gereset, secret keys in wp-config vervangen, en het databasewachtwoord geroteerd. Kostte veertig minuten.

De week erna. Pluginaudit: van 24 plugins hadden er vier meer dan achttien maanden geen update en waren er twee al niet meer nodig. Zes verwijderd, één vervangen. Overgebleven: 17 plugins, waarvan er 13 op automatisch gaan. De vier die het afreken- en formulierproces raken blijven handmatig, in een maandelijks venster van dertig minuten op dinsdagochtend.

De routine sindsdien. Kern op automatisch voor kleine versies, grote versies handmatig na een staging-test. Meldingen naar een gedeelde postbus die de directeur en de marketeer allebei zien. Eén afspraak op papier: bij een actief misbruikt lek in de kern mag de marketeer zonder overleg patchen of de site offline halen, binnen vier uur.

Totale investering: één avond en ongeveer drie uur in de week erna. De volgende noodpatch kost nog een kwartier, want de kern doet het dan zelf en de vraag is alleen nog of er sporen zijn.

Wat je hierna nog moet regelen

Een patchroutine dekt één deur, en het is niet de deur waardoor de meeste inbraken lopen. Een gestolen beheerderswachtwoord slaat je hele update-discipline over. Wachtwoordmanager, phishing-bestendige MFA en een geteste back-up horen daarom in de vijf lagen die je een keer per kwartaal naloopt, met deze routine als de patchlaag daarbinnen.

En houd de eerlijke grens voor ogen. Deze routine maakt je niet onkwetsbaar; hij verkort de tijd dat je open staat en zorgt dat je het merkt. Dat is precies het verschil dat telt wanneer een lek binnen vijf uur massaal wordt uitgebuit. De vraag is niet meer op welke dinsdag je patcht. De vraag is wat je site vanavond doet zonder jou.