To kritiske sårbarheder i PHP kan gøre det muligt for en angriber at køre kode på en webserver uden først at logge ind. De rettede versioner er udgivet, og diverse Webhosting har opdateret sine tilgængelige PHP-versioner. Men som virksomhed bør I stadig kontrollere, hvilken version jeres website bruger, og om andre sikkerhedsproblemer står åbne.
Den 21. oktober 2026 offentliggjorde PHP-projektet to kritiske sårbarheder, CVE-2026-109618 og CVE-2026-109619. Begge kan under bestemte forhold føre til fjernkørsel af kode, også kaldet remote code execution. Det betyder, at et angreb i værste fald kan give mulighed for at læse eller ændre data, placere ondsindet kode på serveren eller forstyrre driften.
Det er vigtigt at holde fast i proportionerne: En sårbar version er ikke det samme som et dokumenteret angreb. Men fordi sårbarhederne kan udnyttes uden login, og PHP bruges på mange websites, bør opdateringen behandles som en hasteopgave.
Hvilke PHP-versioner er rettet
PHP-projektet anbefaler omgående opdatering til en af disse versioner:
PHP 8.5.12
PHP 8.4.27
PHP 8.3.36
PHP 8.2.35
PHP 8.1 og ældre versioner modtager ikke længere almindelige sikkerhedsopdateringer fra PHP-projektet. Nogle hosting- eller LTS-leverandører kan levere egne rettelser, men det skal bekræftes hos den konkrete leverandør. PHP 8.2 når desuden end of life den 31. december 2026, så en opgradering til en nyere understøttet version bør allerede være planlagt.
Hvad diverse host hændelsen betyder for jer
Om morgenen den 22. oktober markerede de hændelsen som løst og skrev, at alle tilgængelige PHP-versioner var opdateret, og at de midlertidige modforanstaltninger var rullet tilbage.
Hvis jeres website ligger hos eksempelvis one.com eller simply.com, er det betryggende, men kontrollen bør ikke stoppe dér. Hostingplatformen kan være opdateret, mens jeres website stadig bruger en ældre PHP-gren, forældede plugins eller en konfiguration, der giver unødig risiko. Bruger I en anden hostingudbyder eller egen server, skal I kontrollere leverandørens status og den installerede patchversion direkte.
Sådan tjekker I jeres website nu
Find den aktive PHP-version. Åbn hostingens kontrolpanel eller bed jeres webansvarlige om den præcise version. Det er ikke nok at vide, at I bruger PHP 8.4; patchniveauet skal i denne situation være 8.4.27 eller nyere.
Bekræft at rettelsen er installeret. Sammenhold versionen med PHP-projektets sikkerhedsmeddelelse og hostingudbyderens status. Hvis oplysningerne ikke er entydige, så bed leverandøren om en skriftlig bekræftelse.
Tag en frisk backup. Sørg for en brugbar backup af både filer og database, før I ændrer PHP-version, WordPress, temaer eller plugins. Kontrollér også, hvem der kan gendanne, og hvor lang tid det vil tage.
Test før I skifter version. En nyere PHP-version kan afsløre inkompatibilitet i ældre plugins, temaer eller specialkode. Test helst i et stagingmiljø, og kontrollér formularer, login, betaling, integrationer og andre forretningskritiske funktioner.
Opdatér WordPress og tilføjelser. PHP-rettelsen løser sårbarheden i PHP, men ikke svagheder i WordPress-kernen, plugins eller temaer. Fjern tilføjelser, der ikke længere bruges, og erstat komponenter, som ikke længere vedligeholdes.
Kontrollér debug logging. WordPress kan gemme fejl i wp-content/debug.log. Hvis loggen ligger offentligt tilgængeligt, kan den indeholde tekniske oplysninger, som ikke bør være synlige. Slå debugtilstand fra på produktionssitet, når fejlsøgningen er afsluttet, eller placér og beskyt loggen korrekt.
Se efter tegn på misbrug. Gennemgå nye administratorbrugere, uventede filændringer, ukendte planlagte opgaver, usædvanlig trafik og sikkerhedsalarmer. En opdatering lukker sårbarheden fremadrettet, men fjerner ikke nødvendigvis følgerne af et tidligere angreb.
Placér et tydeligt ansvar. Aftal hvem der følger leverandørmeddelelser, godkender hasteopdateringer og dokumenterer dem. Det er især vigtigt, hvis webbureau, hostingudbyder og intern IT deler ansvaret.
WordPress-advarslen om en offentlig debug-log
Et af de uploadede skærmbilleder viser WordPress Site Health-advarslen om, at websitet logger fejl til en potentielt offentlig fil. Det er et særskilt problem fra de to PHP-sårbarheder, men det er relevant at løse samtidig. WordPress’ egen dokumentation advarer om, at debug-filer kan ligge offentligt tilgængeligt og bør flyttes uden for webroden eller beskyttes med korrekte filrettigheder og serverregler.
Lad en teknisk ansvarlig kontrollere WP_DEBUG, WP_DEBUG_LOG og WP_DEBUG_DISPLAY i wp-config.php. På et produktionssite bør debugoplysninger som udgangspunkt ikke vises for besøgende eller efterlades i en offentligt læsbar logfil. Slet ikke en log ukritisk, hvis den er nødvendig i en igangværende undersøgelse; gem den sikkert og afklar først, om den indeholder spor, der bør bevares.
Tre fejl I bør undgå
At antage at alt er sikkert, fordi hostingudbyderen viser grøn status. Leverandørens platform kan være rettet, mens jeres valgte version, websitekode eller drift stadig kræver handling.
At opgradere direkte på et forretningskritisk website uden backup og funktionstest. Hurtig handling er vigtig, men ændringen skal stadig kunne rulles tilbage.
At blive på en udgået PHP-version på ubestemt tid, fordi et plugin ikke kan følge med. Det flytter problemet fremad og øger den tekniske gæld.
Gør næste sikkerhedsopdatering lettere at håndtere
Denne hændelse viser, hvorfor et website ikke kun skal kunne opdateres, men også skal have en ejer, en kendt leverandørkæde og en enkel proces for hasteændringer. Registrér derfor jeres websites og systemer, de ansvarlige personer, de anvendte versioner og den seneste kontrol. Aftal også, hvordan en kritisk meddelelse bliver vurderet, testet, implementeret og dokumenteret.
Det gør det lettere at svare på de spørgsmål, der opstår, når en ny sårbarhed rammer: Er vi berørt? Hvem handler? Hvad er allerede rettet? Og hvordan dokumenterer vi det over for ledelse, kunder eller en cyberforsikring?
Vil du vide mere eller er du i tvivl om opsætningen eller sikkerheden på din hjemmeside er du velkommen til at kontakte os her