Mijn WordPress-site is gehackt: wat te doen, in 10 stappen
Par AIFORYA — 26 juli 2026 — 12 min de lecture
Op deze pagina (15)
Leest u dit in noodgeval, begin dan hier: verwijder niets, installeer nog niets opnieuw. De duurste fout in het eerste halfuur is niet slecht opschonen — het is de sporen wissen voordat u begrijpt hoe de aanvaller binnenkwam. Zonder die informatie schoont u op, en wordt u binnen enkele dagen opnieuw geïnfecteerd, meestal via dezelfde deur.
Deze gids geeft de tien stappen op volgorde, met wat u bij elke stap controleert. Hij is geschreven voor iemand die zijn eigen site beheert zonder systeembeheerder te zijn. Reken op twee tot vier uur voor een eenvoudig geval; langer als de site groot is of de hosting gedeeld en traag.
De signalen die u hier brachten zijn waarschijnlijk een van deze: de site stuurt bezoekers naar een onbekende pagina, Google toont „Deze site kan uw computer schaden", er zijn anderstalige pagina's in de zoekresultaten verschenen, toegang tot het beheer wordt geweigerd, of uw hostingpartij heeft het account opgeschort. Ze leiden allemaal naar hetzelfde protocol.
Inhoud
- Stap 0: de eerste vijf minuten
- Stap 1: de geïnfecteerde staat veiligstellen
- Stap 2: toegang afsluiten zonder alles te slopen
- Stap 3: de accounts terugpakken
- Stap 4: alle open sessies beëindigen
- Stap 5: vinden wat er gewijzigd is
- Stap 6: op zoek naar achterdeurtjes
- Stap 7: opschonen of herstellen
- Stap 8: de ingang sluiten
- Stap 9: de Google-waarschuwing laten opheffen
- Stap 10: de vergeten plicht — persoonsgegevens
- Herhaling voorkomen
Stap 0: de eerste vijf minuten
Drie reflexen, in deze volgorde.
Raak niets aan vanaf de machine die besmet kan zijn. Is uw eigen computer geïnfecteerd, dan geeft u met een wachtwoordwijziging vanaf dat toestel de nieuwe wachtwoorden rechtstreeks aan de aanvaller. Gebruik een andere computer of een telefoon.
Wis de logboeken niet. De toegangslogboeken van uw hostingpartij (vaak 7 tot 30 dagen bewaartermijn) zijn het enige dat u vertelt waar het binnenkwam. Vraag ze meteen op als uw pakket geen toegang geeft: ze verlopen.
Waarschuw uw hostingpartij. Veel hebben een apart team en, belangrijker: verstuurt uw server spam, dan sluiten ze u zonder aankondiging af. Dat u ze hebt ingelicht, verandert dat gesprek.
Stap 1: de geïnfecteerde staat veiligstellen
Tegenintuïtief en toch onmisbaar. Maak een volledige kopie — bestanden én database — van de huidige, geïnfecteerde staat en bewaar die offline.
Drie redenen: het is uw vangnet als het opschonen de site sloopt; het is het enige bruikbare spoor om de aanval te begrijpen; en zijn er persoonsgegevens bij betrokken, dan is het waarmee u kunt documenteren wat er gebeurd is (zie stap 10).
Geef de kopie een duidelijke naam, met datum en het woord „GEÏNFECTEERD", en zet hem nooit per ongeluk terug.
Stap 2: toegang afsluiten zonder alles te slopen
Serveert de site doorverwijzingen of kwaadaardige inhoud, dan maakt elke extra bezoeker uw situatie erger in de ogen van Google en van uw hostingpartij.
De juiste zet is een onderhoudspagina op serverniveau, niet het verwijderen van de site. U houdt de inhoud in handen, bezoekers zien een eerlijk bericht, en zoekmachines krijgen een HTTP 503 (tijdelijk niet beschikbaar), wat uw vindbaarheid niet vernietigt — anders dan een site die dagenlang fouten teruggeeft.
Stap 3: de accounts terugpakken
Wijzig alle wachtwoorden, vanaf een schone machine, in deze volgorde: hosting, FTP/SFTP, database, WordPress-beheerdersaccounts, gekoppelde mailbox. Eén vergeten account is genoeg om opnieuw te beginnen.
Open daarna de gebruikerslijst van WordPress en zoek wat er niet hoort te staan: een beheerder die u niet herkent, een recent aangemaakt account, of een bestaand account waarvan de rol naar beheerder is gezet. Verwijder ze niet meteen — noteer eerst het e-mailadres en de registratiedatum; dat is nuttige informatie over de ingang. Daarna verlagen of verwijderen.
Controleer ook sleutels en toegangstokens: API-sleutels, applicatiewachtwoorden, koppelingen met diensten van derden. Dat zijn de klassieke restanten van een opschoning, en ze blijven geldig na een wachtwoordwijziging.
Stap 4: alle open sessies beëindigen
Een wachtwoord wijzigen logt niemand uit die al is ingelogd: de sessiecookie blijft geldig. Een aanvaller met een open sessie houdt die.
De ingreep is het opnieuw genereren van de beveiligingssleutels van WordPress (de „salts") in wp-config.php. WordPress biedt daarvoor een officiële generator. Vervangt u ze, dan maakt u in één keer alle bestaande sessies ongeldig, inclusief die van uzelf: u moet opnieuw inloggen, en de aanvaller ook — alleen heeft die het wachtwoord niet meer.
Stap 5: vinden wat er gewijzigd is
Het doel is scheiden wat van u is van wat is toegevoegd.
De kern van WordPress is verifieerbaar. De kernbestanden hebben officiële controlegetallen die het project publiceert: elke afwijking markeert een gewijzigd bestand. De meeste analyseprogramma's doen die vergelijking automatisch — het is de betrouwbaarste controle die u hebt, omdat ze niet op een lijst virushandtekeningen berust maar op een exacte referentie.
Waar u eerst kijkt: wp-config.php, de .htaccess in de hoofdmap (en die in submappen), index.php, de map wp-content/uploads — geen enkel .php-bestand heeft daar iets te zoeken — en de map wp-content/mu-plugins, die automatisch code laadt zonder ooit in de pluginlijst te verschijnen.
Sorteren op wijzigingsdatum is uw beste bondgenoot: zet de bestanden op een rij die in de dagen vóór het incident zijn gewijzigd. Een themabestand dat is gewijzigd op de dag dat het begon, terwijl u niets hebt aangeraakt, geeft u uw startpunt.
Stap 6: op zoek naar achterdeurtjes
Dit is de stap die men overslaat, en die de herinfecties verklaart.
Een achterdeurtje is een stuk code waarmee de aanvaller ook na het opschonen terugkomt. Het overleeft een wachtwoordwijziging en vaak een update. De gebruikelijke plekken:
- Een plugin of thema dat u nooit hebt geïnstalleerd — bekijk ook de inactieve thema's, die zelden worden nagelopen.
- Een geplande taak die de kwaadaardige code opnieuw installeert. Zet de geplande taken van WordPress op een rij en zoek namen die nergens bij horen.
- Een onopvallend beheerdersaccount, aangemaakt enkele dagen vóór het zichtbare incident.
- Code die rechtstreeks in de database is geïnjecteerd, vaak in de optietabel of in berichten.
Zolang het achterdeurtje er is, is elke opschoning tijdelijk. Twijfelt u, dan is dit het moment voor een professional: dat is geen falen, dat is een kostenafweging.
Stap 7: opschonen of herstellen
Twee wegen, en de keuze hangt aan één vraag: hebt u een back-up van vóór de infectie?
Zo ja, zet die terug — maar besef dat terugzetten alleen nooit genoeg is. Het brengt de site terug zoals hij was, inclusief het lek dat de toegang mogelijk maakte. U moet terugzetten en daarna meteen stap 8 uitvoeren, vóór de site weer online gaat. Een herstel zonder correctie is een aftelklok.
Zo nee, dan schoont u laag voor laag op: vervang de WordPress-kern door een vers officieel archief, herinstalleer elke plugin en elk thema vanaf de officiële bron in plaats van bestanden stuk voor stuk te repareren, en bewaar met de hand alleen wp-content/uploads — nadat u het van elk uitvoerbaar bestand hebt ontdaan.
Een woord over back-ups, want ze zijn het scharnier van deze stap: een back-up die u nooit hebt getest is geen back-up, maar een voornemen. De dag van het incident is het slechtst denkbare moment om te ontdekken dat hij onvolledig was.
Stap 8: de ingang sluiten
Opschonen behandelt de gevolgen. Deze stap behandelt de oorzaak, en alleen die voorkomt herhaling.
- Werk alles bij: de kern, de plugins, de thema's en de PHP-versie. Een PHP-versie die geen beveiligingsupdates meer krijgt, is een keuze, geen noodlot — uw hostingpartij laat u vrijwel altijd wisselen.
- Verwijder wat u niet gebruikt. Elke inactieve plugin en elk ongebruikt thema blijft code op de schijf, dus misbruikbaar. Een uitgeschakelde plugin is geen afwezige plugin.
- Controleer de gebruikersrechten. Een redacteur hoeft geen beheerder te zijn. De meeste inbraken lopen via een account met meer rechten dan nodig.
Stap 9: de Google-waarschuwing laten opheffen
Is uw site gemarkeerd, dan is opschonen niet genoeg: de waarschuwing blijft staan tot u een beoordeling aanvraagt.
Open in Search Console het onderdeel beveiligingsproblemen. Het benoemt het soort inbraak en geeft vaak voorbeeld-URL's — gebruik die om te controleren of u niets bent vergeten. Vraag daarna een beoordeling aan en beschrijf wat u hebt hersteld: een nauwkeurig verzoek gaat sneller door dan een vaag verzoek.
Reken op enkele dagen. Vraag de beoordeling pas aan als u werkelijk schoon bent: een afwijzing verlengt de doorlooptijd.
Controleer meteen de eigenaren van uw Search Console-property: een aanvaller die zichzelf als eigenaar toevoegt, houdt nog lang na de opschoning zicht op uw site.
Stap 10: de vergeten plicht — persoonsgegevens
Bevatte uw site klantaccounts, bestellingen, formulierinzendingen of een mailinglijst, dan is een hack niet alleen een technisch incident: het is mogelijk een datalek.
In Europa verplicht de AVG de verwerkingsverantwoordelijke om de bevoegde toezichthouder binnen 72 uur na kennisname te melden, tenzij het onwaarschijnlijk is dat het lek een risico oplevert voor de betrokkenen — en om de betrokkenen zelf te informeren wanneer het risico hoog is. De termijn begint bij kennisname, niet wanneer alles hersteld is.
Deze alinea is geen juridisch advies en vervangt uw functionaris voor gegevensbescherming of uw adviseur niet. Wat telt: leg de zaak niet weg als puur technisch zonder de vraag te stellen, en documenteer wat u hebt vastgesteld en gedaan — precies waarvoor de kopie van de geïnfecteerde staat uit stap 1 dient.
Herhaling voorkomen
Een site die wordt opgeschoond zonder dat de werkwijze verandert, wordt opnieuw overgenomen. Drie maatregelen dekken de overgrote meerderheid van de echte gevallen, en ze kosten vrijwel niets.
Tweestapsverificatie op accounts met rechten. Dit is de maatregel die wachtwoorddiefstal — nog altijd de meest alledaagse ingang — nutteloos maakt.
Bescherming van de inlogpagina. Pogingen beperken, blokkeren na herhaalde mislukkingen, adressen in de gaten houden die blijven aandringen: geautomatiseerde aanvallen zijn dom en massaal, en ze stoppen bij een deur die meetelt.
Bewaking van de bestandsintegriteit. Dat is het verschil tussen het incident binnen enkele uren zelf ontdekken en het drie weken later horen van een klant of via een Google-waarschuwing. De kosten van een hack zijn niet evenredig aan de technische ernst: ze zijn evenredig aan hoe lang hij onopgemerkt bleef.
De vier duurste fouten
- Alles verwijderen en opnieuw beginnen zonder de ingang te begrijpen. U verliest de informatie, en het lek blijft.
- Een back-up terugzetten en meteen weer online gaan. Het lek wordt met de rest teruggezet.
- Wachtwoorden wijzigen zonder sessies ongeldig te maken. De aanvaller blijft ingelogd.
- Alleen opschonen wat zichtbaar is. De zichtbare doorverwijzingen zijn het symptoom; het achterdeurtje is de ziekte.
FAQ
1. Hoe lang duurt het om een gehackte WordPress-site op te schonen? Twee tot vier uur bij een eenvoudig geval met een schone back-up. Een dag of langer zonder back-up, of als de infectie oud is en zich in de database heeft verspreid. Het langste deel is bijna nooit het opschonen: het is het vinden van de ingang.
2. Kan ik WordPress er niet gewoon overheen installeren?
Dat vervangt de kernbestanden, wat helpt, maar raakt plugins, thema's, de database en bestanden in uploads niet — daar verstoppen de meeste achterdeurtjes zich. Het is een stap, geen oplossing.
3. Mijn hostingpartij zegt dat het mijn schuld is. Klopt dat? Bij gedeelde hosting kan de oorzaak ook een naburige site of een lek aan serverzijde zijn. Dat gezegd hebbende: in de grote meerderheid van de waargenomen gevallen is de ingang een verouderd onderdeel of een zwak wachtwoord — dus iets waar u invloed op hebt. Vraag de toegangslogboeken op: die beslechten het beter dan de discussie.
4. Moet ik mijn bezoekers waarschuwen? Kunnen persoonsgegevens zijn blootgesteld, dan is de vraag niet alleen commercieel maar ook regelgevend: zie stap 10. Daarbuiten is transparantie vrijwel altijd goedkoper dan stilte die later wordt ontdekt.
5. Hoe weet ik dat het echt voorbij is? Drie signalen: de kernbestanden komen weer overeen met de officiële controlegetallen, er blijft geen onbekende geplande taak over, en er duikt na meerdere dagen niets opnieuw op. Het derde telt het zwaarst — een herinfectie treedt meestal binnen de week op.
6. Kan het opnieuw gebeuren? Ja, als de oorzaak niet is aangepakt. Nee, in de praktijk, als u stap 8 hebt gedaan en tweestapsverificatie, inlogbescherming en integriteitsbewaking hebt ingericht. Geautomatiseerde aanvallen zoeken makkelijke doelen; die gaan verder.
Meer over voorkomen in plaats van repareren leest u in onze gids om WordPress te beveiligen tegen geautomatiseerde aanvallen.