Dansk hosting fra Aalborg
Servere i Europa
24/7/365 dansk support
[email protected]
Sikkerhed og backup 7 min. læsning Opdateret 3. oktober 2026

Malware-oprydning i WordPress – trin for trin, så det holder

Fjern malware i WordPress i fem faser: isolér, kortlæg med checksums, rens fra rene kilder, luk indgangen og hærd – så det ikke gentager sig.

Malware-oprydning i WordPress – trin for trin, så det holder

Kort svar: En grundig malware-oprydning følger fem faser: isolér (vedligeholdelsestilstand, skift ALLE adgangskoder og nøgler), kortlæg (find de inficerede filer med checksum- og scanningsværktøjer), rens (geninstallér kerne, temaer og plugins fra rene kilder – reparer aldrig inficerede filer i hånden), luk hullet (find og opdatér indgangen, ellers kommer angriberen igen) og hærd (2FA, opdateringer, overvågning). Genvejen er en ren backup fra FØR infektionen – men kun sammen med fase 4: hullet skal stadig lukkes.

Fagligt gennemgået: 2. oktober 2026

Den akutte førstehjælp – hvad du gør i timen efter opdagelsen – står i guiden om hacket WordPress. Denne artikel er næste kapitel: den systematiske oprydning, der gør sitet rent og HOLDER det rent. Forskellen på de to er vigtig: mange “rensede” sites geninficeres inden for uger, fordi kun symptomerne blev fjernet – ikke indgangen.

Kommandoerne nedenfor bruger WP-CLI og en terminal via SSH. Har du ikke den adgang, kan de fleste trin udføres med et sikkerhedsplugin, filhåndteringen i kontrolpanelet og phpMyAdmin – eller af din hostingudbyder.

Før du ændrer noget: Tag en komplet kopi af det inficerede site – filer og database – før du renser noget, og gem den adskilt fra sitet. Den er dit bevismateriale og din analysekilde. Arbejd aldrig direkte i den eneste kopi, og brug ikke den inficerede kopi som “backup”, du senere gendanner fra.

1. Isolér og skift alle nøgler

Sæt sitet i vedligeholdelsestilstand (eller spær adgangen med adgangskode eller IP-begrænsning), så besøgende ikke rammes, mens du arbejder. Skift derefter samtlige nøgler i én arbejdsgang:

  • alle WordPress-brugeres adgangskoder – især administratorer;
  • databasens adgangskode (og opdatér wp-config.php);
  • SFTP-, SSH- og kontrolpaneladgange;
  • API-nøgler til betaling, mail, CDN og andre integrationer, der står i databasen eller konfigurationen.

Angriberen kan have høstet alt – og en oprydning med genbrugte nøgler er spildt arbejde. Skift også saltnøglerne i wp-config, så alle stjålne login-cookies dør øjeblikkeligt:

wp config shuffle-salts

2. Kortlæg infektionen

Terminaleksempel: verify-checksums afslører ændrede kernefiler og fremmede filer
Genskabt terminaleksempel, 30. august 2026: checksum-tjekket afslører både ændrede kernefiler og filer, der slet ikke hører hjemme. Eksemplet er ikke data fra hostious.io.

wp core verify-checksums sammenligner hver kernefil med WordPress’ officielle facit og udpeger alt ændret eller fremmed – samme tjek findes for plugins fra wordpress.org. Start med de to, og supplér med søgninger efter de klassiske tegn:

wp core verify-checksums
wp plugin verify-checksums --all

# PHP-filer i uploads (hører aldrig hjemme dér)
find wp-content/uploads -type f -name "*.php"

# Filer ændret inden for de seneste 14 dage
find . -type f -mtime -14 -printf "%TY-%Tm-%Td %TH:%TM  %p\n" | sort

# Administratorer, cron-hændelser og must-use-plugins
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp cron event list
wp plugin list --status=must-use

# Scripts i indhold og indstillinger
wp db search "<script" --all-tables

Kig også på de steder, hvor bagdøre gerne gemmer sig:

StedHvad du leder efter
.htaccess (i roden og i undermapper)Redirects til fremmede domæner, især betinget af referrer eller mobil
.user.ini og php.iniauto_prepend_file, der indlæser en fremmed fil før WordPress
wp-config.phpEkstra kode i toppen eller bunden, include af ukendte filer
Options-tabellenÆndret siteurl eller home, ukendte autoload-indstillinger med kode
Tema og child-temaUkendt kode i functions.php eller filer, der ikke hører til temaet

Notér alle fund med tidsstempler – de ældste peger på indgangstidspunktet, som fase 4 skal bruge. Et sikkerhedsplugins scanning er et godt supplement, men den finder kun det, den kender.

3. Rens fra rene kilder

Princippet: erstat, reparer ikke. Kernen geninstalleres fra wordpress.org, plugins og temaer slettes og hentes friske i samme (eller nyere) versioner – og alt, der ikke længere bruges eller vedligeholdes, ryger helt. Med WP-CLI:

wp core download --force --skip-content
wp plugin install <plugin-slug> --force
wp theme install <tema-slug> --force

Premium-plugins og -temaer hentes fra leverandørens egen konto, aldrig fra en tilfældig kilde. Kun wp-config.php (gennemgået linje for linje), uploads (renset for PHP-filer) og databasen bevares fra det gamle site. Databasen gennemgås for injicerede scripts i indlæg, widgets og indstillinger samt ukendte brugere.

Findes en ren backup fra før infektionen (tidsstemplerne fra fase 2 afgør det), er gendannelse plus fase 4 ofte hurtigere og sikrere – fremgangsmåden står i gendannelses-guiden. Husk, at indhold og ordrer oprettet efter backuppen skal genskabes.

4. Luk hullet

Uden denne fase er resten midlertidig. Indgangen er næsten altid én af fire:

  • et sårbart, forældet plugin eller tema – sammenhold fase 2’s tidsstempler med kendte sårbarheder (se overvågnings-guiden);
  • et lækket eller svagt kodeord – tjek accessloggen for vellykkede logins fra fremmede IP-adresser, og beskyt loginet;
  • en anden inficeret installation på samme konto (krydskontaminering);
  • nulled eller piratkopierede temaer og plugins med indbygget bagdør.

Konkludér ikke “det var nok tilfældigt” – find den konkrete indgang, og luk den. Accessloggen omkring det ældste tidsstempel er det bedste sted at starte – se guiden til at læse serverlogs.

Flere sites på samme konto

Ligger flere WordPress-installationer på samme hostingkonto, kan malware flytte sig mellem dem, fordi de deler filrettigheder. Gennemgå derfor alle installationer – også gamle testsites og glemte undermapper – med samme metode. En glemt kopi af sitet fra for flere år siden med forældede plugins er en klassisk indgang. Tjek også serverens crontab, hvis du har adgang: en planlagt opgave kan genskabe bagdøren hver nat, uanset hvor grundigt du har renset filerne.

5. Hærd og overvåg

Afslut med pakken, der gør næste angreb til en ikke-hændelse: 2FA på alle administratorer, automatiske opdateringer på plugins, wp-config-hærdning (bl.a. DISALLOW_FILE_EDIT), sikkerhedsheadere og løbende fil- og sårbarhedsovervågning. Fjern administratorrettigheder fra brugere, der ikke har brug for dem.

Var sitet markeret som skadeligt hos Google, så anmod om en ny gennemgang via rapporten om sikkerhedsproblemer i Search Console, når sitet er rent – markeringen forsvinder ikke af sig selv. Tjek også, om domænet er kommet på spamlister, hvis sitet har sendt spam.

Verifikation

Oprydningen er dokumenteret, når verify-checksums er rent for kerne og plugins, scanningen er ren, der ingen ukendte brugere, cron-hændelser eller mu-plugins findes, indgangen er identificeret og lukket – og sitet har kørt to uger uden nye fund i overvågningen. Gem hele hændelsesnotatet (tidslinje, fund, indgang, tiltag): det er både jeres læring og dokumentationen, hvis kunder eller myndigheder spørger. Og er opgaven større end tiden tillader, så lad Hostious tage rensningen – med serveradgang og logs går det betydeligt hurtigere.

Læs også

Ofte stillede spørgsmål om malware-oprydning

Kan jeg nøjes med et sikkerhedsplugins auto-rens?

Som førstehjælp, ja – men auto-rens fjerner det genkendte og lader ukendte bagdøre og selve indgangen stå. Brug den som fase 2-værktøj, og gennemfør stadig fase 3-5.

Hvorfor bliver sitet ved med at blive geninficeret?

Fordi indgangen aldrig blev lukket – eller fordi en bagdør overlevede rensningen (typisk i uploads, som mu-plugin, i .user.ini eller som en planlagt opgave). Genstart fra fase 2 med tidsstemplerne i fokus, og overvej gendannelse fra ren backup som fundament.

Skal kunder eller myndigheder informeres?

Hvis persondata kan være berørt (formulardata, kundekonti, ordrer), skal hændelsen vurderes efter GDPR. Indebærer bruddet en risiko for de berørte, skal det anmeldes til Datatilsynet inden for 72 timer efter, at I blev opmærksomme på det. Dokumentér omfang og tidsrum, og tag vurderingen med jeres rådgiver – teknik-notatet fra oprydningen er grundlaget.

Er det nok at gendanne en backup?

Kun hvis backuppen er fra før infektionen, og du samtidig lukker indgangen og skifter alle nøgler. Ellers gendanner du enten malwaren eller et site med det samme hul, som angriberen kan bruge igen.

Skrevet af Marc, stifter af Hostious

Jeg hedder Marc og har stiftet Hostious. Vi hoster WordPress-hjemmesider og WooCommerce-webshops for danske virksomheder – drevet fra Aalborg-området med servere i Europa – og jeg skriver guiderne her ud fra det, vi ser i driften hver dag.

Udgivet 31. august 2026Opdateret 3. oktober 2026Fagligt gennemgået 2. oktober 2026

Samme emne

Fortsæt med emnet

Alle guides: Sikkerhed og backup