Ejere og driftsansvarlige for websites med PHP bør kontrollere, om deres servere har fået de seneste sikkerhedsrettelser. To kritiske fejl i selve PHP kan under bestemte forhold gøre det muligt for en angriber at få kørt kode på en webserver. Rettelserne er tilgængelige, og den australske cybersikkerhedsmyndighed ACSC har den 22. oktober opdateret sin advarsel med en opfordring til at installere dem.

Det er ikke en fejl i én bestemt hjemmeside eller et enkelt plugin. PHP er et programlag på serveren, som udfører kode bag blandt andet dynamiske websites. Derfor kan ansvaret for opdateringen ligge et andet sted end hos den person, der normalt redigerer artikler, produkter eller billeder på siden.

I ACSC’s opdaterede advarsel er anbefalingen at finde PHP-installationerne i organisationens miljø, følge den aktuelle vejledning, anvende sikkerhedsrettelser og holde øje med mistænkelig aktivitet. Advarslen blev oprindeligt offentliggjort den 21. oktober; dagens opdatering understreger, at rettelserne nu er udgivet.

Fire rettede versioner

PHP-projektets meddelelse fra 21. oktober angiver versionerne 8.5.12, 8.4.27, 8.3.36 og 8.2.35 som sikkerhedsudgivelserne. Projektet beskriver risikoen som relevant for PHP-installationer, der modtager webforespørgsler, og nævner blandt andet PHP-FPM, Apache mod_php, php-cgi, FrankenPHP og LiteSpeed.

Det betyder ikke, at alle disse opsætninger kan angribes på præcis samme måde. Projektet fremhæver mod_php som særligt udsat. For administratorer er konklusionen imidlertid, at valget af en anden måde at køre PHP på ikke i sig selv er dokumentation for, at opdateringen kan undværes.

Versionsnummeret skal også læses i sammenhæng med leverandøren. Linux-distributioner og leverandører med langtidsvedligeholdelse kan indarbejde en sikkerhedsrettelse i deres egen pakke uden at skifte til præcis samme nummer som PHP-projektets udgivelse. Det relevante spørgsmål er derfor, om den installerede pakke indeholder rettelserne – ikke kun hvilket kort versionsnummer et kontrolpanel viser.

Fejl i hukommelseshåndteringen

Den første sårbarhed, CVE-2026-109618, handler om, hvad der sker, når PHP ikke kan tildele den nødvendige hukommelse. Ifølge projektets tekniske sikkerhedsmeddelelse kan en afbrudt forespørgsel efterlade interne datastrukturer i en tilstand, hvor den efterfølgende oprydning bliver farlig.

Problemet er altså ikke blot, at et website kan vise en fejl, hvis det løber tør for hukommelse. Fejlen i håndteringen kan åbne mulighed for fjernkørsel af kode. For Apache mod_php beskriver meddelelsen et demonstreret angreb via en HTTP-forespørgsel uden forudgående login.

Koden kører i den sammenhæng med webprocessens rettigheder. Det er en alvorlig adgang, men ikke det samme som automatisk at få alle administratorrettigheder på maskinen. Den konkrete konsekvens afhænger også af, hvilke filer, oplysninger og forbindelser processen har adgang til.

For PHP-FPM skelner samme meddelelse mellem en vurderet sårbar kodevej og en fuldt demonstreret udnyttelse. Det er en vigtig præcision: En teknisk vurdering af risiko og et fungerende angreb i en bestemt opsætning er ikke identiske former for dokumentation.

Når oplysninger hænger ved mellem forespørgsler

Den anden sårbarhed, CVE-2026-109619, vedrører intern tilstand, der overlever fra én forespørgsel til den næste. I den særskilte sikkerhedsmeddelelse om denne fejl beskrives referencer til hukommelse, som allerede er frigivet, men som senere kan blive brugt igen.

En webserver behandler mange forespørgsler over tid. Når en proces genbruges, er det afgørende, at oplysninger fra det tidligere arbejde bliver ryddet korrekt op, før næste opgave begynder. Her ligger problemet i PHP’s interne håndtering, ikke nødvendigvis i en fejl, hjemmesideejeren selv har skrevet ind i sit program.

Også ved denne sårbarhed afhænger den konkrete angrebsvej af opsætningen. Meddelelsen beskriver en bekræftet vej for mod_php og en applikationsafhængig vej for PHP-FPM. Den bør derfor ikke læses som et løfte om, at alle FPM-installationer er upåvirkede.

Hvem skal handle på et webhotel?

For en mindre virksomhed eller forening kan det vigtigste første spørgsmål være organisatorisk: Hvem driver PHP-miljøet? På et administreret webhotel vil det ofte være hostingfirmaet, mens en organisation med egne servere typisk har en intern administrator eller en ekstern driftspartner.

En brugbar henvendelse til leverandøren er derfor konkret: Er de to sårbarheder rettet i det miljø, som netop vores website bruger? En generel besked om, at en leverandør arbejder på opdateringer, siger ikke nødvendigvis, om alle kunders miljøer allerede er behandlet.

Et CMS og PHP er forskellige softwarelag. En grøn status for opdateringer inde i hjemmesidens administrationspanel kan derfor ikke alene bruges som bevis for, at serverens PHP er rettet. Omvendt erstatter en PHP-opdatering heller ikke vedligeholdelse af indholdssystemet og dets udvidelser. De to opgaver supplerer hinanden.

En rettelse og en undersøgelse er to forskellige ting

ACSC anbefaler også overvågning af de berørte applikationer og tilknyttede systemer. Det peger på en vigtig skelnen: At lukke en sårbarhed handler om at fjerne en mulig adgangsvej. At undersøge, om den allerede har været misbrugt, er en anden opgave.

En organisation bør derfor ikke konkludere, at der har været et indbrud, alene fordi en sårbar version har været installeret. Men den bør heller ikke bruge en gennemført opdatering som dokumentation for, at tidligere aktivitet nødvendigvis var harmløs. Den vurdering kræver konkrete oplysninger om det berørte miljø.

For almindelige besøgende er dette først og fremmest en sag for dem, der driver tjenesten. Det er ikke en fejl, som kan lukkes ved at opdatere browseren på brugerens egen computer. Ansvaret følger her serverens software og drift.

Den praktiske nyhed er dermed både alvorlig og afgrænset: Der findes rettelser, og administratorer kan handle nu. Det afgørende er at få bekræftet den konkrete installations status frem for at forveksle et velfungerende website med et dokumenteret opdateret website.