Gehackte WordPress-sites zien er niet altijd kapot uit. Het meest voorkomende signaal dat ik zie is een melding in Google Search Console: duizenden Japanse pagina’s zijn ineens geïndexeerd op een site waarvan de eigenaar zeker wist dat er niets mis was. De site laadt prima als je inlogt. Het dashboard ziet er schoon uit. De hack is onzichtbaar voor iedereen die geen Googlebot is.
Na tien jaar WordPress-sites opschonen kan ik je vertellen dat de lijst van werkelijke oorzaken korter is, en anders, dan de standaard checklist die online de ronde doet. Het merendeel van die checklist is vendor-driven: installeer deze plugin, zet die instelling aan. Dit artikel rangschikt de vijf aanvalsvectoren die ik het vaakst tegenkom, legt uit waarom sommige van de meest aanbevolen verdedigingen het punt missen, en eindigt met fixes in volgorde van daadwerkelijke impact.
Het probleem met het standaard beveiligingsadvies
Open een willekeurige “WordPress-beveiligingschecklist” van een hostingprovider en je ziet dezelfde opener: sterke wachtwoorden, 2FA, verberg je login-URL. Dat advies klopt. Het adresseert alleen niet hoe de meeste gecompromitteerde sites daadwerkelijk gecompromitteerd zijn geraakt.
Patchstacks rapport van 2025 toonde aan dat 43% van de nieuwe WordPress-kwetsbaarheden nul authenticatie vereiste om te misbruiken (Patchstack State of WordPress Security 2025). De aanvaller ziet je loginpagina nooit. Ze raken een kwetsbaar plugin-endpoint direct en krijgen code-uitvoering of admin-toegang zonder ooit een wachtwoord te raden. MalCare’s eigen data is duidelijk: 2FA beschermt tegen ongeveer 5% van de dreigingen die sites daadwerkelijk compromitteren (MalCare blog).
Het dominante beginners-advies, “installeer Wordfence en houd plugins bijgewerkt, dan zit je goed”, is half juist. Wordfence blokkeert brute force effectief. Maar Wordfence draait op de applicatielaag, nadat de webserver en PHP al geladen zijn. Een PHP-webshell geüpload naar /wp-content/uploads/ wordt door de webserver direct uitgevoerd, nog voordat WordPress opstart. Wordfence ziet hem niet. Patchstacks rapport van 2026 mat dat traditionele WAFs slechts 12% van WordPress-specifieke aanvallen blokkeren (Patchstack 2026).
En het standaard advies “patch snel op basis van CVSS-score” misleidt je in beide richtingen. Patchstack ontdekte dat 64,7% van de openbaar gemaakte kwetsbaarheden als CVSS “Medium” is geclassificeerd, terwijl 69,6% van die gevallen waarschijnlijk nooit in het wild wordt misbruikt. Ondertussen worden sommige lager gescoorde kwetsbaarheden binnen uren massaal aangevallen. Het signaal dat je wilt is werkelijke exploitatie-frequentie, niet een ernstscore.
De 5 aanvalsvectoren, gerangschikt op hoe vaak ik ze zie
Deze rangschikking is gebaseerd op werkelijke exploitatie-frequentie in het wild, afkomstig uit onderzoek van Wordfence, Patchstack en Sucuri, gekruist met de cleanup-patronen die ik steeds weer tegenkom. Niet op theoretische ernst. Niet op CVSS. De meeste hoog-CVSS items in een willekeurig kwartaal worden nooit een keer aangevallen, terwijl een handvol “Medium” plugin-bugs met 9 miljoen verzoeken in twee weken worden platgebombardeerd.
#1 Kwetsbare plugins: de deur die aanvallers gebruiken
Dit is de vector. 96% van de WordPress-kwetsbaarheden die in 2024 openbaar werden gemaakt kwamen uit third-party plugins, 4% uit themes, minder dan 6 in totaal uit de kern (Wordfence 2024 Annual Report). In 2025 steeg het aantal naar 11.334 nieuwe kwetsbaarheden, een stijging van 42% jaar-op-jaar, waarbij 46% ongepatcht was op het moment van publieke bekendmaking. Het exploitatie-window voor zwaar aangevallen kwetsbaarheden heeft een gewogen mediaan van 5 uur.
Dat is geen theorie. LiteSpeed Cache CVE-2024-28000, een privilege escalation in een plugin met 5 miljoen installaties, zag 48.500 aanvalspogingen in één periode van 24 uur na bekendmaking (Wordfence). GutenKit en Hunk Companion samen zorgden voor 9 miljoen exploitatiepogingen in de twee weken na bekendmaking in oktober 2024. Really Simple Security CVE-2024-10924 was een unauthenticated auth bypass die 4 miljoen installaties trof en 2FA volledig omzeilde via een REST-endpoint.
Het cleanup-patroon dat ik het vaakst zie, volgt altijd hetzelfde script. Een plugin-kwetsbaarheid voor bestandsupload, geen authenticatie vereist, accepteert een PHP-bestand vermomd als afbeelding. De shell belandt in /wp-content/uploads/. De webserver voert hem uit bij het volgende verzoek. Het Wordfence-dashboard van de eigenaar zegt nog steeds dat alles in orde is, want Wordfence ziet het verzoek nooit. Twee weken later is er een backdoor-admin-gebruiker, de database zit vol geïnjecteerde scripts, en de cleanup-factuur telt vier cijfers.
Fix: zet automatische updates aan voor alles wat dat ondersteunt. Deactiveer én verwijder ongebruikte plugins, deactiveren alleen is niet genoeg. Doe een server-side scan op onverwachte PHP-bestanden in /uploads, dat is precies wat GuardingWP (mijn eigen scanner-as-a-service) opvangt, en wat de meeste gratis WP-scanners structureel missen. Voor de onderliggende onderhoudsdiscipline is plugins actueel houden de investering met de laagste inspanning en de hoogste dekking.
#2 Credential-aanvallen: hoog volume, lage conversie
Brute force en credential stuffing op wp-login.php genereren veruit het meeste aanvalsverkeer. Wordfence blokkeerde 6,4 miljard brute force-pogingen per maand in 2024 en 100 miljard credential stuffing-pogingen van 74 miljoen unieke IP-adressen over het hele jaar (Wordfence 2024). Een gemiddelde WordPress-site wordt elke 34 minuten gescand.
Volume is geen risico, dat is het punt. De conversieratio van credential-aanvallen zakt onder de 0,02% zodra je basale verdediging toevoegt: rate-limiting, het blokkeren van de standaard gebruikersnaam admin, en unieke wachtwoorden. 2FA is een echte winst tegen precies déze vector. Maar de afweging is duidelijk: het helpt niet tegen de andere vier. CVE-2024-10924 liep 2FA simpelweg voorbij door /reallysimplessl/v1/two_fa/skip_onboarding rechtstreeks te raken. De loginpagina was niet de deur.
Fix: schakel xmlrpc.php uit als je de mobiele app of Jetpack niet gebruikt, pas rate-limiting toe op wp-login.php, verwijder de standaard gebruikersnaam admin, gebruik een wachtwoordmanager. Eén kanttekening: ik raad af om alleen op Wordfence Free te leunen als brute-force-verdediging, want de gratis versie heeft een vertraging van 30 dagen op firewall-regelupdates voor nieuw bekendgemaakte kwetsbaarheden (Ben Ryan technical analysis). Als het exploitatie-window 5 uur is en je patch-vertraging 30 dagen, kloppen de cijfers niet.
#3 SEO-spam-injectie: de stille aanval
Dit is de aanval die zichzelf terugbetaalt. Aanvallers injecteren duizenden doorwaypagina’s, meestal in het Japans of met gokzoekwoorden, en gebruiken cloaking om ze alleen aan zoekmachinebots te tonen. Jij logt in: site ziet er prima uit. Googlebot crawlt: 4.000 spampagina’s geïndexeerd onder jouw domein. De aanvaller verdient aan het gekaapte verkeer door het door te sturen naar namaakwinkels.
Sucuri’s SiteCheck-data van 2024: 117.393 detecties van Japanse zoekwoord-spam, 114.318 verborgen content-spam, 79.817 gok-spam (Sucuri SiteCheck Malware Trends 2024). 10,07% van alle remediaties bevatte kwaadaardige .htaccess-regels die de cloaking afdwingen. Het Hacked Website Report van 2023 vond kwaadaardige admin-gebruikers in 55,2% van de geïnfecteerde databases.
Ik heb sites gecleand waarbij dit vier maanden onopgemerkt liep. Het eerste waarschuwingssignaal is bijna altijd Google Search Console: een plotse piek in geïndexeerde pagina’s, of organisch verkeer dat instort omdat Google het domein heeft afgestraft. Op dat moment is de cleanup groter dan het oorspronkelijke invalspoint, want er is ook een backdoor en een kwaadaardige admin te vinden.
Fix: controleer wekelijks het “Pagina’s”-rapport in Google Search Console op onverwachte geïndexeerde URL’s. Stel een alert in voor organisch verkeer. Doe een server-side malware-scan (niet alleen een front-end URL-scan, die foppen de cloaking). Controleer .htaccess op onbekende rewrite-regels.
#4 Backdoors: waarom één cleanup vaak niet genoeg is
Het initiële exploit is zelden het laatste. 49,21% van de gecompromitteerde sites die Sucuri in 2023 analyseerde bevatte minstens één backdoor (Sucuri 2023 Report). Sucuri verwijderde dat jaar alleen al 21.062 backdoors. Kwaadaardige admin-accounts doken op in 55,2% van de geïnfecteerde databases.
Het patroon is consistent. Een plugin-kwetsbaarheid geeft de aanvaller schrijftoegang tot bestanden. Ze droppen een PHP-shell in /uploads of injecteren één regel in wp-blog-header.php. Ze maken een nieuw admin-account aan met een onschuldig klinkende naam. Ze kunnen de databasecredentials in wp-config.php wijzigen, de eigenaar buitensluiten, en een vers admin-account aanmaken om toegang te houden. De eigenaar hoort er voor het eerst van als ze niet meer kunnen inloggen, en op dat moment heeft de aanvaller al gehaald wat hij zocht.
Wat concurrerende checklists missen: als je een backup terugzet zonder eerst het invalspoint te identificeren, zet je dezelfde kwetsbare plugin-versie terug en ben je binnen dagen opnieuw gecompromitteerd. Ik heb dezelfde site drie keer in twee maanden zien opschonen, omdat het cleanup-team steeds de diagnosestap oversloeg.
Fix: bestandsintegriteitsmonitoring zodat je nieuwe PHP-bestanden ziet verschijnen op plekken waar ze niet horen. Na elk incident: zet alle admin-gebruikers op een rij en verifieer ze elk afzonderlijk. Controleer of wp-config.php niet is aangepast. Patch het invalspoint voordat je een backup terugzet.
#5 Supply chain: de vector waar je je niet uit kunt patchen
Dit is de vector die geen enkel concurrerend artikel behandelt, en die het “houd plugins bijgewerkt”-advies het meest ondermijnt, want updaten naar de nieuwste versie is precies hoe de backdoor binnenkomt.
In april 2026 kocht een aanvaller 30+ WordPress-plugins via Flippa, de marketplace voor website-verkoop, en plantte een slapende backdoor in al die plugins (TechCrunch). De code zag er onschuldig uit: een fetch_ver_info()-functie die een externe URL aanroept, met een unserialize() op de respons. De backdoor activeerde 8 maanden later, nadat hij via verschillende kleine versie-updates die site-eigenaren netjes hadden geïnstalleerd door productie had gerold. Geen CVE. Geen WordPress.org-melding. Geen rode vlag in welk dashboard dan ook.
Dit was geen incident op zichzelf. In juni 2024 werden vijf plugins op WordPress.org via credential stuffing op de developer-accounts voorzien van backdoors, met geïnjecteerde code om frauduleuze admin-gebruikers en SEO-spam aan te maken (Wordfence). Patchstack volgde 1.614 verlaten plugins die nog steeds actief zijn op live sites, ondanks verwijdering uit de WordPress.org-repository, zonder mechanisme dat de eigenaar waarschuwt.
Je kunt je hier niet uit patchen. De patch ís de dreiging.
Fix: volg eigenaarswijzigingen bij plugins (Patchstack publiceert die). Beperk het aantal plugins agressief: elke plugin is een onbewaakt supply-chain-risico. Geef de voorkeur aan plugins met een aantoonbare eigendomsgeschiedenis en een actieve maintainer. Doe periodiek server-side scans om slapende shells te vangen die WP-niveau-tools omzeilen. Dit is precies de vector waarvoor GuardingWP is gebouwd: scannen op bestandssysteemniveau op backdoor-patronen die applicatielaag-scanners niet triggeren.
Hoe een echte verdedigingsstack eruitziet
Er is geen enkele plugin die alle vijf vectoren afdekt. Wie dat verkoopt, verkoopt. Wat volgt is gerangschikt op dekking per inspanning, wat ik als eerste zou installeren op een site die ik zojuist overnam:
- Patch plugins binnen 48 uur na bekendmaking, niet als het uitkomt. Zet automatische updates aan voor alles dat dat ondersteunt. Voor de periode tussen bekendmaking en een vendor-patch sluiten virtual-patching-diensten zoals Patchstack vPatch het window.
- Server-side bestandsscanning, niet alleen plugin-scanning. Bestandsupload-webshells omzeilen elke WP-niveau-scanner. Dat is de laag waar GuardingWP op werkt, en wat de meeste gratis beveiligingsplugins structureel niet kunnen.
- Login-hardening: rate-limiting, unieke gebruikersnaam, 2FA. Weinig moeite, sluit de brute-force-vector af. Geen complete verdediging, maar een snelle winst.
- Minimaliseer het plugin-oppervlak. Elke inactieve plugin is een onbewaakt aanvalsoppervlak, en elke actieve plugin is een supply-chain-risico. Deactiveer én verwijder, niet alleen deactiveren. Doe twee keer per jaar een audit.
- Monitor op onverwachte geïndexeerde content. Het “Pagina’s”-rapport in Google Search Console is je vroegste signaal voor SEO-spam. Controleer wekelijks, stel een verkeersalert in, behandel elke onverklaarde geïndexeerde URL als een potentieel incident.
Als je liever geen plugin-CVEs bijhoudt, bestanden scant en GSC wekelijks controleert, is dat precies waarvoor beheerd WordPress-onderhoud bestaat. Het werk verdwijnt niet. Iemand moet het doen.
Tot slot
Beveiliging is geen product of een instelling. Het is weten welke deur aanvallers gebruiken, en het slot daar als eerste op zetten.