Hackerne kan komme ind, før hjemmesiden får ordet

To kritiske PHP-huller viser, hvor lidt en opdateret hjemmeside fortæller om sikkerheden nedenunder. I en dokumenteret serverkonfiguration kan angrebet ramme, før hjemmesidens egen kode begynder at køre.

Du kan have opdateret din hjemmeside og stadig mangle den opdatering, der lukker et alvorligt sikkerhedshul.

Det er den ubehagelige lære af PHP’s sikkerhedsudgivelse den 21. oktober. PHP er en motor på serveren, som mange hjemmesider bruger til at behandle forespørgsler og skabe de sider, vi ser i browseren. Når fejlen ligger i motoren, hjælper det ikke nødvendigvis at reparere hjemmesidens egne funktioner.

WordPress gjorde forskellen usædvanligt tydelig i sin advarsel: Der var ingen WordPress-opdatering planlagt til disse huller. Det var PHP, der skulle opdateres.¹

Motoren bag en stor del af nettet

PHP er langt fra en niche. Den 23. oktober målte W3Techs sproget på 69,3 procent af de hjemmesider, hvor tjenesten kunne identificere sproget på serversiden. Det er omtrent syv ud af ti i den målte gruppe. Tallet gælder hverken al internettrafik eller samtlige hjemmesider, og det siger intet om, hvor mange der har installeret sikkerhedsrettelsen.²

Man møder PHP gennem systemer som WordPress og TYPO3, også uden at se bogstaverne i adresselinjen. TYPO3’s egen dokumentation kræver eksempelvis en webserver, PHP og en database.³

Der er velkendte danske eksempler. Aarhus Universitet oplyser selv, at AU’s website er bygget i TYPO3. W3Techs registrerer også både TYPO3 og PHP på dmi.dk, hvor danskerne henter vejrudsigter og varsler.⁴⁵

De to navne illustrerer teknologiens rækkevidde. De er ikke dokumentation for, at universitetet eller DMI er blevet hacket, har kørt en ubeskyttet PHP-version eller har lukket på grund af denne sag. Det har vi ikke belæg for at skrive.

En etage under loginfeltet

En moderne hjemmeside består af flere lag. Et indholdssystem holder styr på artikler eller varer. Udvidelser leverer ekstra funktioner. Under dem arbejder den software, der fortolker koden og tager imod besøgendes forespørgsler.

Lagene kan blive vedligeholdt af forskellige mennesker. Du kan selv opdatere indholdssystemet, mens webhotellet bestemmer, hvilken PHP-version der kører. Sikkerheden afhænger af, at arbejdet bliver gjort hele vejen ned.

PHP-projektet advarede om, at de to fejl kan tillade fremmede at få serveren til at udføre kode uden først at logge ind. Det kaldes fjernkørsel af kode uden autentificering. Konsekvensen afhænger af de rettigheder og data, som den ramte proces har adgang til.⁶

Det mest opsigtsvækkende ligger i rækkefølgen. PHP’s egen fejlbeskrivelse dokumenterer en angrebsvej med Apache og modulet mod_php, hvor fejlen kan udløses under opstarten af en forespørgsel. På det tidspunkt er hjemmesidens egen kode endnu ikke begyndt at køre.⁷

Et loginfelt kan derfor ikke være hele forklaringen på, om en hjemmeside er beskyttet. Det skal selv have mulighed for at komme til orde.

Når oprydningen bliver indgangen

De to huller handler om computerens hukommelse. De har registreringsnumrene CVE-2026-109618 og CVE-2026-109619.

Det første opstår, når PHP håndterer mangel på hukommelse. Arbejdet kan blive afbrudt, mens interne data endnu kun er delvist gjort klar. Under oprydningen kan programmet derefter behandle ugyldige data, som om de var gyldige.⁷

Det andet handler om interne oplysninger, der overlever længere end det stykke hukommelse, de hører til. En senere forespørgsel hos den samme arbejdsproces kan støde på den gamle tilstand.⁸

Det er detaljer, de færreste hjemmesideejere normalt behøver kende. Men de forklarer noget væsentligt: Et sikkerhedshul kan ligge i det maskineri, der håndterer en fejl, og som brugeren aldrig ser.

PHP-projektet vurderer mod_php som den mest udsatte konfiguration, men advarer også om andre måder at drive PHP på, blandt dem PHP-FPM. Det ville være forkert at læse den dokumenterede Apache-angrebsvej som en frikendelse af alle andre opsætninger.⁶

Et hul er ikke et optalt indbrud

CERT-EU vurderede begge sårbarheder til 9,2 på en skala til 10 og anbefalede øjeblikkelig opdatering. Organisationen fremhævede også, at PHP kan være indbygget i andre produkter, så man ikke nødvendigvis finder det ved kun at lede efter almindelige hjemmesider.⁹

Det er alvorligt. Men en høj alvorlighedsgrad fortæller hverken, hvor mange servere der er overtaget, eller hvor stor en andel af danske virksomheder der er ramt. De gennemgåede varsler giver ikke et sådant dansk skadestal.

Denne sag kan heller ikke alene bevise, at al digital sikkerhed er blevet dårligere. Den viser en bestemt sårbarhed i vores måde at organisere den på: Vi skal kunne finde og rette en fælles komponent på tværs af mange produkter og leverandører.

De lukkede selv døren

Andre operatører har beskrevet, hvordan de midlertidigt trak tjenester ud af drift under PHP-alarmen.

Det nederlandske rejsebureau 333travel offentliggjorde en tidslinje for den 21. oktober: Klokken 12.40 blev hjemmeside, kundeportal og øvrige systemer taget offline. Hjemmesiden var tilbage klokken 17.36, og kundeportalen fulgte klokken 17.44. Ifølge virksomheden var pausen et bevidst sikkerhedsvalg, mens den ventede på og installerede rettelser.¹⁰

Wiki-operatøren Weird Gloop beskriver en anden løsning. Den slukkede webserverne bag sine wikier som en forholdsregel og oplyser, at pausen varede 13 timer. Alligevel kunne omkring 94 procent af sidevisningerne ifølge operatøren fortsat leveres fra cache, altså gemte kopier, uden at PHP eller databasen kørte.¹¹

Dermed kan en læser opleve et fungerende website, mens maskineriet bagved er standset. Det er også en grund til, at man ikke kan afgøre et systems sikkerhed ved blot at åbne forsiden.

De to hændelser er operatørernes egne redegørelser om forebyggende indgreb. De skal ikke forveksles med bekræftede hackerangreb. Også i Danmark advarede Ministeriet for Samfundssikkerhed og Beredskab den 21. oktober om, at hjemmesider og applikationer kunne være utilgængelige, indtil de var opdateret.¹²

Hvem tager telefonen, når rettelsen kommer?

Der findes rettelser. De blev udsendt i PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35. Nogle leverandører leverer også rettelser til deres egne pakker uden at følge de samme versionsnumre. Derfor er dokumentation fra leverandøren vigtigere end et versionsnummer betragtet alene.⁶

Samtidig har vedligeholdelse en udløbsdato. PHP’s officielle sikkerhedsstøtte til 8.2 slutter den 31. december 2026. En rettelse nu erstatter derfor ikke en plan for næste opgradering.¹³

For en forening eller en lille virksomhed er det relevante spørgsmål til webhotellet konkret: Er vores PHP-installation rettet mod netop disse to sårbarheder, og hvem har kontrolleret det?

Britiske NCSC anbefaler også at lede efter tegn på kompromittering i systemer, som ikke straks kan opdateres eller lukkes ned. En opdatering fjerner ikke automatisk en bagdør, som allerede kan være blevet installeret.¹⁴

PHP-hullerne gør dermed en skjult del af den digitale hverdag synlig. Vi køber en hjemmeside, men bliver afhængige af en hel vedligeholdelseskæde. Den kæde bør have navne, klare opgaver og nogen, der svarer, når en kritisk rettelse kommer.