To kritiske PHP-sårbarheder: opdatér nu, og husk serveren

PHP udsendte 21. oktober 2026 sikkerhedsopdateringer til to kritiske sårbarheder. Begge kan føre til, at en angriber kører kode på serveren uden at være logget ind. Begge er vurderet til 9,2 ud af 10.

Samtidig har Kombit lukket helt eller delvist ned for flere kommunale it-systemer, heriblandt Aula. Pressechefen peger på det lag, der ligger under: »Det er på PHP, der ligger under Aula.« Kombit understreger samtidig, at man ikke ved, om der er sket et indbrud — nedlukningen er en forsigtighedsforanstaltning.

Hvad er der sket?

PHP-projektet varslede opdateringen dagen før og frigav den 21. oktober klokken 16.00 dansk tid. To sårbarheder er lukket:

Begge er klassificeret som fjernudførelse af kode uden godkendelse. Det er den værste kategori, der findes: angriberen behøver hverken brugernavn, kodeord eller et link, nogen skal klikke på.

Hvordan ser du, hvilken PHP-version du kører?

Det tager under et minut, og du behøver ikke være udvikler. Vælg den vej, du har adgang til:

• I WordPress: Værktøjer → Websitetilstand → Info → Server. Linjen hedder »PHP-version«.
• I webhotellets kontrolpanel: de fleste danske webhoteller har en side, der hedder noget med »PHP« eller »PHP-version«, hvor den både vises og kan skiftes.
• Med adgang til serveren: kør kommandoen direkte.

# På en server, du har SSH-adgang til
php -v

# Bemærk: CLI-versionen kan afvige fra den, websitet kører.
# Den afgørende er den, webserveren bruger (PHP-FPM, mod_php, LiteSpeed).

Viser den 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 — eller noget nyere — er du dækket for de to sårbarheder. Viser den et lavere nummer på samme gren, mangler opdateringen.

Hvilke PHP-versioner retter sårbarhederne?

Læg mærke til den nederste linje. PHP 8.2 holder op med at få sikkerhedsrettelser 31. december 2026 — altså om godt to måneder. Opdatér til 8.2.35 nu, men brug samtidig anledningen til at planlægge springet til 8.3 eller 8.4. Ellers står du uden en rettelse at installere, næste gang der kommer en meddelelse som denne.

Kører du PHP 8.1 eller ældre, får du ikke længere almindelige opdateringer fra PHP-projektet. Men i det her tilfælde har sikkerhedsgruppen lagt rettelser frem til 7.4, 8.0 og 8.1, som kan bygges fra kildekoden. Mange webhoteller bagporterer desuden selv. Spørg dit webhotel — og læg samtidig en plan for at komme op på en understøttet version.

Sådan opdaterer du PHP — trin for trin

1. Find ud af, hvilken PHP-version du kører — se afsnittet ovenfor.
2. Tag en frisk backup af både filer og database, før du rører noget. En backup, du aldrig har afprøvet, er et håb — ikke en plan.
3. Opdatér PHP. På et almindeligt webhotel er det typisk et valg i kontrolpanelet. På egen server er det pakkehåndteringen.
4. Kontrollér bagefter, at versionen rent faktisk er skiftet, og at sitet stadig virker. Tjek forsiden, en undeside, kontaktformularen — og har du webshop, så før et testkøb hele vejen igennem.
5. Hører du intet fra dit webhotel, så spørg dem direkte. Tavshed er ikke det samme som, at der er styr på det.

Hvorfor det her rammer bredere, end folk tror

»PHP er dødt« er en påstand, der har holdt sig forbavsende længe. Virkeligheden er, at sproget ligger under en meget stor del af det danske internet — fra foreningens hjemmeside til kommunens forældreintra.

Det er også derfor, sådan en sårbarhed er anderledes end et hul i et plugin. Et plugin kan du slå fra. PHP er fundamentet, som resten står på. Opdaterer du WordPress, dine plugins og dit tema, har du opdateret huset — ikke grunden, det står på.

Den slags er sjældent et spørgsmål om ond vilje. Det er et spørgsmål om, at ingen har taget stilling til, hvem der har ansvaret for laget under systemet. Hvis du er i tvivl om, hvem der opdaterer PHP på dine løsninger, er svaret med stor sandsynlighed: ingen.

Og det er sjældent selve indbruddet, der koster mest — det er månederne bagefter. Jeg har ryddet op efter måneders skjult malware på et dansk WordPress-site, hvor hverken temaet eller et plugin var vejen ind. Jo færre lag, der er sluppet ud af syne, jo kortere bliver den slags forløb — og jo færre afhængigheder en installation har, jo mindre er der at miste overblikket over.

Ofte stillede spørgsmål om PHP-opdateringen

Er min WordPress-side berørt?

Hvis den kører på en PHP-version under 8.5.12, 8.4.27, 8.3.36 eller 8.2.35, så ja — uanset hvilket tema og hvilke plugins du bruger. Sårbarhederne ligger i PHP selv, ikke i WordPress. Det hjælper derfor ikke at opdatere WordPress, temaet eller dine plugins.

Mit site ligger hos et dansk webhotel. Gør de det ikke selv?

De fleste delte webhoteller opdaterer selv PHP, ofte inden for få dage. Men du vælger typisk selv, hvilken PHP-version dit site kører på — og ligger du på en gren, de ikke længere understøtter, bliver den ikke opdateret for dig. Tjek din version, og spørg dem direkte, hvis du er i tvivl. Tavshed er ikke en bekræftelse.

Kan jeg vente til næste uge?

Det ville jeg ikke. Begge sårbarheder kan udnyttes uden login, og PHP-projektet skriver selv, at der ikke findes nogen fuldstændig afværgeforanstaltning. Når en rettelse først er offentlig, kan man regne baglæns fra den, og forsøg på udnyttelse følger typisk hurtigt efter.

Hjælper en firewall eller et sikkerhedsplugin?

Ikke pålideligt. En WAF eller et sikkerhedsplugin kan bremse kendte angrebsmønstre, men det er stadig PHP, der afvikler forespørgslen. PHP-projektet angiver direkte, at der ikke findes en fuldstændig afværgeforanstaltning. Opdateringen er den eneste rigtige løsning.

Hvad hvis mit site går i stykker af opdateringen?

Inden for samme gren — for eksempel fra 8.3.35 til 8.3.36 — sker det stort set aldrig. Det er spring mellem hovedversioner, for eksempel fra 8.1 til 8.4, der kan kræve tilpasning af gammel kode eller forældede plugins. Tag backup først, og afprøv sitet bagefter. Vælter noget, kan du skifte tilbage og få det rettet, inden du prøver igen.

Hvordan undgår jeg at stå i det her igen?

Ved at nogen har ansvaret for laget under systemet. Det er præcis, hvad en serviceaftale dækker: overvågning, backup og opdateringer — også af PHP — så de bliver lavet, inden de bliver til en nyhed. Og ved at holde antallet af afhængigheder nede, så der er færre ting at følge med i.

Hvis du ikke selv kan nå det

Er du usikker på, om dine sites er berørt, eller har du flere løsninger at holde styr på, så sig til. Jeg kan kontrollere PHP-versionen, tage backup, opdatere og teste bagefter.

Det er også præcis den slags, en serviceaftale dækker: at nogen holder øje, og at opdateringer bliver lavet, inden de bliver til en nyhed. Skriv til hej@mickeyr.dk, eller kontakt mig her.

Kilder

• PHP: sikkerhedsmeddelelse og udgivelser, 21. oktober 2026
• PHP: understøttede versioner og slutdatoer for sikkerhedsrettelser
• GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• TV 2: it-trusler mod offentlige systemer (live)