Indgangsvejen i WordPress: sårbart plugin eller svag adgang?

Forside › Undersøgelse efter et hackerangreb · Gennemgået oktober 2026 · Af John Nielsen

Når en WordPress-side er kompromitteret, og webbureauet og kunden er uenige om ansvaret, bliver indgangsvejen det centrale tekniske spørgsmål. De almindelige forklaringer er et sårbart plugin eller tema, et stjålet eller svagt login til WordPress, en kompromitteret konto hos hosting, FTP eller kontrolpanel, og smitte fra andre sider på samme server. Hver forklaring efterlader forskellige spor, og den rigtige metode er at opstille dem som hypoteser og teste dem mod adgangslogs, versionshistorik og datoer for offentliggjorte sårbarheder. Ofte kan én forklaring underbygges og andre afkræftes. Nogle gange kan ingen af dem, og det skal så stå klart.

Sikringen og den grundlæggende analyse af filer, database og logs er beskrevet i Kompromitteret WordPress: webserverlogs, filændringer og databasen. Leverandørens praktiske skridt, når kunden giver skylden, står på bevissikring-digitalt.dk.

Kortlæg adgangene

Før hypoteserne kan testes, skal det være klart, hvem og hvad der havde adgang til siden. Lav en liste over WordPress-brugere med administratorrettigheder, konti hos hostingudbyderen, FTP-, SFTP- og SSH-konti, databasebrugere, administrationsværktøjer, der kan installere og opdatere plugins på afstand, og integrationer med egne nøgler, fx betalings- og nyhedsbrevsmoduler. Notér for hver adgang, hvem der ejer den, hvem der kender koden, og om den var beskyttet med totrinsgodkendelse. Listen er grundlaget for at vurdere, hvilke veje der overhovedet var mulige, og den afslører ofte konti, som ingen længere bruger.

Opstil hypoteserne først

Skriv hypoteserne ned, før analysen begynder, og beskriv for hver af dem, hvilke spor der ville støtte den, og hvilke der ville afkræfte den. Det beskytter mod at lede efter den forklaring, man på forhånd tror på, og gør det let for modparten at se, hvordan konklusionen er nået. → Analyseplan og hypoteser

Sårbart plugin eller tema · Spor, der støtter: Forespørgsler mod den sårbare komponent kort før første ændring; komponenten var i en sårbar version på tidspunktet · Spor, der afkræfter: Komponenten var opdateret, før sårbarheden blev udnyttet bredt; ingen forespørgsler mod den
Stjålet eller gættet WordPress-login · Spor, der støtter: Vellykket login fra ny adresse efterfulgt af administrative handlinger; forudgående loginforsøg · Spor, der afkræfter: Ingen vellykkede logins i perioden; ændringer er sket uden om WordPress
Hosting-, FTP- eller SSH-konto · Spor, der støtter: Filer skrevet af en anden systembruger end webserveren; log for FTP, SSH eller kontrolpanel · Spor, der afkræfter: Filer er skrevet af webserverens proces; ingen logins i hostingens logs
Andre sider på serveren · Spor, der støtter: Samme type fund på andre sider under samme konto; filer skrevet på tværs af webrødder · Spor, der afkræfter: Siden er alene på kontoen eller isoleret
Komponent fra uofficiel kilde · Spor, der støtter: Premium-plugin uden licens hentet uden for leverandørens kanal; afvigelser fra leverandørens pakke · Spor, der afkræfter: Komponenten svarer til den officielle pakke

Sårbart plugin: tidslinjen afgør

For hypotesen om et sårbart plugin er tidslinjen afgørende. Der skal fastlægges fire datoer:

hvornår den sårbare version blev installeret på siden,
hvornår sårbarheden blev offentliggjort, og hvornår en rettet version var tilgængelig,
hvornår siden blev opdateret til den rettede version, hvis den blev det,
hvornår den første ondsindede ændring eller forespørgsel fandt sted.

Datoer for offentliggørelse og rettelse findes i offentlige sårbarhedsdatabaser og i pluginets ændringslog. Angiv kilden for hver dato, og vær opmærksom på, at databaserne kan angive forskellige datoer for samme sårbarhed. Typiske referencer er CVE-registret, den amerikanske National Vulnerability Database (NVD) og databaser, der specialiserer sig i WordPress-komponenter. Datoen i NVD er den dato, posten blev offentliggjort dér, og den kan ligge efter leverandørens eller forskerens første offentliggørelse.

Den installerede versionshistorik er sværere at finde. Mulige kilder er backups med pluginets filer, pluginets egen versionsfil, administrationsværktøjer, der logger opdateringer, hostingens logs, indstillingen for automatiske opdateringer og ændringstidspunkter på pluginets filer. Brug flere kilder, fordi filernes tidsstempler kan påvirkes af både opdateringer og angriberen.

Er sårbarheden udnyttet, ses det typisk som forespørgsler i adgangsloggen mod netop det pluginets filer eller funktioner, fra adresser, der ikke ellers bruger siden, tæt på den første ændring. En sårbar version alene viser ikke, at sårbarheden var indgangsvejen.

Stjålet eller svagt login

WordPress logger som udgangspunkt ikke logins i databasen. Logins må derfor findes i adgangsloggen som vellykkede POST-forespørgsler til loginsiden efterfulgt af forespørgsler til administrationen, eller i et sikkerhedsplugins egen log, hvis et sådant var installeret. Kendetegn er:

mange mislykkede forsøg efterfulgt af et vellykket,
et vellykket login fra en ny adresse uden forudgående fejl, hvilket kan pege på, at koden var kendt,
administrative handlinger lige efter, fx installation af et plugin eller oprettelse af en bruger.

Hvilken konto der blev brugt, kan ofte findes ved at koble tidspunktet til ændringer i databasen, fx forfatteren af en revision eller den bruger, der installerede et plugin. Om kontoen havde totrinsgodkendelse, og om koden var genbrugt, er relevant for ansvaret, men det er en vurdering uden for loggen. Feltbetydninger i adgangsloggen er beskrevet i Webserverlogs.

Hosting og server

Filernes ejer og gruppe på serveren viser, hvilken systembruger der skrev dem. Filer skrevet af webserverens proces peger mod en vej gennem webapplikationen, mens filer skrevet af FTP- eller SSH-kontoen peger mod den konto. Hostingens logs for FTP, SSH og kontrolpanel skal derfor med. De ligger hos hostingudbyderen og har ofte kort opbevaring.

Når der ikke kan konkluderes

Mangler logs for den relevante periode, kan indgangsvejen ofte ikke fastlægges. Det er et resultat i sig selv. Rapporten bør så beskrive, hvilke hypoteser der er mulige, hvilke der kan udelukkes, og hvilke data der ville have været nødvendige. Fravær af spor for én hypotese gør ikke en anden bevist. → Fravær af spor

Når begge parter har en sagkyndig

I en tvist mellem bureau og kunde er det en fordel, hvis begge parters sagkyndige arbejder ud fra de samme sikrede data og den samme liste over hypoteser. Uenighed handler så om fortolkning frem for om, hvilke data der findes. Går sagen videre til et syn og skøn, er hypotesetabellen et godt udgangspunkt for skønstemaerne. → IT-skøn over hjemmesider og webshops

Fejlkilder

Bekræftelsesbias: Den, der på forhånd mener, at et bestemt plugin var skyld, finder let spor, der passer.
Scanninger: Siden er udsat for automatiske scanninger hele tiden. Forespørgsler mod et sårbart plugin viser forsøg, ikke nødvendigvis det vellykkede.
Flere indgangsveje: En side kan være kompromitteret flere gange af forskellige aktører.
Gendannelser: En gendannelse fra backup kan genindføre en sårbar version og give et forvirrende versionsforløb.

Hvad analysen kan og ikke kan vise

Analysen kan vise, hvilken indgangsvej data bedst understøtter, og hvilke der kan afkræftes. Den kan dokumentere, hvilken version der var installeret, og hvornår en rettelse var tilgængelig. Den kan ikke afgøre, hvem der havde ansvaret for opdateringer eller adgangskoder. Det afhænger af aftalen mellem parterne og er en juridisk vurdering.

Dokumentation

Rapporten bør præsentere hypoteserne med støttende og afkræftende fund, tidslinjen med kilder for hver dato og en klar konklusionsgrad for den mest sandsynlige indgangsvej. Læg de rå logs, versionsoplysninger og opslag i sårbarhedsdatabaser i bilag med hashværdier og opslagstidspunkt, så den anden part kan efterprøve hver dato.

Kilder og versioner

Senest gennemgået: oktober 2026.

Næste skridt

Del af: Undersøgelse efter et hackerangreb

Læs også: Kompromitteret WordPress: webserverlogs, filændringer og databasen · Skimming på betalingssiden: spor efter injiceret JavaScript

→ Undersøgelse efter et hackerangreb · Haster det? Forensisk sikring (hastesager koster ekstra) · For sagkyndige · Tlf. 70 13 63 23 · Digital bevissikring hos Nielco IT

Skrevet af John Nielsen, IT‑sagkyndig og indehaver af Nielco IT. Selvstændig siden 2009 og mere end 30 års erfaring med IT‑sikkerhed. Har været IT‑sagkyndig i danske retskredse og ved Den Fælles Europæiske Patentdomstol (UPC). Om John Nielsen · LinkedIn · Redaktionel politik