Je WordPress-site is gehackt: dit doe je in de eerste 24 uur

Is je WordPress-site gehackt, zet hem dan eerst veilig offline met een 503-onderhoudsmelding, maak een kopie, vervang alle wachtwoorden en salts, zoek de malware en handel de Google-melding in Search Console af, in die volgorde. Pas daarna ruim je op. Vaak merk je het doordat een klant belt over gokreclame op je homepage, doordat Google onder je bedrijfsnaam het label "Deze site kan zijn gehackt" toont of doordat je hoster je account blokkeert wegens spamverkeer. Wat je in de eerste uren doet, bepaalt of je er een halve dag of twee weken mee bezig bent.

Wat doe je direct: offline, kopie en wachtwoorden?

Stap één: zet de site uit de lucht, maar op de goede manier. Niet door de DNS te slopen en niet door de site simpelweg te verwijderen, maar door hem in onderhoudsmodus te zetten die een 503-statuscode teruggeeft. Een 503 vertelt Google dat je site tijdelijk niet beschikbaar is en dat de pagina bewaard moet blijven. Een 404 of een lege pagina vertelt Google dat je content weg is, en dat kost je posities die je daarna weer moet terugverdienen. Draait er een webshop op, overweeg dan alleen het besmette deel af te schermen in plaats van de hele winkel.

Stap twee: maak eerst een volledige kopie van de besmette site voordat je iets aanraakt. Bestanden én database. Dat voelt tegennatuurlijk, want je wilt de rotzooi juist weg. Maar zodra je begint met verwijderen ben je je bewijsmateriaal kwijt: je kunt dan niet meer nagaan hoe ze binnenkwamen, welke bestanden er zijn toegevoegd en wanneer het begon. En als je opruimactie de site sloopt, is die kopie je enige weg terug. Zet hem ergens neer waar hij niet uitvoerbaar is, dus niet in een submap van je webroot.

Stap drie: wachtwoorden. Allemaal, niet alleen die van WordPress. Elke beheerder in wp-admin, je hostingpaneel, FTP en SFTP, de databasegebruiker in wp-config.php, en elke API-sleutel die in je site of plugins staat. Gebruik nieuwe, unieke wachtwoorden en zet tweefactorauthenticatie aan waar dat kan. Als je hetzelfde wachtwoord ergens anders gebruikte, verander dat daar ook. Aanvallers verkopen inloggegevens door, dus reken erop dat wat gelekt is ook elders geprobeerd wordt.

Stap vier: vervang de salts in wp-config.php. Dat zijn de acht regels met AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY en de bijbehorende salts. WordPress biedt hiervoor een officiële salt-generator op api.wordpress.org: je haalt daar een verse set op en plakt de nieuwe regels over de oude heen. Het effect is simpel en cruciaal: alle bestaande sessies worden ongeldig. Ook die van de aanvaller. Zonder deze stap kan iemand die al ingelogd was gewoon blijven rondlopen nadat je alle wachtwoorden hebt gewijzigd.

Back-up terugzetten of schoonmaken?

Stap vijf: de keuze tussen back-up terugzetten of schoonmaken. Back-up terugzetten is sneller en betrouwbaarder, mits je twee dingen weet: dat die back-up van vóór de besmetting is, en dat je de content sindsdien kunt missen. Dat eerste is het lastige deel, want besmettingen worden vaak pas weken na de inbraak zichtbaar. Als je back-up van gisteren is en de aanvaller zit er al drie weken in, zet je gewoon de hack terug. Kijk daarom naar wijzigingsdatums van bestanden en naar je logbestanden om het startpunt te bepalen.

Schoonmaken is de route als je die datum niet kunt vaststellen, of als er sinds de inbraak bestellingen, inzendingen of artikelen zijn binnengekomen die je niet mag verliezen. Bij een webshop is dat bijna altijd het geval. De aanpak: vervang WordPress core volledig door een verse download van dezelfde versie, vervang alle plugins en het thema door verse kopieën uit de officiële bron, en behandel alleen wp-content/uploads en de database als materiaal dat je handmatig moet nalopen. Alles wat je kunt vervangen in plaats van repareren, moet je vervangen.

Waar zit de malware?

Waar zit die malware dan? De uploads-map als eerste. Daar horen alleen afbeeldingen, PDF's en documenten te staan, dus elk PHP-bestand in wp-content/uploads is per definitie verdacht. De tweede plek is wp-content/mu-plugins, de map voor must-use plugins. Die laden automatisch en je kunt ze niet deactiveren, maar ze zijn niet onzichtbaar: in wp-admin staan ze onder Plugins in een apart tabblad Must-Use. Kijk daar dus, en kijk daarna alsnog in de map zelf.

WordPress laadt namelijk alleen PHP-bestanden die direct in mu-plugins staan en niet die in submappen, en precies daar maken aanvallers gebruik van: een onopvallend loader-bestand op het eerste niveau haalt de echte payload uit een submap die verder nergens opvalt. Een kort, onbekend bestand op het eerste niveau naast een submap die je niet herkent is dus reden om te kijken. De derde is de gebruikerstabel in de database, waar een extra beheerdersaccount met een onopvallende naam kan staan.

Verder kijk je naar .htaccess-bestanden met omleidingsregels die je zelf niet hebt gezet, naar geplande taken in de WordPress-cron die een script periodiek opnieuw installeren, naar injecties bovenaan index.php of wp-config.php, en naar je thema-bestanden functions.php en header.php. Let op code die begint met base64_decode, eval, gzinflate of lange strings hexadecimale tekens: dat is versleutelde payload en heeft in een normaal thema niets te zoeken.

Draai je met wp-cli, dan geeft wp core verify-checksums je binnen een minuut een lijst met gewijzigde core-bestanden. Voor plugins bestaat wp plugin verify-checksums, maar dat vergelijkt uitsluitend tegen de checksums van de wordpress.org-repository. Premium plugins, plugins van een eigen server en nulled kopieën vallen er dus buiten, en voor thema's bestaat er helemaal geen checksum-commando. Juist bij premium en nulled plugins, verderop in dit artikel aangewezen als een van de meest voorkomende ingangen, helpt de checksum-controle je dus niet: daar vergelijk je handmatig met een verse kopie van de leverancier.

Een besmetting die je zelf niet ziet, is de vervelendste soort. Sommige malware toont de gewone site aan bezoekers en alleen spam aan zoekmachines, door te kijken naar de user-agent of de verwijzende zoekopdracht. Test daarom niet alleen in je browser: bekijk de site zoals Googlebot hem ziet via de URL-inspectie in Search Console, en zoek in Google op site:jouwdomein.nl om te zien of er pagina's in de index staan die jij nooit gemaakt hebt. Vind je daar Japanse tekens, medicijnnamen of casinotermen, dan zit de besmetting in je zoekresultaten en niet alleen in je site.

Hoe krijg je Google-waarschuwingen weg?

Dan Google. Staat er in Search Console een melding onder Beveiligingsproblemen, dan blijft die staan tot jij een beoordeling aanvraagt. Doe dat pas als de site aantoonbaar schoon is én het gat gedicht, want een afgewezen aanvraag kost je een nieuwe wachtperiode. Bij de aanvraag beschrijf je kort wat je hebt gevonden en opgelost. Ruim tegelijk de spampagina's op: verwijder ze, laat ze een 410 teruggeven en gebruik het verwijderingsverzoek in Search Console voor de meest zichtbare. Controleer daarna een paar weken lang of er geen nieuwe onbekende URL's opduiken.

Hoe dicht je het gat?

Pas hierna dicht je het gat, en dit is de stap die het vaakst wordt overgeslagen. Een schoongemaakte site met hetzelfde lek is binnen dagen opnieuw besmet, en de tweede keer duurt het herstel langer omdat de aanvaller inmiddels een achterdeurtje heeft achtergelaten. Update alles naar de actuele versie, verwijder elke plugin en elk thema dat je niet gebruikt in plaats van het te deactiveren, en gooi nulled of via een dubieuze site gedownloade premium plugins er zonder discussie uit. Die zijn een van de meest voorkomende ingangen.

Zet daarna een paar dingen vast die het herhalen moeilijker maken. Blokkeer uitvoering van PHP in de uploads-map op serverniveau. Beperk of hernoem de inlogpagina en zet een limiet op mislukte inlogpogingen. Zet tweefactorauthenticatie aan voor elke beheerder. Geef redacteuren geen beheerdersrol omdat het makkelijk is. Zorg dat je PHP-versie nog ondersteund wordt. En controleer of je back-ups nu wél buiten de server staan, want als je die deze week nodig had gehad, wist je het antwoord al.

Wat als er klantgegevens op je site staan?

Staan er klantgegevens op je site, dan loopt er naast de techniek een tweede spoor. Bij een mogelijk datalek geldt de meldplicht uit de AVG: in beginsel binnen 72 uur na ontdekking bij de Autoriteit Persoonsgegevens, die op de eigen site beschrijft wanneer een melding nodig is. Of een hack ook een datalek is en moet je een datalek melden, hangt af van wat er is buitgemaakt. Leg vanaf minuut één vast wat je ziet, wanneer je het zag en wat je hebt gedaan.

Wanneer schakel je hulp in?

Wanneer schakel je hulp in? Als je geen bruikbare back-up hebt. Als de besmetting terugkomt nadat je hem hebt verwijderd, want dan zit er nog een achterdeur. Als je hoster je account heeft geblokkeerd. Als er een webshop of klantdata bij betrokken is. En simpelweg als je na twee uur zoeken niet weet waar je naar kijkt. Herstel is geen kwestie van een plugin installeren, en hoe langer een besmetting loopt hoe dieper hij in je zoekresultaten zit. Wij doen dit soort werk onder WordPress-hulp: opsporen, schoonmaken, gat dichten en de Google-melding afhandelen.

Hoe voorkom je een nieuwe hack?

Een nieuwe hack voorkom je met saai, structureel werk: geteste updates, back-ups buiten de server en iemand die af en toe kijkt. Een volledige lijst met maatregelen vind je in onze WordPress-beveiligingschecklist. Dat structurele werk is precies wat een onderhoudscontract hoort te zijn. Staat je site bovendien op een overvolle shared server zonder isolatie tussen accounts, kijk dan ook naar managed hosting, waar een besmetting bij de buurman niet jouw probleem wordt.

Laatst bijgewerkt op 11 oktober 2026