Plugins zijn verantwoordelijk voor het merendeel van beveiligingslekken
Van alle geïnfecteerde WordPress-sites ontstaat ruim de helft van de infecties door verouderd of verlaten plugingebruik, en plugins zijn in bredere zin verantwoordelijk voor het grootste deel van alle gevonden beveiligingslekken op dit platform. Van de daadwerkelijke hacks richt een aanzienlijk deel zich specifiek op verouderde versies: een deel van de aanvallen buit bekende kwetsbaarheden uit in software die simpelweg nog niet is bijgewerkt, en ook verouderde kernversies van het CMS zelf zijn een terugkerende oorzaak van gehackte sites. Dit zijn geen incidentele uitschieters, maar het structurele patroon achter de meeste website-hacks.
2026 liet zien hoe snel dit kan escaleren
In april 2026 werden meer dan dertig vertrouwde WordPress-plugins gecompromitteerd nadat aanvallers stiekem backdoor-malware in reguliere plugin-updates hadden verwerkt: sites die keurig hun updates installeerden, kregen daarmee ongemerkt kwaadaardige code binnen. Diezelfde maand verwijderde de officiële pluginrepository op één dag meer dan 25 plugins wegens ernstige beveiligingsproblemen. Dit soort supply chain-aanvallen, waarbij niet de eindgebruiker maar de plugin-ontwikkelaar zelf het doelwit is, nemen toe en zijn met een reguliere update-controle alleen niet altijd te voorkomen.
Wat een kwetsbare plugin in de praktijk betekent voor uw site
Een misbruikte kwetsbaarheid leidt zelden meteen tot een zichtbaar kapotte site. Vaker injecteert een aanvaller onopgemerkt code die bezoekers doorstuurt naar een andere site, spamlinks toevoegt aan bestaande pagina's, of gegevens uit formulieren afvangt zonder dat u of uw bezoekers dat merken. Pas als zoekmachines of browsers de site als onveilig markeren, of als een hostingpartij de site preventief offline haalt, wordt het probleem zichtbaar, en dan is de schade aan vindbaarheid en vertrouwen vaak al aangericht.
Waarom dit risico groter is bij een webshop
Bij een webshop staat er meer op het spel dan bij een informatieve site zonder transacties: een kwetsbare plugin kan naast contentmanipulatie ook toegang geven tot bestel- en klantgegevens, of het betaalproces stilletjes ondermijnen zonder dat de betaling zichtbaar mislukt. Voor sites die persoonsgegevens of betalingen verwerken, weegt een strikt update-ritme daarom zwaarder mee dan bij een eenvoudige, statische pagina, en is het extra belangrijk om plugins met toegang tot gevoelige gegevens als eerste te controleren bij iedere ronde.
Hoe u het risico beperkt zonder alles zelf te hoeven bijhouden
Een aantal concrete gewoontes beperkt het risico aanzienlijk: verwijder plugins die u niet meer actief gebruikt in plaats van ze inactief te laten staan, controleer bij nieuwe plugins wanneer ze voor het laatst zijn bijgewerkt en of de ontwikkelaar nog actief is, en installeer kritieke beveiligingspatches direct in plaats van te wachten op een geplande updateronde. Een plugin die al maanden geen update heeft gekregen terwijl vergelijkbare plugins dat wel regelmatig doen, is een signaal om extra alert op te zijn of een alternatief te overwegen.
Wat u vervolgens doet als een plugin-update tóch iets breekt, staat beschreven in wat te doen na fouten door een plugin-update. En omdat plugins niet het enige kwetsbare onderdeel zijn, is het verstandig om beveiliging in bredere zin periodiek te controleren; zie SSL en beveiliging controleren voor de rest van die checklist.
Ook thema's en kernbestanden lopen risico, niet alleen plugins
Plugins krijgen de meeste aandacht omdat ze het grootste deel van de kwetsbaarheden veroorzaken, maar een verouderd thema of een verouderde kernversie van het CMS zelf kent hetzelfde risico. Een aanzienlijk deel van de gehackte sites draaide op het moment van de hack een verouderde, kwetsbare versie van de kernsoftware zelf, los van eventuele plugins. Beperk een controle dus niet tot alleen de pluginlijst, maar neem ook thema en kernversie mee als vast onderdeel.
Waarom controleren en herstellen vaak samen moeten gaan
Een kwetsbare plugin signaleren is één stap, maar zonder daadwerkelijk herstel blijft het risico bestaan. Wie liever niet zelf uitzoekt welke plugin het probleem is en hoe die veilig te vervangen of bij te werken, kan dit laten uitvoeren door een partij die zowel de controle als de reparatie oppakt; zie website laten controleren en repareren voor hoe dat traject werkt.
