Waarom verouderde plugins een risico vormen voor je website -

Verouderde plugins zijn de meest gebruikte ingang voor aanvallen op WordPress-sites. Van alle nieuwe kwetsbaarheden die in 2025 in het WordPress-ecosysteem opdoken, zat 91 procent in plugins, en aanvallers hebben vaak maar een paar uur nodig om zo’n lek op grote schaal te misbruiken. Met een opgeruimde pluginlijst, een vaste updateroutine en een back-up die je echt hebt getest, haal je het grootste deel van dat risico weg.

Bijna elke WordPress-site die een paar jaar meedraait, heeft ze: plugins die ooit voor één klus zijn geïnstalleerd en daarna zijn vergeten. Een formulierplugin van de vorige webbouwer, een slider die allang van de homepage is verdwenen, een importtool die één keer is gebruikt. De site doet het, dus het rode bolletje bij Updates blijft staan tot er tijd voor is. Intussen staat er code op je server die al jaren door niemand is nagekeken, terwijl de lijst met bekende lekken elke week langer wordt.

Plugins zijn het zwakke punt van WordPress

Beveiligingsbedrijf Patchstack telde in 2025 in totaal 11.334 nieuwe kwetsbaarheden in het WordPress-ecosysteem, 42 procent meer dan een jaar eerder. Daarvan zat 91 procent in plugins en 9 procent in thema’s. In WordPress zelf werden zes kwetsbaarheden gemeld, allemaal met een lage prioriteit.

Die verhouding is goed te verklaren. Aan de core werkt een groot team met een eigen securityproces, en kleine beveiligingsupdates worden standaard automatisch geïnstalleerd. Plugins komen van duizenden verschillende makers, van bedrijven met een eigen securityteam tot een enkele ontwikkelaar die er in de avonduren aan werkt. Stopt zo’n ontwikkelaar ermee, dan blijft de plugin gewoon op jouw site draaien, zonder dat iemand nog lekken dicht.

Betaalde plugins zijn daarbij geen veilige haven. Patchstack ontving in 2025 bijna tweeduizend geldige meldingen over premium en freemium componenten, en 76 procent daarvan was in de praktijk te misbruiken. Omdat onderzoekers minder makkelijk bij de code van betaalde plugins kunnen, blijven fouten daar langer onopgemerkt.

Oude lekken blijven gewoon werken

Aanvallers kiezen hun doelwitten zelden met de hand. Scripts lopen dag en nacht het internet af op zoek naar sites met een bepaalde plugin in een kwetsbare versie. Of jouw site een webshop met duizenden klanten is of de pagina van een lokale sportvereniging, maakt voor zo’n script weinig uit. Elke gekaapte site is bruikbaar om spam te versturen, bezoekers door te sturen naar phishingpagina’s of zoekmachines te vervuilen met nepteksten.

Dat oude versies daarbij een dankbaar doelwit zijn, blijkt uit de lijst met meest aangevallen kwetsbaarheden van 2025. Slechts vier van de tien waren dat jaar gepubliceerd. De rest stamde uit 2023 en 2024 en zat in bekende plugins als LiteSpeed Cache, GiveWP en WooCommerce Payments, waarvoor de oplossing al lang klaarstond. De aanvallen werden gemeten op sites waar de oude versie nog draaide.

Bij nieuwe lekken gaat het intussen snel. Ongeveer de helft van de kwetsbaarheden met grote impact wordt volgens Patchstack binnen 24 uur na publicatie aangevallen. Voor de lekken die het zwaarst worden misbruikt, ligt de gewogen mediaan op vijf uur. Een update die een maand blijft liggen, geeft aanvallers ruim de tijd.

Breng eerst in kaart wat er draait

Updatehygiëne begint met een overzicht. In het dashboard zie je onder Plugins welke uitbreidingen actief zijn, welke zijn uitgeschakeld en voor welke een update klaarstaat. Heb je SSH-toegang, dan gaat het sneller met WP-CLI:

_{wp core version
wp plugin list --fields=name,status,version,update,auto_update
wp theme list --fields=name,status,version,update}

Kijk daarna per plugin op de pagina in de plugindirectory van WordPress.org wanneer hij voor het laatst is bijgewerkt. Bij plugins die al lang stilstaan, toont de directory een waarschuwing dat de plugin niet is getest met de laatste drie grote WordPress-versies. Let ook op plugins die helemaal uit de directory zijn verdwenen. Daarvoor komt nooit meer een update binnen, waardoor ze in je dashboard keurig bijgewerkt lijken.

Noteer per plugin drie dingen: waarvoor je hem gebruikt, wanneer de laatste release was en waar updates vandaan komen. Dat laatste is vooral bij betaalde plugins van belang. Is de licentie verlopen, dan stopt meestal ook de aanvoer van updates, en dat merk je pas als je er gericht naar kijkt.

Opruimen komt voor updaten

Elke plugin die je verwijdert, hoef je nooit meer bij te werken. Loop de lijst daarom kritisch door voordat je op de updateknop drukt.

Uitgeschakelde plugins kunnen weg, want de bestanden staan nog op de server en kunnen bij sommige lekken nog steeds rechtstreeks worden aangeroepen. Uitschakelen alleen beschermt je dus onvoldoende. Hetzelfde geldt voor thema’s die je niet gebruikt. Bewaar het actieve thema en één standaardthema als terugvaloptie, en verwijder de rest.

Plugins die al jaren geen update hebben gehad, vervang je door een alternatief dat actief wordt onderhouden. Soms blijkt de functie inmiddels in WordPress zelf te zitten, of in een plugin die je al gebruikt. Illegale kopieën van betaalde plugins, de zogeheten nulled plugins, horen op geen enkele site thuis. Ze krijgen geen updates en bevatten regelmatig een achterdeur.

Hoe werk je bij zonder dat de site omvalt?

De angst dat een update iets sloopt, is de belangrijkste reden dat updates blijven liggen. Die angst is terecht bij een site die jaren achterloopt, en met een vaste volgorde hou je het risico klein.

1. Maak een volledige back-up van bestanden en database, en controleer of je die kunt terugzetten. Met wp db export heb je binnen een paar seconden een databasedump.
2. Loopt een plugin of WordPress zelf meerdere hoofdversies achter, test de update dan eerst op een kopie van de site. Een stagingomgeving of een lokale kopie volstaat.
3. Bekijk met wp plugin update --all --dry-run wat er zou veranderen, zonder dat er iets wordt aangepast.
4. Werk plugins een voor een of in kleine groepjes bij, en begin met de plugins waarvoor een beveiligingslek bekend is.
5. Controleer na elke stap de onderdelen waar je site om draait: het bestelproces, formulieren, de inlog en de zoekfunctie.
6. Werk daarna thema’s en de WordPress-core bij en doe dezelfde controle nog een keer.

Loopt een site meerdere grote versies achter, lees dan de changelog van de belangrijkste plugins. Pagebuilders en webshopplugins voeren bij grote releases soms databasewijzigingen door die je niet zomaar terugdraait. Een back-up van vlak voor de update is dan je enige weg terug.

Automatische updates met beleid

WordPress installeert kleine core-updates al jaren vanzelf. Sinds versie 5.5 kun je dat ook per plugin en per thema aanzetten, in het dashboard of met wp plugin auto-updates enable gevolgd door de naam van de plugin. Vanaf versie 6.6 zet WordPress een plugin automatisch terug naar de vorige versie als een automatische update een fatale PHP-fout veroorzaakt.

Dat vangnet heeft wel grenzen, want een kapotte lay-out, een formulier dat niets meer verstuurt of een betaalstap die vastloopt, levert geen fatale fout op en blijft onopgemerkt. Een werkbare verdeling is om automatische updates aan te zetten voor plugins met een beperkte rol, zoals een cookiemelding of een redirectplugin, en de plugins waar omzet aan hangt handmatig bij te werken na een test. Zet in beide gevallen de e-mailmeldingen aan en lees ze ook.

Vergeet PHP niet

Onder WordPress draait PHP, en ook dat veroudert. PHP 8.1 krijgt sinds eind 2025 geen beveiligingsupdates meer, en voor PHP 8.2 loopt de ondersteuning tot eind 2026. Oude plugins zijn vaak de reden dat een site op een verouderde PHP-versie blijft hangen, omdat ze op een nieuwere versie foutmeldingen geven. Dat is een extra reden om ze te vervangen. Welke versie je site gebruikt, zie je in het dashboard onder Gereedschap, Sitediagnose. Het omzetten zelf regel je in het controlepaneel van je hostingpakket.

Updates lossen niet alles op

Bijwerken is noodzakelijk en tegelijk onvoldoende. Volgens Patchstack was voor 46 procent van de kwetsbaarheden in 2025 nog geen oplossing beschikbaar op het moment dat ze openbaar werden. Je kunt dan updaten wat je wilt, het lek blijft open.

Daarom horen er een paar maatregelen naast. Volg de meldingen over plugins die je gebruikt, bijvoorbeeld via de openbare databases van Patchstack, Wordfence of WPScan. Verschijnt er een ernstig lek zonder patch, schakel de plugin dan uit en verwijder hem tot er een oplossing is. Een webapplicatiefirewall met regels die specifiek op WordPress-lekken zijn gericht, kan aanvallen tegenhouden in de periode tussen publicatie en patch. Patchstack verkoopt zelf zulke bescherming, dus lees de cijfers met dat belang in het achterhoofd.

Beperk verder de schade als het toch misgaat. Geef alleen beheerdersrechten aan mensen die ze nodig hebben, zet tweestapsverificatie aan voor alle beheerders en bewaar back-ups op een andere plek dan de webserver.

Leg vast wie het doet en wanneer

Updates blijven meestal liggen omdat niemand zich er eigenaar van voelt. Zet daarom een naam en een ritme op papier. Een werkbaar schema bestaat uit elke week een kwartier voor het doorlopen en installeren van updates, elke maand een blik op de pluginlijst en de beveiligingsmeldingen, en elk kwartaal een hersteltest van de back-up. Bij een ernstig lek in een plugin die je gebruikt, werk je dezelfde dag nog bij.

Beheer je meerdere sites, bijvoorbeeld als bureau of MSP, dan loont het om dit te centraliseren. Met tools als MainWP of ManageWP zie je in één overzicht welke sites achterlopen, en met WP-CLI kun je dezelfde controles over al je sites scripten. Spreek met klanten af wie verantwoordelijk is voor updates en wat er gebeurt met plugins die zij zelf installeren. Staat dat in het contract, dan voorkom je discussie op het moment dat er een site is gehackt.