HACK

Beveiliging · Eerste hulp

WordPress site gehackt:
eerste hulp

Je site vertoont verdacht gedrag of is volledig overgenomen? Raak niet in paniek. Volg deze stap-voor-stap aanpak om de schade te beperken, de site te herstellen en een herhaling te voorkomen.

Door Kristof Loyens, 14 mei 2026 · bijgewerkt 9 oktober 2026 · 9 min leestijd

// Herken je een van deze signalen?

Je site wordt omgeleid naar een vreemde URL

Google toont "This site may be hacked"

Onbekende gebruikers of beheerdersaccounts

Plots veel spammail vanuit je domein

Vreemde bestanden of code in je thema

Je hostingprovider schakelt de site uit

Een gehackte WordPress-site is nachtmerriescenario voor elke ondernemer. Maar het overkomt meer mensen dan je denkt, WordPress drijft meer dan 40% van alle websites wereldwijd, wat het een populair doelwit maakt voor geautomatiseerde aanvallen. Hoe sneller je handelt, hoe minder schade.

Stap 1: Bevestig de hack

Soms lijkt een site gehackt maar is er een andere oorzaak (plugin-conflict, serverstoring). Bevestig eerst het probleem via twee onafhankelijke bronnen:

Surf vanuit een ander netwerk: gebruik een mobiele dataverbinding of een VPN. Sommige redirects activeren zich alleen voor nieuwe bezoekers, niet voor jou als beheerder.
Google Safe Browsing: controleer je domein via de transparantierapport-tool van Google. Een rode vlag daar betekent dat Google actief bezoekers waarschuwt.
Vraag je hostingprovider: zij zien vaak als eersten wanneer er kwaadaardige activiteit is op serverniveau.
Scan met een online malware-checker: tools als Sucuri SiteCheck geven snel een extern oordeel.

Let op: log pas in op je WordPress-dashboard nadat je zeker bent dat je eigen computer niet gecompromitteerd is. Gebruik bij voorkeur een schoon toestel of een incognitovenster.

Stap 2: Zet de site tijdelijk offline

Zo snel mogelijk offline gaan beperkt de schade voor je bezoekers en voorkomt dat Google je site massaal afstraft. Je hebt hiervoor twee opties:

Via je hostingpanel: de meeste providers (cPanel, Plesk, Kinsta, SiteGround…) hebben een knop om de site tijdelijk te deactiveren of in onderhoudsmodus te zetten zonder dat je toegang tot WordPress nodig heeft.
Via een onderhoudsmodus-plugin via FTP: upload een eenvoudig index.php-bestand met een "tijdelijk offline" melding naar de root van je site.

Stap 3: Wijzig alle wachtwoorden

Doe dit voordat je ook maar één andere stap zet, anders kunnen aanvallers terugkeren terwijl je bezig bent te herstellen.

// Wachtwoorden te wijzigen, in deze volgorde

WordPress-beheerdersaccount(s)	Sterkst mogelijke wachtwoord, minimaal 20 tekens
Database (MySQL)	In cPanel → MySQL Databases, ook bijwerken in `wp-config.php`
FTP / SFTP	Via je hostingpanel; verwijder onbekende FTP-accounts
Hostingpanel (cPanel / Plesk)	Aparte loginpagina van je provider
E-mailaccounts gekoppeld aan het domein	Aanvallers misbruiken deze voor spam of phishing

Vervang ook de secret keys (salts) in wp-config.php

Een nieuw wachtwoord alleen is niet genoeg. WordPress houdt ingelogde sessies bij met cookies die ondertekend zijn met de secret keys in wp-config.php. Heeft de aanvaller nog een geldige sessiecookie, dan blijft hij ingelogd, ook na je wachtwoordwijziging. Nieuwe keys maken alle bestaande sessies ongeldig.

Genereer een nieuwe set via de officiële generator: api.wordpress.org/secret-key/1.1/salt/.
Vervang in wp-config.php de acht regels van AUTH_KEY tot en met NONCE_SALT door de nieuwe set.
Met WP-CLI kan het in één commando: wp config shuffle-salts.

Iedereen, jij inbegrepen, wordt daarna uitgelogd. Dat is precies de bedoeling.

Stap 4: Maak een forensische back-up

Dit klinkt contra-intuïtief, back-up maken van een gehackte site?, maar het is cruciaal. Je hebt de besmette versie nodig om achteraf te achterhalen hoe de aanval plaatsvond en welke bestanden gewijzigd zijn.

Download alle bestanden via FTP/SFTP naar een offline locatie (niet op de server).
Exporteer een dump van de database via phpMyAdmin of de CLI.
Bewaar deze back-up apart van je gewone back-ups, label hem duidelijk als "gehackt – forensisch".

Stap 5: Herstel vanaf een schone back-up

Als je recente, niet-besmette back-ups heeft, is dit de snelste weg naar herstel. De meeste hostingproviders bewaren automatische dagelijkse back-ups, vraag ernaar als je ze niet vindt.

Controleer altijd de datum. Een back-up van vóór de hack is nuttig; een back-up van na de hack bevat mogelijk al de malware. Vergelijk bestandsdatums en -groottes als je twijfelt.

Na het terugzetten van de back-up: update onmiddellijk alle plugins, thema's en de WordPress-core. De kwetsbaarheid waardoor de aanvaller binnenkwam, bestaat anders nog steeds.

Stap 6: Handmatig malware opsporen (als er geen back-up is)

Geen bruikbare back-up? Dan begint het handwerk. Dit zijn de plaatsen waar aanvallers het vaakst kwaadaardige code verbergen:

wp-content/themes/[uw-thema]/: met name functions.php, header.php en footer.php worden aangepast.
wp-content/uploads/: PHP-bestanden horen hier nooit thuis. Elk .php-bestand in de uploadsmap is verdacht.
wp-config.php: check op vreemde code boven of onder de standaard inhoud.
.htaccess: aanvallers voegen hier redirect-regels aan toe die onzichtbaar zijn voor de beheerder maar actief zijn voor gewone bezoekers.
Databasetabel wp_options: de velden siteurl en home worden soms gewijzigd naar een andere URL.

// Handige grep-commando voor SSH

grep -rl "eval(base64_decode" /var/www/html/wp-content/

Zoekt recursief naar geobfusceerde PHP-injectie, een klassieke handtekening van malware.

Sneller met WP-CLI

Heb je SSH-toegang, dan vergelijkt WP-CLI je bestanden in enkele seconden met de officiële broncode. Elk bestand dat afwijkt of er niet hoort, verschijnt in de uitvoer.

// WP-CLI controles

wp core verify-checksums wp plugin verify-checksums --all wp user list --role=administrator

Controleert de WordPress-core, alle plugins uit de officiële plugin-directory en toont elke beheerder. Premium plugins kan WP-CLI niet vergelijken: die vervang je best door een verse download van de leverancier.

Plugins als Wordfence of MalCare doen dit scanwerk geautomatiseerd en markeren gewijzigde bestanden ten opzichte van de officiële WordPress-broncode.

Stap 7: Verwijder onbekende gebruikers en herstel bestandspermissies

Ga naar Gebruikers → Alle gebruikers in WordPress en verwijder elke beheerder die je niet herkent. Controleer ook je hostingpanel op FTP-accounts die je niet zelf aangemaakt heeft.

Stel daarna de bestandspermissies correct in, aanvallers verhogen deze soms om schrijftoegang te krijgen:

Bestanden: 644
Mappen: 755
wp-config.php: 600 (alleen lezen door de eigenaar)

Stap 8: Beveilig de site en kom terug online

Herstel zonder extra beveiliging is een herhaling van zetten. Neem deze maatregelen voordat je de site terug online zet:

Installeer een beveiligingsplugin: Wordfence (gratis) of iThemes Security blokkeren brute-force aanvallen en scannen op malware.
Activeer tweefactorauthenticatie: voor alle beheerdersaccounts. Dit maakt gestolen wachtwoorden nutteloos.
Verberg de inlogpagina: de standaard URL /wp-admin is wereldkundig; gebruik een plugin om hem te hernoemen.
Beperk inlogpogingen: na 5 mislukte pogingen tijdelijk blokkeren volstaat om 99% van de bots te stoppen.
Schakel XML-RPC uit: tenzij je het actief gebruikt, is dit een veelgebruikt aanvalsvector dat je beter sluit.
Zet automatische updates aan: voor WordPress-core en beveiligingsupdates van plugins.
Kies veilige hosting: een goede host met dagelijkse back-ups, monitoring en serverbeveiliging vangt veel aanvallen op vóór ze je bereiken; zie onze hosting.

Oorzaken en preventie, overzicht

Aanvalsvector	Hoe het gebeurt	Preventie
Verouderde plugins of thema's	Bekende kwetsbaarheden worden geautomatiseerd uitgebuit	Automatische updates aanzetten
Zwak wachtwoord	Brute-force of credential stuffing	Sterk wachtwoord + 2FA
Geïnfecteerde nulled plugins	Gratis illegale versies bevatten backdoors	Nooit nulled software gebruiken
Gedeelde hosting zonder isolatie	Andere sites op de server besmetten de uwe	VPS of geïsoleerde hosting kiezen
Zwakke FTP-credentials	Aanvallers loggen in en uploaden malware	SFTP met sleutelauthenticatie
Geen back-ups	Geen hersteloptie na aanval	Dagelijkse offsite back-ups

Een hack is niet alleen een technisch probleem. Bewaart je site persoonsgegevens (klantaccounts, bestellingen, contactformulieren, nieuwsbriefinschrijvingen) en kan de aanvaller daar bij geweest zijn, dan spreekt de GDPR van een datalek. Dan gelden deze regels:

Melden binnen 72 uur bij de Gegevensbeschermingsautoriteit (GBA), gerekend vanaf het moment dat je het lek ontdekt. Dat gaat via een online formulier. Heb je nog niet alle details, meld dan eerst wat je weet en vul later aan.
Geen melding nodig als het lek waarschijnlijk geen risico inhoudt voor de betrokkenen, bijvoorbeeld als er enkel publieke informatie op de server stond. Noteer die afweging wel.
Betrokkenen verwittigen als het risico hoog is, bijvoorbeeld bij gelekte wachtwoorden, adresgegevens of betaalinformatie. Zij moeten dan zelf hun wachtwoorden kunnen wijzigen of alert zijn voor phishing.
Documenteer alles in een intern register van datalekken: wat er gebeurde, welke gegevens betrokken waren en welke maatregelen je nam. Ook lekken die je niet meldt, horen in dat register.

Je forensische back-up uit stap 4 is hier goud waard: daarmee kan je achteraf aantonen welke gegevens wel en niet geraakt zijn.

Wanneer vraag je hulp?

Niet iedereen heeft de technische kennis of tijd om dit zelf af te handelen, en dat is volkomen begrijpelijk. Schakel een professional in als:

Je geen bruikbare back-up kunt vinden.
De malware terugkeert na verwijdering (backdoor nog aanwezig).
Google je site heeft gemarkeerd en de verzoek tot herziening moet ingediend worden.
Je niet zeker bent of de site volledig schoon is voor bezoekers terug toe te laten.
Er persoonlijke data van klanten mogelijk gelekt is, dan speelt ook de GDPR-meldplicht.

Veelgestelde vragen

Hoe weet ik of mijn WordPress-site gehackt is?

Typische signalen zijn redirects naar vreemde sites, een waarschuwing van Google ('This site may be hacked'), onbekende beheerdersaccounts, spam die vanuit je domein vertrekt en onbekende PHP-bestanden in je thema- of uploadsmap. Bevestig het altijd via een tweede bron: surf vanaf een ander netwerk, check Google Safe Browsing of laat een externe malwarescan lopen.

Kan ik een gehackte WordPress-site zelf herstellen?

Ja, als je toegang hebt tot je hostingpanel, FTP en de database, en je een schone back-up van vóór de hack hebt. Zonder bruikbare back-up, of als de malware na verwijdering terugkeert, zit er meestal nog een backdoor op de server en schakel je beter een professional in.

Lost een back-up terugzetten een hack op?

Niet volledig. Een schone back-up verwijdert de malware, maar niet het lek waarlangs de aanvaller binnenkwam. Wijzig na het terugzetten alle wachtwoorden, vervang de secret keys in wp-config.php en update meteen WordPress, plugins en thema's, anders ben je binnen enkele dagen opnieuw gehackt.

Hoe lang duurt het om een gehackte WordPress-site te herstellen?

Met een schone back-up ben je vaak binnen een paar uur terug online. Zonder back-up, met handmatige opschoning, reken je eerder op een tot enkele werkdagen. Staat je site op de zwarte lijst van Google, dan duurt de beoordeling van je herzieningsverzoek doorgaans nog enkele dagen extra.

Moet ik een gehackte website melden bij de Gegevensbeschermingsautoriteit?

Als er persoonsgegevens mogelijk in handen van de aanvaller zijn gekomen (klantaccounts, bestellingen, formulierinzendingen), is dat een datalek. Onder de GDPR meld je dat binnen 72 uur na ontdekking bij de Gegevensbeschermingsautoriteit (GBA), tenzij het lek waarschijnlijk geen risico inhoudt voor de betrokkenen. Bij een hoog risico verwittig je ook de betrokken personen zelf.

Wat kost het herstel van een gehackte WordPress-site?

Dat hangt vooral af van de beschikbaarheid van een schone back-up en hoe diep de malware zit. Een herstel vanaf back-up met beveiligingsronde is een beperkte klus; een volledige handmatige opschoning met analyse van de aanval vraagt meer tijd. Neem contact op met Quantum Leap voor een concrete prijs.

Quantum Leap to the rescue!

We kwamen onlangs tussen bij een lokaal bedrijf waarvan de WordPress-site stiekem bezoekers doorstuurde naar een casino-site, en dat al weken. De eigenaar merkte het pas toen een klant hem erop wees. We herstelden de site vanuit een clean back-up, verwijderden de backdoor die de aanvaller achtergelaten had, en zetten een monitoringsysteem op dat abnormale bestandswijzigingen meteen signaleert. Sindsdien: geen incidenten meer.

WordPress-site gehackt of wil je een aanval voorkomen? Neem contact met ons op, we helpen snel en discreet.

Lees ook: WordPress inloggen lukt niet · WordPress kritieke fout oplossen · WordPress update mislukt? Oplossen · WordPress website sneller maken: case

Kristof Loyens

Eigenaar Quantum Leap. WordPress fan. Designer en Developer. Loves The interwebz, snowboarding, graffiti en luide muziek. Maakt een geweldige pompoensoep.

← Terug naar alle blogberichten