Sikkerhedshullerne i PHP (PHP2Shell): Hvad betyder det for dit WordPress-site?

Du har måske set det i nyhederne: Den 21. oktober 2026 lukkede Aula og flere andre danske sider midlertidigt, fordi der var fundet to alvorlige sikkerhedshuller i PHP. Det lyder måske voldsomt, men for de fleste websites handler det i praksis om én ting: at din hostingudbyder har lagt rettelsen på. Her gennemgår jeg, hvad der er sket, hvordan du finder ud af, om dit website er dækket, og hvad jeg har gjort for mine egne kunder.

Tidsstemplet øverst viser, hvornår siden sidst er gennemgået.

Kort fortalt

• Fejlen sidder i PHP, det programmeringssprog WordPress kører på – ikke i WordPress, dine plugins eller dit tema.
• Rettelsen skal lægges på serveren. Det gør din hostingudbyder eller den, der driver din server. Den kommer ikke med de almindelige WordPress-opdateringer.
• De fem danske hostingudbydere, jeg har læst udmeldinger fra, melder alle, at rettelsen er lagt på deres webhoteller.
• Har du administratoradgang, kan du se PHP-versionen i WordPress, men tallet fortæller ikke altid hele historien. Det er hostingudbyderens svar, der afgør det.
• Er du i tvivl, så spørg din hostingudbyder, om rettelsen er lagt på, og hvornår.
• Skift adgangskoden til dine WordPress-administratorer og til webhotellet (se Hurtige svar).
• Har du en vedligeholdelsesaftale med mig, er rettelsen klaret. Du skal ikke gøre noget for at få den, men skift gerne din egen adgangskode (se Hurtige svar). Længere nede kan du se, hvad jeg har gjort.

Hvad er der sket?

Den 21. oktober 2026 kl. 16.00 dansk tid udgav folkene bag PHP en hasteopdatering, der lukker to kritiske sikkerhedshuller (CVE-2026-109618 og CVE-2026-109619, i daglig tale “PHP2Shell”). Ifølge PHP selv kan hullerne give en angriber mulighed for at køre sin egen kode på serveren uden at logge ind. Begge er vurderet til 9,2 på en skala fra 0 til 10.

PHP er fundamentet under WordPress. Hvis WordPress er huset, er PHP det, huset står på. Derfor rammer fejlen alle WordPress-sites, uanset hvilke plugins de bruger, og alle andre websites, der kører PHP.

Sikkerhedsfirmaet Wiz, som var med til at finde fejlen, har vist, at selv en helt simpel side kan være sårbar. Det hjælper altså ikke, at WordPress og plugins er opdaterede.

Ifølge W3Techs bruges PHP af 69,3 % af de websites, hvor man kender serversproget, og WordPress kører 39,6 % af alle websites (22. oktober 2026). Det er grunden til, at sagen fik så meget opmærksomhed.

Du har måske også set navnet WP2Shell. Det er en anden sag med huller i selve WordPress, og ifølge Meow Apps rettes den med en almindelig WordPress-opdatering.

Meldinger om hullerne slap ud to dage før den planlagte udgivelse, og derfor kom rettelsen en dag tidligere. Dansk Industri opfordrede alle virksomheder med PHP-løsninger til at opdatere “NU – ikke i morgen”, og Den Nationale Operative Stab gik i informationsberedskab, det laveste niveau. Dagen efter sagde Styrelsen for Samfundssikkerhed, at der ikke er tale om en krise, “men situationen er alvorlig”.

Det betyder, at hullet skal lukkes hurtigt, men der er ingen grund til panik. For langt de fleste handler det om at få bekræftet, at hostingudbyderen har gjort sit.

Er mit website ramt?

Alle websites med PHP var sårbare, indtil rettelsen blev lagt på serveren. Spørgsmålet er derfor ikke, om dit website var ramt, men om din server har fået rettelsen.

Det nemmeste svar får du hos din hostingudbyder. Længere nede har jeg samlet, hvad de danske hostingudbydere selv har meldt ud.

Har du administratoradgang, kan du også se PHP-versionen i WordPress: Gå til Værktøjer → Webstedshelbred → fanen Info → Server, og find linjen PHP-version. Rettelsen kom i disse versioner:

Står der versionen fra tabellen eller et højere tal med de samme to første tal (fx 8.4.28), er rettelsen på.

Men står der et lavere tal, er dit website ikke nødvendigvis sårbart. Nogle hostingudbydere lægger rettelsen ind i den version, du allerede har, så tallet ikke ændrer sig.

Jeg har selv set det på et webhotel hos Dandomain 22. oktober: versionen stod stadig som 8.4.26, men en teknisk oversigt fra serveren viste, at rettelsen var på. Den slags tjek skal du ikke selv lave, så spørg i stedet din hostingudbyder.

Du skal ikke selv rode med serveren for at finde ud af det. Det er din hostingudbyder, der lægger rettelsen på, og det er også den, der kan bekræfte det.

Har du en vedligeholdelsesaftale med mig, tjekker jeg det automatisk for dig. Har du et supportklippekort, kan jeg også gøre det, hvis du beder mig om det, og så trækkes tiden på kortet.

Til dig, der selv arbejder med serveren: Kører webhotellet CloudLinux (der står “lve” i linjen Serverarkitektur, fx 4.18.0-553.171.1.lve.el8), bliver rettelsen lagt ind som en backport, og versionsnummeret står uændret.

Dandomain og Curanet (team.blue) har lavet en side om, hvordan man ser rettelsen: https://phpinfo.dk.team.blue/. De nævner tre tegn i oversigten fra phpinfo(), og ét er nok: linjen memory_hard_limit_percent, en “Build Date” fra 19. oktober 2026 eller senere, eller en af de rettede versioner. En phpinfo-fil viser mange detaljer om serveren, så slet den, så snart du har tjekket.

Hvad gør jeg?

Hvis du har en vedligeholdelsesaftale med mig

Så holder jeg øje med det for dig. Længere nede kan du se, hvad jeg har gjort.

Hvis dit website ligger på et webhotel hos en udbyder

1. Tjek din hostingudbyders driftsside eller nyheder (se oversigten nedenfor).
2. Kan du ikke finde en klar melding, så skriv til hostingudbyderen og bed om en skriftlig bekræftelse på, at rettelsen er lagt på, og hvornår. Det er også Dansk Industris råd. Du kan bruge beskeden herunder.
3. Kører dit website PHP 8.1 eller ældre, så læs afsnittet om gamle versioner.
4. Skift adgangskoden til dine WordPress-administratorer og til webhotellet (se Hurtige svar).

Hvis du selv står for serveren

Opdatér PHP-pakkerne til en rettet version (eller distributionens rettede pakke), genstart PHP, og tjek bagefter, at den rettede version faktisk kører. Udgivet er ikke det samme som installeret: Da rettelsen kom, var en af de store pakkeservere så overbelastet, at opdateringen fejlede de første gange.

Besked, du kan sende til din hostingudbyder

Kopiér teksten, og ret domænet og PHP-versionen:

Hej

Mit website mitdomæne.dk ligger på et webhotel hos jer. Kan I bekræfte, at PHP på mit webhotel har fået rettelsen af de to sikkerhedshuller CVE-2026-109618 og CVE-2026-109619 (PHP2Shell), og hvornår den blev lagt på?

I WordPress står PHP-versionen som 8.4.26. Hvis rettelsen er lagt ind i den eksisterende version, vil jeg gerne have det bekræftet, så jeg ved, at versionsnummeret ikke skal ændre sig.

Kører mit website en PHP-version, der ikke længere får rettelser, vil jeg gerne høre, hvad I anbefaler.

På forhånd tak

Hvad har de danske hostingudbydere meldt ud?

Kun det, hostingudbyderne selv har skrevet på deres egne sider. Tidspunkter i dansk tid. Sidst gennemgået 22. oktober 2026 kl. 23.41.

Står din hostingudbyder ikke på listen, så spørg dem direkte.

Hvad hvis PHP ikke kan opdateres i dag?

PHP 8.1 og ældre får ingen ny version fra PHP. PHP har undtagelsesvis lagt rettelser ud til dem, der selv bygger PHP, og nogle hostingudbydere har lagt dem på, men det var en undtagelse, som man ikke kan bygge på.

Mit råd er at flytte til en version, som PHP stadig giver fuld support – lige nu 8.4 eller 8.5 – og teste det på en kopi af sitet først, fordi et ældre tema eller plugin kan gå i stykker på en nyere PHP. PHP 8.2 og 8.3 får kun sikkerhedsrettelser, og for 8.2 stopper de 31. december 2026.

Kan det ikke lade sig gøre med det samme, anbefaler Styrelsen for Samfundssikkerhed at tage systemer offline, hvis de ikke kan opdateres inden for kort tid. Et plugin til vedligeholdelsestilstand hjælper ikke her, fordi angrebet kan ske, før WordPress overhovedet indlæses.

Fem-minutters-tjek: Er der tegn på indbrud?

Rettelsen lukker hullet, men den fjerner ikke noget, en angriber måtte have lagt ind, før den kom. Kig tilbage til 17. oktober, ikke kun til 21. oktober: Amazon så det første forsøg fire dage før rettelsen. Du kan selv lave et hurtigt tjek:

1. Brugere: Har du administratoradgang, så gå til Brugere → Alle brugere, og se efter administratorer, du ikke kender. Har du ikke det, så bed en administrator om at kigge.
2. Forsiden: Åbn dit website på mobilen og fra et Google-søgeresultat. Bliver du sendt videre til en fremmed side?
3. Google: Søg på site:mitdomæne.dk. Er der sider med fremmed sprog, reklame for medicin, kasino eller andet, du ikke har lavet?
4. Search Console: Har du adgang, så åbn rapporten Sikkerhedsproblemer.
5. Din hostingudbyder: Spørg, om de har set tegn på angreb i serverens logfiler siden 17. oktober, og om deres malware-scanning har fundet noget. Logfilerne kan du typisk ikke selv se.

Finder du noget, så få hjælp til at rydde op, og få også skiftet adgangskoden til databasen.

Hvad jeg har gjort for mine kunder

De websites, jeg selv hoster, ligger på to hostingplatforme. Sådan forløb det:

• 21. oktober, timer før rettelsen: Ifølge begge platformes egne meldinger lagde de en midlertidig spærring ind mod en af de kendte angrebsveje.
• 21. oktober kl. 16.00: PHP udgav rettelsen.
• 21. oktober om aftenen: Den første platform var opdateret og efterprøvet kl. 22.10. De to første forsøg fejlede, fordi den pakkeserver, rettelsen skulle hentes fra, var overbelastet. Det er et godt eksempel på, at udgivet ikke er det samme som installeret.
• 22. oktober: Den anden platform udgav sine rettede pakker kl. 0.00 og rullede dem ud server for server. Den sidste server nåede udrulningen ikke, så den opdaterede jeg selv. Kl. 15.05 var den efterprøvet, og dermed kørte alle de websites, jeg hoster, den rettede version.

Jeg har efterprøvet hvert enkelt website, så jeg ved, at det kører den rettede version, og ikke kun at rettelsen er udgivet.

Jeg valgte at holde mine kunders sites åbne. Ifølge begge mine hostingplatforme lagde de allerede den 21. oktober, timer før rettelsen, en midlertidig spærring ind mod en af de kendte angrebsveje, og PHP-rettelsen blev lagt på, efterhånden som platformene leverede den.

Offentlige systemer som Aula har andre data og en anden risikoprofil end en virksomheds hjemmeside, så jeg forstår godt, at de valgte at lukke. For mine kunder vurderede jeg, at spærringen og rettelsen var den rigtige balance.

Mine kunder får en mail om, hvad sagen betyder for netop deres situation.

Har du en vedligeholdelsesaftale med mig, har jeg holdt øje med serveren og sørget for, at rettelsen kom på, eller fulgt med i, hvornår din hostingudbyder lagde den på. Er du i tvivl om, hvem der gør det for dit website, er du velkommen til at skrive til mig.

Hvordan kunne det ske?

De første tegn på fejlen blev fundet i 2024 under en ekstern gennemgang af PHP’s sikkerhed. Ingen vidste dengang, om den kunne bruges til at bryde ind, og alle løsninger kunne skabe nye problemer, så rettelsen gik i stå. PHP-projektet kalder det selv en strukturel fejl: beslutningerne tog for lang tid, og meget få kender PHP’s inderste dele godt nok til at rette den slags.

I august 2026 viste flere sikkerhedsfirmaer med hjælp fra kunstig intelligens, at fejlen kunne bruges til at bryde ind. Ifølge Wiz klarede én forsker på en uge, hvad der før ville kræve et hold af eksperter i flere måneder. Derfra var rettelsen PHP’s højeste prioritet.

Planen var at offentliggøre rettelsen torsdag 22. oktober kl. 16.00. Men tirsdag eftermiddag begyndte meldinger om hullerne at gå rundt på sociale medier, og samme aften rykkede PHP udgivelsen en dag frem til onsdag kl. 16.00.

Onsdag morgen, over seks timer før tid, udgav firmaet Chainguard ifølge PHP-projektet rettelsen på egen hånd. Hvem der først lækkede meldingerne om hullerne, vides ikke.

Sagen er også et varsel. Kunstig intelligens gør det hurtigere både at finde huller og at bygge angreb ud fra en rettelse, og Amazon skriver, at kritiske rettelser nu skal lægges på i løbet af timer, ikke dage.

Hurtige svar

Hvad er PHP, og bruger mit website det?
PHP er det programmeringssprog, der får WordPress, Joomla, Drupal og mange andre websites til at virke på serveren. Har du dit website i en færdig hjemmesidebygger eller netbutik, hvor du ikke selv har et webhotel, er det platformen, der står for serverne, og så er det dem, du skal spørge, hvis du er i tvivl.

Skal jeg selv opdatere PHP i mit kontrolpanel?
Ikke hvis du kører PHP 8.2 eller nyere på et almindeligt webhotel, for så lægger hostingudbyderen rettelsen på den PHP-version, dit website kører på, fx 8.4. At skifte version i kontrolpanelet kan få et ældre tema eller plugin til at gå i stykker. Kører du 8.1 eller ældre, bør du skifte, fordi PHP ikke længere udgiver nye versioner til dem, men test det først.

Kører du 8.2, så planlæg alligevel at skifte inden nytår, for efter 31. december 2026 får den ingen rettelser fra PHP. PHP 8.3 får sikkerhedsrettelser til og med 31. december 2027.

Er fejlen i WordPress?
Nej. Den sidder i PHP, som WordPress kører på. Derfor hjælper en WordPress-opdatering ikke her.

Beskytter Wordfence eller et andet sikkerhedsplugin mig?
Nej. Pluginnet kører inde i WordPress, og angrebet kan ske i PHP, før WordPress kører.

Hjælper Cloudflare?
Cloudflare har lagt regler ind mod angrebet på alle planer med firewall, også den gratis. Det hjælper kun, hvis trafikken til dit website går gennem Cloudflare, og Cloudflare skriver selv, at PHP skal opdateres alligevel. Det er et ekstra lag, ikke en rettelse.

Er hullerne blevet brugt til angreb?
Ja, der har været forsøg: Amazon så det første 17. oktober, fire dage før rettelsen kom, men skriver, at det er uklart, om de tidlige forsøg ville være lykkedes mod rigtige systemer. Efter rettelsen kom der hurtigt flere, og 22. oktober skriver Amazon, at hullerne nu bruges bredt i angreb. Ingen af de kilder, jeg har læst, har pr. 22. oktober dokumenteret et vellykket indbrud, men forsøgene er grunden til, at rettelsen skulle på hurtigt.

Min hostingudbyder melder, at rettelsen er lagt på. Er alt så i orden?
Har hostingudbyderen bekræftet det for netop dit website, er hullet lukket. En generel melding dækker ikke altid en ældre PHP-version eller en server, hvor du selv eller en anden står for opsætningen, og Curanet skriver fx, at de ikke opdaterer servere uden for deres driftsansvar. Rettelsen fjerner heller ikke noget, en angriber nåede at lægge ind, før den kom, så tag fem-minutters-tjekket ovenfor, og skift dine adgangskoder.

Er det farligt at besøge et website, der ikke er opdateret?
Ikke nødvendigvis, for hullet sidder på serveren, ikke på din computer eller telefon. Men har en angriber fået adgang til et website, kan siden være ændret, og de oplysninger, du har givet den, kan være kommet i forkerte hænder. Hold derfor ekstra øje med mails og opkald, der beder dig logge ind eller betale.

Vores forening har sitet hos en frivillig eller en administrator. Hvad gør vi?
Kontakt den, der står for det tekniske, og bed om en skriftlig bekræftelse på, at PHP er opdateret, og hvornår. Det kræver ingen teknisk viden, og I kan tage udgangspunkt i beskeden til hostingudbyderen ovenfor.

Skal jeg skifte adgangskoder?
Mit råd er at skifte adgangskoden til dine WordPress-administratorer og til webhotellet. Wiz har vist, at hullerne kan bruges til at læse adgangskoder fra serverens hukommelse, uden at angriberen overtager serveren, og Amazon så forsøg, før rettelsen kom. Har dit website forbindelser til fx betaling eller nyhedsbrev, så bed den, der har sat dem op, om at vurdere, om de nøgler også skal skiftes.

Har du en vedligeholdelsesaftale med mig, er det som regel kun mig, der er administrator på dit website. Skift gerne din egen adgangskode til websitet.

Brug mindst 15 tegn, genbrug ikke adgangskoder, og brug gerne en passwordmanager. Slå to-faktor-login til, hvor det er muligt. Det anbefaler Styrelsen for Samfundssikkerhed generelt.

Min hostingudbyder siger, at rettelsen er på, men versionen er den samme. Passer det?
Det kan sagtens passe. Se afsnittet “Er mit website ramt?” ovenfor.

Faktaboks

PHP: Programmeringssproget, der får WordPress og mange andre websites til at virke på serveren.

CVE: Et fælles nummer for en sikkerhedsfejl, så alle taler om den samme. Her CVE-2026-109618 og CVE-2026-109619.

CVSS 9,2: Alvorligheden på en skala fra 0 til 10.

Backport: Når rettelsen lægges ind i den version, du allerede har, i stedet for at skifte til et nyt versionsnummer.

CloudLinux: Et styresystem til webhoteller. Her kommer PHP-rettelser ofte som backport.

Firewall (WAF): Et filter foran websitet, der kan stoppe kendte angreb, før de når serveren.

Kilder

• PHP’s sikkerhedsmeddelelser 20. og 21. oktober 2026
• CERT-EU, sikkerhedsvarsel 2026-018
• Amazon om angrebsforsøgene
• Cloudflare
• DR’s liveblog
• DR’s livechat med spørgsmål fra foreninger og site-ejere
• DR’s tidslinje
• Meow Apps
• PHP Foundation om sikkerhedsudgivelsen
• PHP’s understøttede versioner
• Styrelsen for Samfundssikkerhed om sikkert login
• team.blue om CloudLinux og backport
• W3Techs: PHP og WordPress
• Wiz
• Hostingudbydernes sider: se tabellen ovenfor.

Billede: Illustration: AI-genereret.