De kern: de overweldigende meerderheid van WordPress-hacks is terug te voeren op een kleine set goed begrepen kwetsbaarheden — verouderde plugins en thema's, zwakke admin-inloggegevens, SQL-injectie in kwetsbare code, cross-site scripting en blootgestelde XML-RPC-eindpunten — elk met een specifieke, bekende oplossing in plaats van een vaag advies om "de beveiliging te verbeteren".
Waarom WordPress zo'n veelvoorkomend doelwit is
WordPress draait een groot deel van alle websites — W3Techs volgt dit al meerdere jaren consistent op ruim 40% van het hele web. Die schaal is precies de reden waarom het wordt aangevallen: een enkele kwetsbaarheid ontdekt in een populaire plugin kan mogelijk worden misbruikt op tienduizenden sites die nog de kwetsbare versie draaien, waardoor geautomatiseerde massascan-aanvallen de moeite waard zijn voor een aanvaller op een manier die een op maat gebouwde site zelden rechtvaardigt.
Dit is belangrijke context omdat het het probleem correct herkadert: de WordPress-kern zelf is bij de meeste aanvallen niet het zwakke punt. Het omringende plugin- en thema-ecosysteem is dat wel, samen met basale configuratiekeuzes die volledig binnen de controle van de site-eigenaar liggen.
Verouderde plugins en thema's
Beveiligingsonderzoek stelt consistent vast dat verouderde plugins en thema's met publiekelijk bekendgemaakte kwetsbaarheden veruit de grootste aanvalsvector zijn voor WordPress-inbraken — ver vóór kernkwetsbaarheden of gerichte, op maat gemaakte aanvallen. Zodra een kwetsbaarheid publiekelijk bekend wordt gemaakt (zelfs wanneer er al een patch is uitgebracht), beginnen geautomatiseerde scanners binnen enkele uren het web af te speuren naar sites die nog de kwetsbare versie draaien.
De oplossing is eenvoudig maar vereist discipline: schakel waar mogelijk automatische updates in voor plugins en thema's, verwijder elke plugin die niet meer actief wordt onderhouden (controleer de "laatst bijgewerkt"-datum in de WordPress-pluginmap), en controleer de kwetsbaarheidsgeschiedenis van nieuwe plugins voordat je ze installeert via een database zoals de WPScan-kwetsbaarhedendatabase.
Zwakke of hergebruikte admin-inloggegevens
Brute-force-inlogpogingen tegen wp-login.php zijn constante achtergrondruis op het web — geautomatiseerde bots proberen veelgebruikte combinaties van gebruikersnaam/wachtwoord tegen elke WordPress-site die ze vinden, en een zwak of hergebruikt wachtwoord verandert die achtergrondruis in een daadwerkelijke inbraak.
De oplossing: dwing sterke, unieke wachtwoorden af voor elk admin-account, schakel tweefactorauthenticatie in, hernoem of beperk de toegang tot de standaard "admin"-gebruikersnaam als deze nog wordt gebruikt, en beperk inlogpogingen om geautomatiseerde brute-force-tools te vertragen.
SQL-injectie in kwetsbare plugins
SQL-injectie stelt een aanvaller in staat om een databasequery te manipuleren via het eigen invoerveld van een plugin — een contactformulier, een zoekbalk, een URL-parameter — dat niet goed schoonmaakt wat erin wordt getypt, waardoor mogelijk de hele WordPress-database inclusief gebruikersgegevens wordt blootgesteld of gewijzigd.
De oplossing is grotendeels dezelfde als voor verouderde plugins: SQL-injectiekwetsbaarheden worden bijna altijd gevonden in specifieke pluginversies en snel gepatcht zodra ze zijn gemeld, dus up-to-date blijven met updates sluit de overgrote meerderheid van deze gaten voordat ze ooit op een specifieke site worden misbruikt.
Cross-Site Scripting (XSS)
XSS stelt een aanvaller in staat om via een niet-opgeschoond invoerveld kwaadaardige JavaScript in een pagina te injecteren, die vervolgens draait in de browser van iedereen die die pagina bezoekt — mogelijk met diefstal van admin-sessiecookies of doorverwijzing van bezoekers naar een kwaadaardige site tot gevolg. Reactievelden, contactformulieren en plugin-instellingen die gebruikersinvoer niet escapen, zijn de meest voorkomende toegangspunten.
De oplossing: dezelfde updatediscipline is van toepassing, aangezien XSS-kwetsbaarheden doorgaans pluginspecifiek zijn en snel worden gepatcht; een web application firewall (inbegrepen in veel beveiligingsplugins) voegt een laag toe die bekende XSS-injectiepatronen kan blokkeren, zelfs voordat een patch wordt toegepast.
XML-RPC-misbruik
WordPress' XML-RPC-interface, oorspronkelijk gebouwd voor tools voor extern publiceren, is een veelvoorkomende vector geworden voor twee specifieke aanvallen: brute-force-inlogpogingen die via de pingback-methode worden geleid om normale ratelimiting te omzeilen, en het gebruik van het XML-RPC-eindpunt van een site als versterker bij DDoS-aanvallen tegen andere doelwitten.
De oplossing: schakel XML-RPC volledig uit, tenzij de site actief afhankelijk is van een plugin (meestal Jetpack) of een app die dit vereist — voor de meeste sites sluit dit een aanvalsoppervlak zonder functioneel nadeel.
Onveilige bestandsrechten
Te ruime bestands- en mapmachtigingen — vaak op hun standaardwaarde gelaten of tijdens het oplossen van problemen versoepeld en nooit teruggezet — stellen een aanvaller die enige voet aan de grond krijgt op de server in staat om kernbestanden te wijzigen, een achterdeur te plaatsen, of gevoelige configuratiegegevens zoals databasegegevens in wp-config.php te lezen.
De oplossing: WordPress' eigen documentatie beveelt 644 voor bestanden en 755 voor mappen aan als een veilige basis, waarbij wp-config.php idealiter nog verder afgesloten wordt omdat het direct databasegegevens bevat.
Snelle referentietabel
| Kwetsbaarheid | Veelvoorkomend toegangspunt | Primaire oplossing |
|---|---|---|
| Verouderde plugins/thema's | Bekende, bekendgemaakte CVE's | Auto-updates inschakelen, onderhouden plugins verwijderen |
| Zwakke admin-inloggegevens | Brute-force op wp-login.php | Sterke wachtwoorden, 2FA, beperking inlogpogingen |
| SQL-injectie | Niet-opgeschoonde plugin-invoervelden | Plugins up-to-date houden met gepatchte versies |
| Cross-site scripting (XSS) | Reactie-/contactformuliervelden | Plugins bijwerken, web application firewall gebruiken |
| XML-RPC-misbruik | Pingback-brute-force, DDoS-relay | XML-RPC uitschakelen indien niet actief nodig |
| Onveilige bestandsrechten | Serverconfiguratiefout | 644 voor bestanden, 755 voor mappen |
Een praktische hardeningschecklist
- Werk alles bij volgens een schema, niet reactief — WordPress-kern, elke plugin en het actieve thema, idealiter met automatische updates ingeschakeld voor kleine releases.
- Verwijder ongebruikte plugins en thema's volledig, niet alleen deactiveren — een inactieve maar geïnstalleerde plugin met een bekende kwetsbaarheid kan in sommige aanvalsketens nog steeds worden misbruikt.
- Dwing tweefactorauthenticatie af voor elk account met publicatie- of adminrechten, niet alleen het primaire admin-account.
- Schakel XML-RPC uit, tenzij een specifieke, actief gebruikte integratie het vereist.
- Test beveiligingswijzigingen eerst op een staging-kopie, aangezien hardeningsstappen zoals wijzigingen in machtigingen of het uitschakelen van functies af en toe een plugin kunnen breken die daarvan afhankelijk is.
Op de hoogte blijven van nieuwe kwetsbaarheden
Kwetsbaarhedendatabases zoals WPScan en Patchstack volgen nieuw bekendgemaakte WordPress-plugin- en themakwetsbaarheden zodra ze worden gepubliceerd, en veel beveiligingsplugins putten uit dezelfde bronnen om site-eigenaren te waarschuwen wanneer een geïnstalleerde plugin een bekend probleem heeft. Je abonneren op een van deze feeds, in plaats van te wachten tot je achteraf een probleem opmerkt, is het verschil tussen patchen binnen uren na bekendmaking en patchen nadat een geautomatiseerde scanner het gat al heeft gevonden.
Veelgemaakte fouten die tot een inbraak leiden
- Aannemen dat een beveiligingsplugin alleen voldoende is, terwijl deze een bekende kwetsbaarheid in verouderde, nog op de site draaiende software niet met terugwerkende kracht kan patchen.
- Ongebruikte plugins deactiveren in plaats van verwijderen, waardoor bekend kwetsbare code op de server aanwezig blijft, ook al draait deze niet actief.
- Hetzelfde admin-wachtwoord hergebruiken op meerdere klantsites, waardoor één gelekt inloggegeven verandert in een inbraak op meerdere sites.
- Het harden van bestandsrechten negeren omdat het wordt gezien als een eenmalige installatietaak in plaats van een terugkerend onderhoudspunt.
- Herstellen vanaf een oude back-up zonder te controleren of deze ook een inmiddels gepatchte kwetsbaarheid herstelt, waardoor een eerdere fix ongemerkt ongedaan wordt gemaakt.
Tot slot
Kortom, de kwetsbaarheden die WordPress-sites daadwerkelijk in gevaar brengen vormen een goed gedocumenteerde, voorspelbare set — vooral verouderde plugins en thema's, plus zwakke inloggegevens, SQL-injectie, XSS, XML-RPC-misbruik en losse bestandsrechten — elk met een specifieke, bekende oplossing in plaats van een vage oproep om "veiliger te worden". Consistente updates en een handvol concrete hardeningsstappen sluiten de overweldigende meerderheid van reële aanvallen, precies het scan- en documentatiewerk waarvoor onze Erdo CRA Compliance-plugin is gebouwd, naast bredere EU-nalevingsvereisten.