WordPress gehackt: een malware-redirect herkennen en opruimen

Je bezoekers worden doorgestuurd naar een spampagina, maar zelf zie je niets. Hoe moderne WordPress redirect-malware zich verstopt voor beheerders, waar hij écht zit en hoe je een site opruimt zodat hij schoon blijft.

Een bezoeker stuurt je een screenshot. Je site stuurt door naar een pharma-pagina, een nep-Amazon-login of een "u heeft gewonnen"-scam. Je opent je eigen site in Chrome: niks aan de hand. Je bekijkt hem op je telefoon terwijl je ingelogd bent: nog steeds niks. In incognito wél, meteen bij de eerste klik. Het meest onaangename aan een moderne WordPress-hack is niet de hack zelf. Het is dat de site er voor jóú prima uitziet terwijl hij je bezoekers aan het bestelen is.

Dit artikel is het opruimplan voor precies dat scenario. Het behandelt hoe je de infectie bevestigt, waar redirect-malware zich in 2026 écht verstopt (spoiler: niet waar de meeste artikelen kijken), de concrete stappen om bestanden en database schoon te maken, en hoe je zorgt dat de site daarna ook schoon blijft. Zit je dit om 23:00 op een vrijdagavond te lezen met een suspend-mail van je host open in een ander tabblad? Spring dan meteen door naar de infectie bevestigen en lees de context-secties later.

Waarom je de redirect zelf niet ziet

Vrijwel alle moderne WordPress redirect-malware checkt is_user_logged_in() of kijkt naar de wordpress_logged_in_* cookie voordat de redirect afgaat. Zit jij ingelogd in wp-admin in dezelfde browser, dan geeft de malware gewoon de normale pagina terug en lijkt je bezoek identiek aan een schone site. De mu-plugins backdoor-campagne die Sucuri in maart 2025 documenteerde doet dit letterlijk zo in zijn redirect.php: conditionele redirect naar updatesnow[.]net, met expliciete uitzonderingen voor ingelogde gebruikers en bots.

Dezelfde check beschermt de SEO-schade van de aanvaller. De regex blokkeert Googlebot en Bingbot, zodat de kwaadaardige content niet in Google's crawl cache terechtkomt en de infectie weken kan blijven hangen voordat Google Search Console aan de bel trekt. Je ziet de redirect alleen vanuit een browser die:

niet is ingelogd in WordPress,
geen WordPress admin-cookies heeft staan,
een normale consumenten-User-Agent gebruikt.

De betrouwbare test is een incognito-venster op een telefoon over mobiel internet, op een domein waar je vanaf die browser nooit eerder hebt ingelogd. Als de redirect intermitterend is, zetten sommige families ook een sessiecookie (de malware die Sucuri in januari 2025 tracked zet een cookie MkQQ) zodat een terugkerende bezoeker niet twee keer achter elkaar wordt doorgestuurd. Eén incognito-hit, één redirect, is genoeg bewijs.

Signalen dat je WordPress-site gehackt is

Een compromittering kondigt zichzelf zelden aan met één glashelder symptoom. De meest voorkomende signalen, ongeveer op volgorde van hoe mensen ze opmerken:

Bezoekers melden redirects naar onbekende domeinen. Pharma, gokken, streamingscams, nep-antivirus of nep-browserupdate-pagina's. De bron is altijd jouw URL, het doel niet.
Google Search Console toont een "Beveiligingsproblemen"-waarschuwing. Ga in je Search Console-property naar Beveiliging & handmatige acties > Beveiligingsproblemen. Google rubriceert deze als "Gehackte content", "Malware en ongewenste software" of "Social engineering". Google's helppagina over gehackte content lijst de specifieke categorieën op.
Chrome toont een interstitial voor bezoekers. "Site vooruit misleidend" of "De site vooruit bevat malware" komt van Google Safe Browsing, dat dezelfde feeds krijgt als Search Console. Die interstitial slaat je click-through rate in één nacht richting nul.
Je host stuurt een suspend-mail. Shared hosts scannen hun klanten met server-side tools en zetten het account dan in quarantaine of mailen je met een deadline. Managed WordPress-hosts zijn meestal nog sneller.
In wp-admin staan beheerders die je zelf niet hebt aangemaakt. Namen zoals wpadmin2, license_admin2 of willekeurige hex-strings zijn een rode vlag. De nep security-plugin-campagne van januari 2025 (gedocumenteerd door The Hacker News) maakt accounts aan die via hook-injectie juist uit de gebruikerslijst worden gefilterd. De afwezigheid van een onbekend account in de UI is dus geen bewijs dat er geen is.
Nieuwe posts of pagina's die je niet zelf hebt geschreven, vaak in een taal die je niet spreekt. Meestal spam-SEO voor pharma of gokken, soms als concept verstopt, soms gepubliceerd en verborgen met custom CSS.
Zoekverkeer stort in. Een daling van 40 tot 90 procent in organisch verkeer binnen 48 uur is de SEO-handtekening van óf een Safe Browsing-waarschuwing óf een handmatige penalty.
Onverklaarbare .php-bestanden in wp-content/uploads/. Die horen daar niet, nooit.

Eén van deze signalen is verdacht. Twee of meer samen betekent dat de rest van dit artikel op jou van toepassing is.

De misvattingen die sites ziek houden

Voordat de opruimstappen beginnen, drie overtuigingen die site-eigenaren dagen van hun leven kosten en meestal ook nog een vieze site opleveren.

"Het kwaadaardige bestand verwijderen is genoeg." Dat is het niet. Moderne reinfector-malware, gedocumenteerd door Sucuri in november 2024, verspreidt zijn payload over elk actief plugin-bestand, slaat een tweede kopie op in wp_options onder een hex-gecodeerde option-naam, zet een derde in de wpcode_snippets-optie en past wp-cron.php aan zodat een scheduled event het verwijderde bestand binnen minuten opnieuw installeert. Sucuri zegt het zonder omhaal: "If the site isn't fully cleaned, even small remnants of the malware can cause it to quickly reinfect everything." Eén overgeslagen vector is er één te veel.

"Een security scan-plugin vindt alle malware." Dat doet hij niet, en het gat is groter dan mensen verwachten. Remote scanners zoals Sucuri's SiteCheck kunnen server-side bestanden helemaal niet zien; ze zien alleen wat een publieke bezoeker ziet. Server-side plugin-scanners zoals de gratis variant van Wordfence pakken grofweg 70 tot 80 procent van de bekende malware-signatures, maar missen malware die in de database zit. Wordfence zelf heeft pas in Wordfence CLI 5.0.1 (november 2024) database-scanning toegevoegd, wat bevestigt dat dit gat er jarenlang was. Nog erger: een Sucuri-rapport uit juli 2024 documenteerde malware die Wordfence actief uitschakelt door de plugin-map te hernoemen naar wordfence1, om vervolgens een nep JavaScript-overlay te injecteren waardoor de uitgeschakelde plugin in het dashboard nog steeds actief lijkt. Een schone scan is bewijsmateriaal, geen sluitend bewijs.

"WordPress opnieuw installeren lost het op." Een WordPress-herinstallatie vervangt /wp-admin/ en /wp-includes/. Hij raakt /wp-content/ (waar je plugins, thema's, uploads en mu-plugins leven) niet aan, hij raakt de database niet aan en hij raakt wp-config.php niet aan. Alle vier zijn primaire persistentie-vectoren. Op de WordPress.org support-forums staat een actieve thread met precies deze titel: malware recreates itself even after deleting and reinstalling WordPress, met meerdere gedocumenteerde gevallen van herinfectie binnen uren na een volledige core-herinstallatie.

Houd deze drie in je hoofd terwijl je werkt. Elke stap hieronder bestaat omdat minstens één van die drie verkeerd is.

De infectie bevestigen

Voordat je begint met opruimen, heb je drie dingen nodig: een duidelijke lijst met symptomen, een verse forensische backup en bewijs dat Google en de security-wereld al zien wat jij ziet.

Reproduceer de redirect in een schone omgeving. Open je site in een incognito-venster op een apparaat dat nog nooit in wp-admin heeft ingelogd. Gebruik mobiel internet, geen kantoor-wifi, voor het geval de aanvaller geo-based filtert. Noteer de bestemmings-URL en het exacte pad op jouw site dat de redirect triggert. Screenshot het.
Maak een forensische backup van de huidige (geïnfecteerde) staat. Dit is niet de backup waar je van terugzet; dit is de kopie waarmee een incident responder later kan reconstrueren wat er gebeurd is. Gebruik de snapshot van je host, wp db export en een tar -czf van de hele WordPress-boom. Zet deze kopie buiten je host. Sla deze stap niet over. In paniek is de neiging om alles weg te gooien en opnieuw te beginnen, en dan ben je meteen het enige bewijsmateriaal kwijt.
Draai Sucuri SiteCheck op je URL. Ga naar sitecheck.sucuri.net en laat je domein scannen. SiteCheck is een remote scanner en vindt alleen publiek zichtbare malware en blocklist-hits, maar "publiek zichtbaar" is precies wat telt bij een redirect-campagne. Noteer elke URL die hij flag't.
Check Google Search Console > Beveiligingsproblemen. Als Google je site heeft gemarkeerd, lijst het rapport de aangetaste URL's op en de categorie van de hack. De volledige flow staat in Google's hulppagina over gehackte content. Screenshot alles.
Laat VirusTotal een URL-scan doen. Die checkt je domein tegen ruwweg 70 blocklists van verschillende vendors, zodat je weet hoe breed de schade is en welke partijen je na het opruimen nog moet aanschrijven.
Haal je hosting access logs van de laatste 30 dagen op. Zoek naar POST-requests op wp-login.php of xmlrpc.php die 200 retourneerden (succesvolle logins) vanuit IP's die niet van jou zijn. Zoek naar POST-requests op wp-admin/admin-ajax.php met action-parameters die je niet herkent. Noteer de tijdstempels; die vormen de tijdlijn voor de rest van het onderzoek.

Het doel van deze fase is een opgeschreven lijst met wat je zeker weet. Zie je niks in incognito en niks in Search Console, maar melden je bezoekers toch redirects? Dan is de meest waarschijnlijke oorzaak een besmet advertentietag of een compromised third-party script, en geen WordPress-hack. Onderzoek dat pad eerst.

Waar redirect-malware zich écht verstopt

De meeste opruimgidsen zeggen "check je themabestanden". Dat is de helft van het verhaal. Moderne WordPress redirect-malware verstopt zich op zeven plekken, ruwweg op volgorde van hoe gangbaar ze in 2024 en 2025 werden:

1. wp-content/mu-plugins/. De must-use plugins-map is de stealth-vector van 2024 en 2025. Bestanden hier laden automatisch bij elke request, kun je niet deactiveren vanuit het adminpaneel, komen niet voor in de pluginlijst en worden door de meeste file-integrity tools straal genegeerd. Het Sucuri-rapport van maart 2025 documenteerde drie kwaadaardige bestanden in één campagne: redirect.php (conditionele redirect met bot- en admin-ontwijking), index.php (downloadt en voert remote PHP uit vanaf GitHub via cURL), en custom-js-loader.php (vervangt afbeeldingen en kaapt outbound links).

2. De wp_options-tabel. Dit is de favoriet van 2023 en 2024, en precies wat server-side file scanners volledig missen. Malware slaat zijn payload op in options-rijen met hex-gecodeerde namen zoals 55e7183bded6e0fa810c47b04e65ea6e, in de wpcode_snippets-optie, in de td_live_css_local_storage-optie (de favoriet van Balada Injector), of past siteurl en home aan zodat elke WordPress-pagina resources laadt vanaf aanvallers-domeinen. De Balada Injector-campagne, samengevat door Sucuri in april 2023, heeft op deze manier meer dan een miljoen sites geïnfecteerd.

3. De functions.php van het actieve thema. Een geïnjecteerde hook bovenin functions.php draait bij elke WordPress-load en kan een redirect afvuren, een script injecteren of andere malware in de database schrijven. De injectie is vaak één regel die gecodeerde PHP uit een string elders in het bestand laadt.

4. .htaccess (Apache) of nginx config. Op Apache draaien geïnjecteerde RewriteRule- en RewriteCond-blokken al voordat WordPress überhaupt laadt. Ze kunnen redirecten op basis van User-Agent, Referer of de afwezigheid van een specifieke cookie. Op nginx staan de equivalenten in de nginx.conf of een included server block van de site. Omdat dit vóór PHP gebeurt, ziet geen enkele PHP-gebaseerde scanner het.

5. wp-config.php. Eén voorafgaand <?php-blok dat bij elke request draait is lastig te zien, want vrijwel niemand leest wp-config.php van boven naar beneden. Alles boven de define('DB_NAME', ...)-regel dat je niet herkent, is verdacht.

6. Actieve plugin-bestanden en de WPCode snippets-plugin. De reinfector-familie die Sucuri in november 2024 identificeerde gebruikt wpcode_snippets specifiek als persistentie-mechanisme, omdat dat de legitieme opslaglocatie is van een veelgebruikte code snippet-plugin. Dat maakt de geïnjecteerde PHP eruit laat zien als beoogd gebruik.

7. wp-content/uploads/. Elk .php-bestand in de uploads-map is een backdoor. Er is geen enkele legitieme reden voor PHP-bestanden daar. De combinatie find wp-content/uploads -name '*.php' geeft op een schone site nul resultaten; op een besmette site geeft hij de locatie van de backdoor.

Dan zijn er de malware-families waarvan je de naam tegen gaat komen als je op je symptomen zoekt. De families die je ook écht in primary security research terugvindt voor 2024 en 2025:

Balada Injector, actief sinds 2017 en genoemd in 2022, gedocumenteerd in Sucuri's synopsis van april 2023 en de januari 2024 Popup Builder-campagne bij The Hacker News. Hij exploiteert plugin-CVE's (tagDiv Composer, Popup Builder CVE-2023-6000), injecteert in td_live_css_local_storage en past siteurl aan.
Mal.Metrica, actief sinds 2023 en gedocumenteerd door Sucuri in mei 2024. 17.449 besmette sites getrackt in 2024. Onderscheidt zichzelf door CDN-look-alike domeinen te gebruiken zoals gll.metricaga.com in plaats van onzinnige woordcombinaties.
SocGholish, actief sinds 2017, gedocumenteerd in Sucuri's analyse van juni 2024. 147.332 geïdentificeerde infecties in 2024. Levert nep browser- en Java-update-waarschuwingen die een Remote Access Trojan op de machine van de bezoeker droppen. Een golf in maart 2024 begon zich voor te doen als WordPress-plugin om detectie te ontlopen.
De mu-plugins persistentie-campagnes hierboven al gelinkt.

Matchen jouw symptomen met één van deze families bij naam? Dan documenteren de Sucuri-rapporten hierboven de exacte bestanden en option-namen waar je op moet letten.

Fase 1: isoleer en bewaar bewijsmateriaal

Voordat je iets aanraakt: bewaar eerst wat er staat. In paniek gaan verwijderen vernietigt bewijs en kan ook de data vernietigen waar je later op wilt terugvallen.

Zet maintenance mode aan met een statisch HTML-bestand op webserver-niveau, niet met een WordPress-plugin. Elke plugin die je nu activeert kan precies de gecompromitteerde plugin zijn. Een enkel maintenance.html-bestand dat via een webserver-rewrite wordt geserveerd, is tamper-proof.
Maak een volledige file-backup: tar -czf /tmp/infected-files-$(date +%F).tar.gz /var/www/html (pas het pad aan). Maak een volledige database-backup: wp db export /tmp/infected-db-$(date +%F).sql. Download beide naar een machine die geen van jouw webhosts is. Dit is de forensische kopie.
Leg de tijdlijn vast: wanneer begonnen de klachten, welke plugins en thema's zijn in de 72 uur ervoor geüpdatet, en wat laten je hosting access logs zien voor admin-logins in datzelfde venster? Schrijf dit op. Je hebt het straks nodig voor de review request in Search Console.
Roteer elk wachtwoord: WordPress admin-wachtwoorden (van álle admins, niet alleen van jou), het hosting control panel, FTP en SSH, de database-gebruiker, en elke API-token die in plugins is opgeslagen (MailChimp, Stripe, reCAPTCHA). Ga ervan uit dat de aanvaller kopieën heeft van alles.

Fase 2: maak de bestanden schoon

Met bewijsmateriaal veilig begin je bij het bestandssysteem. Databases komen daarna, credentials en hardening het laatst.

Draai wp core verify-checksums met WP-CLI. Deze vergelijkt elk bestand onder wp-admin/ en wp-includes/ met de officiële WordPress-release op wordpress.org, en markeert elk bestand dat is aangepast of toegevoegd. Elk gemarkeerd bestand in de core-mappen is verdacht; op een schone installatie staat er niks.
```
# Vergelijkt geïnstalleerde core-bestanden met de hashes van de wordpress.org release.
# Markeert elk aangepast, ontbrekend of extra bestand in wp-admin/ en wp-includes/.
wp core verify-checksums
```
Inspecteer wp-content/mu-plugins/ handmatig. Verwijder elk bestand dat jij er niet zelf hebt neergezet. Herken je helemaal niks? Verwijder dan de hele map; WordPress maakt hem leeg opnieuw aan. Als je host hier drop-ins installeert (sommige managed hosts doen dat), schrijf die bestandsnamen dan eerst op en check ze tegen een verse installatie op dezelfde host.
```
# Lijst elk bestand in mu-plugins met tijdstempel en grootte.
ls -la wp-content/mu-plugins/
# Veelvoorkomende kwaadaardige bestandsnamen uit de Sucuri-campagne van maart 2025:
# redirect.php, index.php, custom-js-loader.php
```

Grep de hele WordPress-boom op obfuscatie-markers. Deze patronen zijn de handtekening van gecodeerde payloads. Onderzoek elk bestand dat dit commando teruggeeft.

# Zoek PHP-bestanden met veelvoorkomende obfuscatie-patronen.
# Elke hit is een bestand dat je met de hand moet lezen en beoordelen.
grep -rl "eval(base64_decode" /var/www/html/wp-content/
grep -rl "gzinflate(base64_decode" /var/www/html/wp-content/
grep -rl "str_rot13(" /var/www/html/wp-content/
grep -rl "preg_replace.*\/e" /var/www/html/wp-content/

Zoek PHP-bestanden in de uploads-map. Dat moeten er nul zijn.

# Een schone site geeft geen resultaten. Elke hit is een backdoor.
find /var/www/html/wp-content/uploads/ -type f -name "*.php"

Lees wp-config.php van boven naar beneden. Alles vóór het openende commentaarblok of vóór de regel define('DB_NAME', ...) dat je niet herkent, is geïnjecteerd. Vergelijk met een verse wp-config-sample.php uit de bijbehorende WordPress-release.
Lees de functions.php van je actieve thema en eventuele header.php of footer.php van boven naar beneden. Redirect-injecties staan bovenin het bestand of binnen de eerste add_action('init', ...)-hook.
Vervang plugins en thema's met verse bronnen. Probeer niet om individuele plugin-bestanden regel voor regel schoon te maken. Voor elke actieve plugin en het actieve thema: download een verse kopie van wordpress.org of de originele vendor, verwijder de hele map onder wp-content/plugins/plugin-name/ of wp-content/themes/theme-name/, en upload de verse kopie. Dat is sneller én betrouwbaarder dan bestand-voor-bestand opruimen. Commerciële plugins vragen vaak om het license-bestand; houd dat bij de hand.
Vervang WordPress-core. Download de bijbehorende versie van wordpress.org/download/releases/ en upload hem, waarmee je wp-admin/ en wp-includes/ overschrijft. Schrijf niet over wp-content/ en niet over wp-config.php. wp core download --force doet hetzelfde vanaf de command line.
Genereer .htaccess opnieuw. Verwijder het huidige bestand en ga dan in wp-admin naar Instellingen > Permalinks en klik op Opslaan. WordPress schrijft een verse default .htaccess-block weg. Had je custom rewrite-regels voor caching of redirects? Zet die terug vanuit een backup waarvan je zeker weet dat hij schoon is, niet vanuit het huidige besmette bestand.
Leeg elke cache. Page cache, object cache, CDN cache, en eventuele Cloudflare- of andere edge-cache. Gecachete pagina's serveren nog lang stale malicious content, ook nadat het onderliggende bestand schoon is.

Verificatie na fase 2. Draai deze checks voordat je verdergaat:

wp core verify-checksums geeft geen aangepaste bestanden.
find wp-content/uploads/ -name "*.php" geeft niks.
ls wp-content/mu-plugins/ toont alleen bestanden die je herkent.
grep -rl "eval(base64_decode" wp-content/ geeft niks.

Geeft één van deze checks nog hits? Dan ga je niet door met de database-cleanup. Reinfector-malware installeert de bestanden die je net hebt verwijderd gewoon weer terug.

Fase 3: maak de database schoon

Dit is de fase die de meeste gidsen overslaan, en de fase die de meeste reinfector-malware juist overleeft. Open phpMyAdmin of gebruik de MySQL CLI op je database.

Verifieer siteurl en home. Deze twee opties moeten exact jouw domein zijn, niks anders.
```
SELECT option_name, option_value FROM wp_options
WHERE option_name IN ('siteurl', 'home');
```
Wijst één van beide naar een domein dat je niet herkent? Pas het aan. Dit is een klassieke Balada Injector-techniek.

Jaag op gecompromitteerde PHP in wp_options. Dit vangt het hex-naam payload-patroon van de reinfector-familie uit november 2024.

SELECT option_name, LEFT(option_value, 200) FROM wp_options
WHERE option_value LIKE '%eval(%'
   OR option_value LIKE '%base64_decode%'
   OR option_value LIKE '%gzinflate%'
   OR option_value LIKE '%str_rot13%'
   OR option_value LIKE '%<script%';

Lees elke hit met de hand. Verwijder de kwaadaardige rijen (DELETE FROM wp_options WHERE option_name = '...').

Zoek hex-genoemde opties. De reinfector-familie slaat zijn payload op onder willekeurige 32-character hex-strings.
```
SELECT option_name FROM wp_options
WHERE option_name REGEXP '^[0-9a-f]{32}$';
```
Een schone WordPress-installatie heeft hier nul rijen. Elke rij is verdacht.
Check de wpcode_snippets-optie specifiek. Gebruik je de WPCode-plugin niet, dan hoort deze optie er helemaal niet te zijn. Gebruik je hem wel? Lees de waarde dan door en verifieer dat elke snippet er één is die je zelf hebt geschreven.
Controleer wp_users op onbekende admin-accounts. Vertrouw niet op de gebruikerslijst in wp-admin; hook-injectie kan accounts daaruit verbergen.
```
SELECT u.ID, u.user_login, u.user_email, u.user_registered, m.meta_value
FROM wp_users u
JOIN wp_usermeta m ON m.user_id = u.ID
WHERE m.meta_key = 'wp_capabilities'
  AND m.meta_value LIKE '%administrator%';
```
Elk account dat je niet herkent gaat weg. Is wp-admin zelf gecompromitteerd, verwijder dan via SQL.
Check wp_posts op geïnjecteerde script-tags in gepubliceerde content.
```
SELECT ID, post_title, post_status FROM wp_posts
WHERE post_content LIKE '%<script%'
  AND post_status = 'publish';
```
Review elke match. Legitiem gebruik (Google Analytics via een custom block, embed-codes) zit meestal in het thema of in de header, niet in post-content zelf.
Maak de scheduled tasks leeg. De reinfector-familie past wp-cron.php aan en zet een task klaar die verwijderde bestanden weer opnieuw installeert. Leeg en regenereer de cron-tabel met WP-CLI:
```
# Toon alle scheduled events; inspecteer op hooks die je niet herkent.
wp cron event list
# Verwijder verdachte scheduled hooks één voor één.
wp cron event delete <hook_name>
```

Verificatie na fase 3. Draai elke SQL-query hierboven opnieuw. Elke query geeft óf niks, óf alleen rijen die je expliciet herkent. wp cron event list toont alleen events van WordPress-core en van plugins die je kent.

Fase 4: sluit de toegang af en verhard

Opruimen zonder verharden laat de deur waardoor de aanvaller binnenkwam wagenwijd openstaan. Het doel van deze fase is die deur dichtdoen en elke overgebleven foothold ongeldig maken.

Roteer alles opnieuw. Ook al heb je in fase 1 al geroteerd, elk wachtwoord dat tijdens de opruimfase in gebruik is geweest kan zijn afgeluisterd. Admin-wachtwoorden van elke gebruiker, hosting control panel, FTP, SSH, database-user, en elke API-token.
Invalideer alle bestaande sessies. Wijzig AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, AUTH_SALT, SECURE_AUTH_SALT, LOGGED_IN_SALT en NONCE_SALT in wp-config.php naar verse waardes uit de WordPress.org secret-key generator. De salts vervangen invalideert elke actieve cookie, dus elke aanvaller die nog een sessie had, wordt uitgelogd.
Verwijder onbekende admin-accounts, en degradeer elke gebruiker die je niet herkent eerst naar abonnee voordat je hem verwijdert, zodat zijn geschreven content bewaard blijft voor review.

Zet de dashboard file editor uit in wp-config.php:

// Blokkeert wp-admin > Weergave > Theme File Editor
// en Plugins > Plugin File Editor. Een herinfectie-vector dicht.
define( 'DISALLOW_FILE_EDIT', true );

Zet file permissions goed. De WordPress hardening guide is de canonieke bron: mappen 755, bestanden 644, wp-config.php op 440 of 400. Vanaf de WordPress-root:

# Zet mappen op 755 en bestanden op 644.
cd /var/www/html
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 440 wp-config.php

Blokkeer PHP-executie in de uploads-map. Voeg een .htaccess-bestand toe op wp-content/uploads/.htaccess (Apache) of de equivalente nginx-location-regel:

# Blokkeer elk PHP-bestand van executie in de uploads-map.
# Een backdoor die hier wordt gedropt, kun je niet meer aanroepen.

    Require all denied

Herinstalleer Wordfence of je gekozen server-side scanner en draai een volledige scan. Was Wordfence eerder geïnstalleerd en hernoemd naar wordfence1 door de evasion-malware van juli 2024? Controleer dan dat de plugin-map nu op het correcte pad wp-content/plugins/wordfence/ staat.
Pas de rest van de hardening-baseline toe. Bestandsrechten, rate limiting op login, 2FA op elk admin-account en het complete wp-config.php security-blok staan uitgewerkt in WordPress beveiliging verharden. Een opgeruimde site die zonder die controls weer live gaat, is een site die opnieuw geïnfecteerd gaat worden.

Een geruststellende versie-noot. Sinds WordPress 5.2 (uitgebracht op 7 mei 2019) worden core automatische updates geverifieerd met een Ed25519-handtekening via libsodium, gedocumenteerd in de Paragon Initiative-post over WordPress 5.2 supply-chain mitigation en de WordPress 5.2 security-aankondiging. Als jouw WordPress-versie 5.2 of nieuwer is, is het core auto-update pad zélf geen geloofwaardige aanvalsvector. Elke compromittering die ik heb opgeruimd, kwam binnen via een plugin, een thema, een gestolen credential of een servermisconfiguratie. Core is niet de zwakke schakel.

Fase 5: vertel Google dat de site schoon is

Een opgeruimde site die nog steeds een Search Console-waarschuwing heeft, is een site zonder verkeer. De review request is de laatste stap en niet optioneel.

Verifieer de opruim met Sucuri SiteCheck. Geef je URL nog een keer in op sitecheck.sucuri.net. Elke URL die eerder geflagged was, hoort nu schoon terug te komen. Flagt SiteCheck nog steeds iets? Dan heb je een vector gemist; terug naar fase 2.
Draai een server-side scan met Wordfence of Jetpack Protect. De server-side blik ziet dingen die SiteCheck niet ziet. Bevestig nul hits.
Open Google Search Console > Beveiliging & handmatige acties > Beveiligingsproblemen. Klik op "Controle aanvragen". Het formulier vraagt wat voor hack je hebt gevonden en wat je eraan gedaan hebt. Wees specifiek. De reviewer van Google is een mens (of op z'n minst mens-gesuperviseerd) en vage antwoorden worden afgewezen. Een redelijke beschrijving ziet er zo uit:

Site was compromised on April 5, 2026. Found a conditional redirect in wp-content/mu-plugins/redirect.php and an injected payload in wp_options under a hex-encoded option name. Cleaned by: replacing all plugin, theme, and WordPress core files with fresh copies; removing malicious options from the database; deleting two unexpected admin users; rotating all credentials and session salts; enabling DISALLOW_FILE_EDIT and blocking PHP execution in wp-content/uploads/. Verified clean via Sucuri SiteCheck and Wordfence full scan. Also applied the full WordPress hardening baseline going forward.
Wachten. De gepubliceerde doorlooptijd van Google is enkele dagen tot een paar weken. Sites die binnen 48 uur na het opruimen een specifieke, geloofwaardige beschrijving indienen, worden meestal sneller vrijgegeven dan sites die een standaard "gelieve de waarschuwing te verwijderen" insturen. Wordt je aanvraag afgewezen, dan vertelt Google waarom; pak dat specifieke punt aan en dien opnieuw in.
Check apart op een manual action. Beveiligingsproblemen en handmatige acties zijn twee aparte Search Console-rapporten. Als de aanvaller je site heeft gebruikt voor spam-SEO en Google er een handmatige penalty bij heeft gezet (spam, cloaking), dan zie je dat onder Beveiliging & handmatige acties > Handmatige acties, en daarvoor moet je een apart reconsideration request indienen.
Licht VirusTotal en de vendors in die je gemarkeerd hadden. De meeste vendor-blocklists clearen automatisch wanneer hun volgende scan de site schoon ziet, maar sommige (onder andere Norton/Symantec en een handvol kleinere vendors) vragen om een handmatig report-formulier. Dien er één in bij elke vendor die VirusTotal als flaggend liet zien.

Wanneer je hulp inschakelt

Bel een specialist als één van deze dingen waar is. Verzamel voordat je belt onderstaand lijstje, zodat het eerste uur niet aan context opgaat.

Je hebt de bestanden opgeruimd en de SQL-queries gedraaid, maar de site redirect binnen minuten opnieuw nadat hij live staat.
Je vindt sporen van toegang die ouder zijn dan je logs; de compromittering begon meer dan 30 dagen geleden en de retentie van je host dekt dat niet.
Je vindt geïnjecteerde code in database-tabellen die ik niet heb genoemd (wp_posts, wp_postmeta, wp_users, wp_usermeta) en je krijgt die niet gedecodeerd.
Je host heeft het account gesuspend en zet het pas weer aan na een derde-partij incident rapport.
De compromittering raakt een payment-integratie (WooCommerce, Stripe, PayPal) en je hebt enige reden om aan te nemen dat kaartgegevens of orderdetails zijn blootgesteld. Blootstelling van kaartgegevens valt onder PCI-DSS meldingsverplichtingen, ongeacht de staat van de opruiming.
Persoonsgegevens van EU-ingezetenen zijn blootgesteld en je hebt de Autoriteit Persoonsgegevens nog niet op de hoogte gesteld. AVG artikel 33 verplicht een melding binnen 72 uur nadat je je van het datalek bewust bent geworden.

Verzamel voordat je vraagt:

De WordPress-versie, PHP-versie, webserver (Apache of nginx), en host.
Het actieve thema en een lijst van actieve plugins met versies (wp plugin list --format=csv).
De forensische backup uit fase 1.
De output van wp core verify-checksums.
De eerste en laatste datum in je access logs waarop je onverklaarbare admin-activiteit ziet.
Elke screenshot uit fase 1 (de redirect, Search Console, SiteCheck, VirusTotal).
Een tijdlijn van wat je al geprobeerd hebt en wat daarop volgde.

Hoe voorkom je dat dit opnieuw gebeurt

Een schone site is een startpunt, geen eindpunt. De controls die de compromittering überhaupt hadden tegengehouden, zijn dezelfde die de volgende gaan tegenhouden:

Automatische updates voor WordPress-core, plugins en thema's. Patchstack's 2024 State of WordPress Security-rapport zet de mediaan van publieke CVE-disclosure tot massale exploitatie op vijf uur. Handmatig patchen past niet in dat raampje. De volledige redenatie en de WP-CLI-commando's staan in WordPress beveiliging verharden.
Een echte backup-strategie, buiten de webhost, met een geteste restore. De compromittering die je net hebt opgeruimd, was een uur werk geweest in plaats van een dag als je een schone backup had gehad van voor het gebeurde. Opgeslagen in wp-content/backups/ telt niet; een aanvaller met schrijfrechten op wp-content/ kan die weggooien. De volledige aanpak staat in WordPress backup-strategie.
Tweestapsverificatie op elk admin-account. Credential-compromittering is het aanvalsspad dat niet in CVE-lijsten opduikt omdat het de data domineert. Een tweede factor blokkeert er vrijwel elke. De setup-walkthrough, inclusief de grace period waarmee je voorkomt dat je je team op dag één buitensluit, staat in tweefactor-authenticatie (2FA) voor WordPress.
Rate limiting op webserver- of WAF-niveau op wp-login.php en xmlrpc.php, beschreven in het hardening-artikel. Als de aanvaller geen 10.000 wachtwoorden kan proberen, vindt hij ook het zwakke niet.
Wekelijks review van admin-gebruikers en wekelijks review van de pluginlijst. Slapende admin-accounts en verlaten plugins zijn de twee faalwijzen die sites in stilte doen sneuvelen. Geen van beide kost lang om te checken; allebei makkelijk te missen.

Heeft een file-aanpassing in fase 2 je site op een volledig blanco pagina gezet in plaats van het normale thema? Het herstelpad voor precies die toestand staat in white screen of death in WordPress.

Wil je dat dit niet steeds jouw probleem is?

Als storingen blijven terugkomen, is de 'fix' vaak consistent beheer: updates, backups en monitoring die niet versloffen.

Bekijk WordPress onderhoud