“Waarom mijn site? Ik ben toch helemaal niet interessant?” Dat is meestal de eerste vraag die ik krijg na een hack. WordPress-websites worden vooral gehackt via verouderde plugins en thema’s, zwakke of hergebruikte wachtwoorden, nulled thema’s, onveilige hosting, ontbrekende tweestapsverificatie, verlopen PHP-versies en niet-verwijderde oude installaties op hetzelfde account. Hieronder lees je per oorzaak hoe die werkt, hoe je herkent dat het jouw lek was en wat je eraan doet.
Hoe een WordPress-hack meestal werkt
Een WordPress-hack begint bijna altijd met een geautomatiseerde scan, niet met iemand die jouw bedrijf heeft uitgekozen. Bots lopen het hele internet af op zoek naar plugins met een bekend lek en inlogpagina’s die een zwak wachtwoord accepteren. Vinden ze er een, dan plaatst de aanvaller malware of een achterdeur (backdoor), en vanaf dat moment wordt je site gebruikt voor spam, doorverwijzingen of het stelen van gegevens. Vergelijk het met een inbreker die niet één huis uitkiest, maar de hele straat langsloopt op zoek naar een open raam. Je site is geen doelwit, het open raam is het doelwit.
Dat betekent ook dat WordPress zelf niet het probleem is. De core krijgt snel beveiligingsupdates, en het risico zit bijna altijd in wat eromheen staat. De meeste hacks die ik zie, hadden met een update en tweestapsverificatie voorkomen kunnen worden. Dat klinkt misschien confronterend, maar het betekent vooral dat je de grootste lekken zelf kunt dichten.
Oorzaak 1 en 2: verouderde plugins en zwakke wachtwoorden
Verouderde plugins en thema’s zijn de meest voorkomende ingang voor een WordPress-hack, omdat een update meestal een gepubliceerde kwetsbaarheid dicht en bots na publicatie gericht naar dat lek gaan zoeken. Tussen het bekend worden van een lek en de eerste aanvallen zit vaak weinig tijd, dus wacht niet weken met beveiligingsupdates. Hetzelfde geldt voor de WordPress-core, laat de automatische beveiligingsupdates daarvan gewoon aan staan. Extra riskant zijn plugins die helemaal geen updates meer krijgen omdat de maker ermee is gestopt. Een enkele keer gaat het andersom en komt een achterdeur juist mee met een update, omdat een plugin is overgenomen of de maker zelf is gehackt. Wil je hier grip op, lees dan hoe je verouderde plugins opruimen aanpakt en hoe je kwetsbaarheden in plugins monitoren kunt. Je kunt de updates ook uitbesteden via WordPress onderhoud.
De tweede oorzaak zit in wachtwoorden, en daar spelen twee verschillende dingen. Een zwak wachtwoord wordt geraden met brute force, een bot die duizenden combinaties achter elkaar probeert. Een hergebruikt wachtwoord hoeft niet eens geraden te worden, want dat komt uit een datalek bij een andere dienst en wordt gewoon uitgeprobeerd op jouw site (credential stuffing). Wachtwoorden lekken ook via phishing of malware op je eigen laptop, zoals nepmails die om je cPanel-gegevens vragen. Je herkent dit aan veel mislukte inlogpogingen of aan beheerders met technisch ogende namen die je niet kent. Het NCSC waarschuwde op 18 juni 2026 bijvoorbeeld voor nepaccounts die beginnen met wp-maintenance- of wp-backup-. Gebruik daarom een wachtwoordmanager en check je e-mailadres op haveibeenpwned.com.
Oorzaak 3 tot en met 5: nulled thema’s, onveilige hosting en geen 2FA
Nulled thema’s en plugins zijn gekraakte versies van betaalde software, en daar zit vaak al een achterdeur in voordat je ze installeert. Ze krijgen bovendien nooit updates. Heb je ooit een premium thema gratis gedownload van een onbekende site, verwijder het dan en koop de officiële versie. Meer daarover in waarom je nulled thema’s nooit gebruikt.
Onveilige hosting is de vierde oorzaak. Denk aan servers zonder isolatie tussen accounts, waardoor een besmetting bij een andere klant kan overspringen, aan het ontbreken van een serverfirewall of aan verouderde serversoftware. Zie je meerdere sites op dezelfde server tegelijk besmet raken, dan is dat een sterke aanwijzing. Ik wil hier wel eerlijk zijn. Goede hosting schermt accounts van elkaar af, maar houdt een lek in je eigen plugin niet altijd tegen. Kies daarom hosting met een firewall op serverniveau en standaard malwarescans, zoals managed WordPress hosting, en houd zelf je plugins bij.
De vijfde oorzaak is het ontbreken van tweestapsverificatie (2FA). Zonder die extra code is één gelekt wachtwoord genoeg om binnen te komen, en dat geldt ook voor je hostingpaneel en het e-mailadres van de beheerder. Hoe je dat instelt, lees je in de WordPress-login beveiligen.
Oorzaak 6 en 7: een verlopen PHP-versie en oude installaties
Een verlopen PHP-versie (end of life) krijgt geen beveiligingsupdates meer, en dat maakt je server kwetsbaar los van wat er in WordPress zelf gebeurt. Daar komt nog iets bij. Een oude PHP-versie houdt vaak ook oude plugins in leven, omdat nieuwe versies van die plugins er niet meer op draaien. Je huidige versie zie je in WordPress onder Extra > Sitediagnose, en op php.net kun je nagaan of die versie nog wordt ondersteund. Op onze shared hosting kies je zelf een versie tussen 7.4 en 8.5 via cPanel > Select PHP Version. Hoe je veilig overstapt, staat in PHP-versie updaten.
De zevende oorzaak wordt in mijn ervaring het vaakst over het hoofd gezien. Het gaat om oude installaties op hetzelfde hostingaccount, zoals een testsite, een oude WordPress in een submap of een vergeten subdomein. Niemand werkt die nog bij, maar ze delen wel het account en de bestanden met je live site. Raakt zo’n oude installatie besmet, dan springt de malware over. Herkenbaar is het patroon waarbij je live site schoon is en de malware toch steeds terugkomt. Maak een back-up, loop alle installaties op je account na en verwijder wat je niet meer gebruikt.
Zo vind je achteraf via welk lek je site is gehackt
Wil je na een hack weten welke van deze zeven oorzaken het was, dan begin je bij de sporen die de aanvaller heeft achtergelaten. Dit is de volgorde die ik zelf aanhoud.
- Bekijk de toegangslogs rond het moment van besmetting. Op onze shared hosting staan die in cPanel onder Raw Access en elke nacht als .gz-bestand in de map
/logs. - Sorteer de bestanden op laatst gewijzigd en zoek wijzigingen die je zelf niet hebt gedaan.
- Vergelijk je pluginlijst met de bekende kwetsbaarheden in WPScan of Patchstack.
- Controleer de gebruikerslijst op onbekende beheerders en hun laatste inlog.
Is je site nu besmet, begin dan bij WordPress website gehackt, wat nu? en lees daarna hoe je malware verwijderen uit WordPress aanpakt.
Bij Surver vangen we een deel van deze oorzaken al op serverniveau af. Op alle shared hostingpakketten houden een ModSecurity-firewall en Bot Blocker veel aanvallen tegen, en Imunify scant bij elke bestandswijziging en elke nacht de hele server. Na meer dan tien mislukte inlogpogingen, ook op wp-admin, krijgt het IP-adres een captcha-pagina, wat brute force flink afremt. Je plugins en wachtwoorden blijven wel jouw verantwoordelijkheid. Ben je toch gehackt, dan zoeken we bij WordPress gehackt de oorzaak en dichten we die. Alles over preventie staat in WordPress-beveiliging: de complete gids.
Veelgestelde vragen
Kan mijn site gehackt worden via een andere site op dezelfde server?
Bij slecht geïsoleerde gedeelde hosting wel. Bij Surver is elk shared hostingaccount afgeschermd met CloudLinux en CageFS, zodat een besmetting bij een ander account niet overspringt. Sites binnen je eigen account zijn niet van elkaar gescheiden, en daar gaat oorzaak 7 over.
Kan een plugin-update zelf een hack veroorzaken?
Dat gebeurt zelden, maar het kan als een plugin wordt overgenomen of de maker zelf wordt gehackt. Installeer daarom alleen plugins uit een betrouwbare bron en volg de beveiligingsmeldingen van WPScan, Patchstack of het NCSC.
Hoe voorkom ik dat het opnieuw gebeurt?
Vind eerst de oorzaak en dicht die, want anders is de volgende hack een kwestie van tijd. Regel daarna vaste updates, tweestapsverificatie voor alle beheerders en een firewall.
