Er WordPress-siden hacket, skal du først ta sikkerhetskopi av den infiserte siden som bevis, sette den i vedlikeholdsmodus og bytte alle passord og sikkerhetsnøkler. Deretter sammenligner du kjernefiler mot originalene, fjerner ukjente administratorer og skjulte filer, oppdaterer alt og ber Google om ny vurdering. Kan persondata ha lekket, må avviket meldes til Datatilsynet innen 72 timer.
Hvordan vet du at WordPress-siden er hacket?
De tydeligste tegnene er at Google eller nettleseren advarer mot siden, at besøkende sendes videre til andre nettsteder, eller at det dukker opp sider du ikke har laget i søkeresultatene. Mange hackede WordPress-sider ser helt normale ut for eieren. Mye skadevare viser seg nemlig bare for besøkende som kommer fra Google eller bruker mobil, og ikke for innloggede administratorer.
Søk etter site:dittdomene.no i Google. Ser du titler på japansk, reklame for legemidler eller kasinoer, er siden rammet av søkespam, som er et av de vanligste WordPress-hackene. Sjekk også rapporten Sikkerhetsproblemer i Google Search Console. Der viser Google eksempler på infiserte adresser. En mer generell gjennomgang finner du i guiden vår til å sjekke nettsider for feil og svakheter.
| Tegn | Sannsynlig type angrep | Første tiltak |
|---|---|---|
| Tusenvis av fremmede sider i Google | Søkespam (innholdsinjeksjon) | Se etter nye filer i rotmappen og i wp-content |
| Mobilbrukere sendes til en annen side | Omdirigering i .htaccess eller i databasen | Sjekk .htaccess og siteurl/home i wp_options |
| Nettleseren viser «Farlig nettsted» | Skadevare eller phishing | Åpne rapporten Sikkerhetsproblemer i Search Console |
| Du kommer ikke inn i wp-admin | Passordet er endret, eller kontoen er slettet eller nedgradert | Få tilgang via webhotellet (se neste avsnitt) |
| Ukjente administratorer under Brukere | Bakdør eller registrering som står åpen | Slett kontoene og sjekk Innstillinger → Generelt |
| Kunder melder om svindelforsøk etter kjøp | Kortskimming i kassen | Stopp betaling nå og vurder å melde avvik |
Hva gjør du den første timen?
Stopp skaden, sikre bevis og steng alle dører før du begynner å slette noe. Rekkefølgen betyr noe. Rydder du før du har tatt kopi, mister du sporene som viser hvordan angriperen kom inn, og da skjer det ofte igjen.
- 1. Ta full kopi av filer og database slik de er nå, også om de er infisert. Merk kopien tydelig så den aldri blir gjenopprettet ved en feil.
- 2. Sett siden i vedlikeholdsmodus eller begrens tilgangen i webhotellets kontrollpanel. Har du nettbutikk, stenger du kassen.
- 3. Bytt passord til webhotellet, FTP/SFTP, databasen, e-post og alle WordPress-administratorer. Gjør det fra en maskin du vet er ren.
- 4. Varsle webhotellet. Mange har egne skannere og tilgangslogger du ikke ser selv.
- 5. Noter tidspunktet da du oppdaget angrepet. Dette er viktig hvis fristen for å melde avvik til Datatilsynet begynner å løpe.
Hacket og kommer ikke inn i WordPress – hva nå?
Du kan nesten alltid få tilgang igjen via webhotellet, selv om innloggingen i WordPress er sperret. Det du trenger, er tilgang til kontrollpanelet, altså phpMyAdmin, filbehandleren eller SSH. Det viser seg ofte at angriperen har byttet e-postadressen på administratorkontoen din, slik at «Glemt passord» sender lenken til angriperen.
Via WP-CLI (raskest hvis du har SSH)
Kjør wp user list --role=administrator for å se hvem som faktisk har administratortilgang. Deretter kan du sette nytt passord med wp user update 1 --user_pass=NyttSterktPassord, og slette ukjente kontoer med wp user delete. Kommandoen wp config shuffle-salts lager nye sikkerhetsnøkler og logger ut alle som er innlogget, også angriperen.
Via phpMyAdmin
Åpne tabellen wp_users (prefikset kan være et annet enn wp_). Rett e-postadressen i user_email, og skriv inn et nytt passord i user_pass med funksjonen MD5. WordPress godtar den gamle MD5-formen og gjør den om til en sikrere hash neste gang du logger inn. Sjekk også wp_usermeta: finner du wp_capabilities med administratorrettigheter på en bruker du ikke kjenner, er det en bakdør.
Blir du sendt videre når du prøver å logge inn?
Se på verdiene siteurl og home i tabellen wp_options. Angripere endrer dem gjerne til sitt eget domene. Hvis de ser riktige ut, men omdirigeringen fortsetter, ligger koden som regel i .htaccess eller i en fil i wp-content/mu-plugins. Utvidelser i den mappen vises ikke i den vanlige utvidelseslisten i wp-admin.
Slik rydder du opp etter et WordPress-hack
Når du rydder skikkelig, bytter du ut all kode med rene originaler og leter deretter gjennom det som ikke kan byttes ut: opplastinger, databasen og wp-config.php. Å slette den ene filen skanneren fant, er sjelden nok. Google påpeker også at et nettsted kan være infisert med flere typer skadevare samtidig.
- 1. Kjør wp core verify-checksums for å finne kjernefiler som er endret eller ikke hører hjemme der. wp plugin verify-checksums --all gjør det samme for utvidelser fra wordpress.org. Premiumutvidelser må du laste ned på nytt fra leverandøren.
- 2. Erstatt wp-admin og wp-includes med ferske kopier i samme versjon, og installer alle utvidelser og temaer på nytt fra originalkilden.
- 3. Let etter PHP-filer i wp-content/uploads. Der skal det normalt bare ligge bilder og dokumenter, så en .php-fil i den mappen er nesten alltid ondsinnet.
- 4. Tøm eller kontroller wp-content/mu-plugins, og se etter ukjente filer i rotmappen, for eksempel filer med tilfeldige navn eller en falsk wp-login-kopi.
- 5. Gå gjennom wp-config.php linje for linje, og lag nye sikkerhetsnøkler (salts).
- 6. I databasen søker du etter <script, eval( og base64_decode i wp_posts og wp_options. Sjekk også planlagte oppgaver (cron) for ukjente jobber.
- 7. Kontroller Innstillinger → Generelt. Et kjent triks er å krysse av for at hvem som helst kan registrere seg, og samtidig sette standardrollen til Administrator.
- 8. Oppdater alt, og slett utvidelser og temaer som er deaktivert. Kode som ikke er i bruk, kan fortsatt angripes.
Det vi ser oftest, er at noen gjenoppretter en sikkerhetskopi fra forrige uke og tror saken er løst. Angriperen var ofte inne lenge før noen merket noe, så kopien inneholder bakdøren også. Finn ut når angrepet startet, ved å se på filenes endringsdatoer og tilgangsloggen, før du velger hvilken kopi du vil bruke.
Må du melde fra til Datatilsynet?
Ja, hvis angrepet sannsynligvis innebærer en risiko for personene du har opplysninger om. Da skal avviket meldes innen 72 timer. Dette gjelder særlig nettbutikker, sider med kontaktskjema som lagrer henvendelser, og medlemsløsninger. Hvis angriperen bare har lagt inn spamlenker og ikke har hatt tilgang til persondata, er det ofte ikke meldeplikt, men du må dokumentere vurderingen.
Ifølge Datatilsynets veiledning om digitale angrep skal du prioritere å håndtere selve hendelsen, og den første meldingen kan inneholde foreløpig og ufullstendig informasjon. Selve meldingen sendes via Altinn. Har du ikke full oversikt innen fristen, kan du melde trinnvis og sende utfyllende opplysninger senere. De 72 timene gjelder også i helger og ferier. Husk å oppdatere personvernerklæringen hvis du bytter leverandører eller verktøy etter hendelsen.
Hvordan får du bort Google-advarselen og tilbake rangeringen?
Når siden er ren, ber du om en ny vurdering i rapporten Sikkerhetsproblemer i Search Console. Google skriver at en vurdering kan ta fra noen dager til noen uker. Du må ikke sende inn en ny forespørsel før du har fått svar på den forrige. Sender du inn når problemet ikke er løst, kan neste behandling ta lenger tid, og i verste fall kan siden bli merket som gjenganger.
Ifølge Googles egen veiledning på web.dev tar vurderinger av phishing omtrent ett døgn og skadevare noen dager, mens søkespam kan ta flere uker fordi sidene ofte må behandles på nytt. Når siden er godkjent, forsvinner advarslene i nettleser og søk innen 72 timer. Skriv konkret hva du har gjort for hver type problem. Korte og generelle forespørsler blir oftere avvist.
På etablerte nettsteder Box drifter blir nye artikler normalt indeksert av Google innen 1–3 dager, og begynner å hente organiske klikk etter 3–6 uker.
Google oppdager altså endringer på etablerte nettsteder raskt, og det gjelder også spamsidene angriperen legger inn. La adressene til spamsidene gi statuskoden 410 (borte) eller 404, ikke omdiriger dem til forsiden, og send inn en oppdatert nettstedskart-fil. Følg også med på hvordan siden din blir omtalt i AI-oversikter og andre AI-svar i søk. De bygger på det Google har indeksert, og spaminnhold kan henge igjen der en stund. Slik bygger du rangeringen opp igjen etterpå, ser du i artikkelen om søkemotoroptimalisering for WordPress.
Hva koster det å rydde opp etter et hack?
Prisen avhenger mest av hvor dypt angriperen har kommet inn og om du har rene sikkerhetskopier, ikke av hvor stor siden er. Prisene varierer mye mellom leverandører, så be om en fast pris eller et kostnadstak før arbeidet starter. De dyreste postene er som regel tapt salg mens siden er nede og tapte plasseringer i Google, ikke selve oppryddingen.
| Løsning | Passer når | Fallgruve |
|---|---|---|
| Gjøre det selv | Enkel side, du har SSH eller phpMyAdmin og en ren kopi | Bakdøren blir ofte oversett, og du blir hacket igjen |
| Webhotellets skanner eller opprydding | Kjent skadevare og få endrede filer | Fjerner symptomene, men tetter sjelden hullet angriperen kom inn gjennom |
| Egen sikkerhetstjeneste | Du trenger rask hjelp og vil ha garanti mot ny infeksjon | Garantien gjelder ofte bare mens abonnementet løper |
| Byrå som også drifter siden | Nettbutikk, persondata eller gjentatte angrep | Krever at du gir byrået full tilgang og overlater ansvaret for driften |
Hva nettsider koster generelt, både å bygge og å drifte, finner du i oversikten over prisen på en nettside. Sammenlign oppryddingen med prisen for løpende vedlikehold av WordPress. For de fleste koster ett hack mer enn flere års vedlikehold.
Når er opprydding ikke riktig løsning?
Opprydding lønner seg ikke når siden er bygget på et tema eller en sidebygger som ikke lenger oppdateres, eller når ingen vet hvilken tilpasset kode som ligger der. Da kan du ikke vite sikkert at siden er ren. Det tryggeste er å flytte innholdet over i en ny installasjon og bygge siden på nytt.
Vi fraråder å rydde en side for tredje gang. Blir siden hacket igjen etter to grundige oppryddinger, sitter problemet i oppsettet: utdaterte utvidelser, delt server med svak isolering eller mange personer med administratortilgang. Da er det bedre å redesigne nettsiden på et rent grunnlag. Samtidig bør du vurdere om WordPress fortsatt er riktig publiseringssystem for bedriften.
Hvordan hindrer du at det skjer igjen?
Oppdater utvidelser raskt, hold antallet nede og beskytt innloggingen med tofaktorautentisering. Ifølge Patchstacks rapport om sikkerheten i WordPress i 2026 lå 91 % av de nye sårbarhetene i utvidelser, og omtrent halvparten av de mest alvorlige ble angrepet innen ett døgn etter at de ble kjent. Det betyr at det ikke holder å oppdatere manuelt én gang i måneden.
- Slå på automatiske oppdateringer for sikkerhetsfikser, og ha et varsel som sier fra når en utvidelse du bruker, har en kjent sårbarhet.
- Legg inn define('DISALLOW_FILE_EDIT', true); i wp-config.php. Da kan ikke en kapret administratorkonto redigere PHP-kode fra wp-admin.
- Blokker kjøring av PHP i wp-content/uploads på serveren.
- Gi hver person sin egen konto med lavest mulig rolle, og slett kontoene til tidligere ansatte og byråer.
- Ta daglige sikkerhetskopier og lagre dem utenfor webhotellet. Test at du faktisk klarer å gjenopprette dem.
- Velg et webhotell som isolerer kontoene fra hverandre og gir deg tilgang til loggene.
Stol ikke blindt på brannmuren hos webhotellet. I Patchstacks tester stoppet vanlige oppsett hos webhotell og nettskyleverandører bare en liten del av angrepene på kjente sårbarheter i WordPress. Vi mener derfor at rask oppdatering og få utvidelser gir mer sikkerhet enn enda en sikkerhetsutvidelse. Hvordan du fordeler ansvaret mellom deg og leverandøren, går vi gjennom i artikkelen om drift av nettside.
Vil du heller at noen andre skal ha ansvaret for sikkerheten, kan du lese om hvordan vi bygger og drifter nettsider for bedrifter.
Ofte stilte spørsmål
Kan jeg bare gjenopprette en sikkerhetskopi etter at WordPress-siden er hacket?
Bare hvis du vet at kopien ble tatt før angriperen kom inn, og hvis du samtidig tetter hullet angriperen brukte. Ellers gjenoppretter du bakdøren også, og siden blir infisert igjen. Sjekk endringsdatoene på filene og tilgangsloggen for å finne ut når angrepet startet.
Hjelper det å installere en sikkerhetsutvidelse etter angrepet?
En skanner kan finne kjent skadevare, men den finner sjelden bakdører som er laget for å se ut som vanlig kode, og den tetter ikke hullet angriperen kom inn gjennom. Bruk den som et supplement etter at du har byttet ut kjernefiler og utvidelser med rene kopier, ikke som eneste tiltak.
Er webhotellet ansvarlig når siden min blir hacket?
Vanligvis ikke. De fleste webhotell har ansvaret for serveren, mens du har ansvaret for WordPress, utvidelsene og passordene. Unntaket er når angrepet skyldes svakheter i selve serveren eller i hvordan kontoene er skilt fra hverandre. Les vilkårene dine, og be webhotellet om tilgangsloggene uansett.
Hvorfor blir siden hacket igjen noen dager etter at jeg har ryddet?
Nesten alltid fordi en bakdør er oversett. Vanlige steder er PHP-filer i uploads-mappen, mu-plugins, en skjult administratorkonto, planlagte oppgaver i databasen eller sikkerhetsnøkler i wp-config.php som ikke er byttet. Det kan også skyldes at utvidelsen med sårbarheten fortsatt er installert.
Hvordan vet jeg om kundedata er stjålet?
Se etter endret kode i kassen, ukjente skript som sender skjemadata til andre domener, og uvanlige spørringer eller eksport i databaseloggen. Klarer du ikke å utelukke at data har lekket, bør du melde avvik til Datatilsynet innen 72 timer og heller ettersende opplysninger når du vet mer.
Kilder og grunnlag
- Patchstack: State of WordPress Security in 2026 (kontrollert 23.09.2026)
- Datatilsynet: Melde avvik til Datatilsynet (kontrollert 23.09.2026)
- Datatilsynet: Håndtering av personvernet ved digitale angrep (kontrollert 23.09.2026)
- Google: Security issues report – Search Console Help (kontrollert 23.09.2026)
- Google / web.dev: Request a review (kontrollert 23.09.2026)
Emner
- Nettside
- Plattformvalg
