PHP-sikkerhedshul 2026: Sådan kontrollerer og lapper du sårbare webtjenester

At vurdere alarmmeddelelsen korrekt

Påstanden om, at en sikkerhedsfejl i PHP kan berøre „halvdelen af internettet“, er en dramatiseret vinkel, men ikke et dokumenteret omfang. Der er ingen beviser for, at halvdelen af alle internettjenester er sårbare eller allerede er blevet kompromitteret. Den faktiske risiko er ikke desto mindre betydelig, da PHP anvendes som kørselsmiljø på mange hjemmesider, webshops, API'er og administrationsgrænseflader.

Det afgørende er ikke, om et websted bruger PHP, men hvilken PHP-version der behandler dets webforespørgsler. Sikkerhedsopdateringerne fra den 21. oktober 2026 vedrører generelt ikke-opdaterede installationer af de understøttede grene, forudsat at de behandler forespørgsler via en webservice. En lokal PHP-installation til udviklingsopgaver skal derfor vurderes anderledes end et kundeportal, der er tilgængeligt udefra.

Die Synlighed på internettet Hvor presserende det er, spiller en afgørende rolle. En offentligt tilgængelig webshop med formularer og upload-funktioner byder på flere mulige kontaktpunkter end en afskærmet intern tjeneste. Men heller ikke en intern tjeneste er automatisk sikker: VPN-adgang, kompromitterede konti eller andre systemer i netværket kan gøre den tilgængelig. Rækkevidde alene kan derfor ikke erstatte en teknisk risikovurdering.

Lige så vigtige er driftsform og Patch-stativ. PHP kan f.eks. køre via PHP-FPM, som et Apache-modul, via php-cgi eller integreret i et produkt. Flere domæner på samme server kan have forskellige versioner og opdateringsmetoder. En generel frifindelse af alle PHP-websteder ville være lige så forkert som antagelsen om, at hver installation er umiddelbart sårbar.

Hvad PHP-sårbarhederne gør det teknisk muligt at gøre

En Fjernkørsel af kode (RCE) betyder, at en hacker under visse betingelser kan udføre kode på et fjerntliggende system. Ifølge sikkerhedsmeddelelsen kræver disse PHP-sårbarheder ikke, at man først logger ind. Koden vil i første omgang blive udført med webprocessens rettigheder og ikke automatisk med ubegrænsede administratorrettigheder. De mulige konsekvenser afhænger derfor i høj grad af filrettigheder, adgangsdata og serverisolering.

CVE-2026-109618 vedrører fejlveje i Mangel på lagerplads. Hvis PHP afbryder en anmodning på grund af en »out-of-memory«-tilstand, kan interne datastrukturer forblive ufuldstændige. Hvis sådanne tilstande genbruges under oprydningen af anmodningen, kan der opstå hukommelsesskader. Den officielle beskrivelse nævner især multipart-anmodninger, filoverførsler og hukommelsesforbruget ved parsning af indlejrede indtastninger som relevante tekniske sammenhænge.

CVE-2026-109619 vedrører derimod en intern tilstand, der er knyttet til en forespørgsel, og hvis hukommelse allerede er blevet frigivet. Hvis en genbrugt worker derefter behandler en yderligere forespørgsel, kan PHP få adgang til denne forældede tilstand, inden den normale initialisering træder i kraft. Sikkerhedsmeddelelsen henviser blandt andet til upload-forløbet for sessioner og fejlstier. Dette beskriver fejltypen og er ikke en vejledning i udnyttelse.

• Dette kan berøre webforespørgsler via PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP og LiteSpeed.
• Fejlene ligger i PHP-kørselstiden, ikke primært i WordPress, Joomla, Shopware, temaer eller enkelte plugins.
• CMS og rammeværker påvirker de funktioner, der er tilgængelige, såsom filoverførsler, men erstatter ikke en opdatering af fortolkeren.

Hvorfor ikke alle installationer udgør den samme risiko

Om en tjeneste reelt er udsat for risiko, afhænger af flere faktorer. Først og fremmest tæller en PHP-web-runtime uden opdateringer og en tilgængelig webtjeneste. Dernæst tæller driftsformen, genbrugte processer, funktioner til upload eller komplekse formularer samt rettighederne for webproceskontoen. En tjeneste med omfattende skriveadgang til webfiler eller adgang til andre tjenester kan have alvorligere konsekvenser end et strengt isoleret projekt.

I Apache med mod_php understreger PHP-projektet især risikoen: Et dokumenteret angreb kan udløses allerede inden den egentlige applikationskode udføres. Selv et velvedligeholdt CMS beskytter i så fald ikke mod sårbarheden under kørsel. Det betyder ikke, at PHP-FPM, php-cgi, FrankenPHP eller LiteSpeed betragtes som ufarlige; de skal ligeledes prioriteres i kontrollen, hvis de ikke er opdateret.

Derudover kræver produkter med indlejret PHP. Dette kan omfatte containerbilleder, apparater, NAS-administrationssystemer eller netværksprodukter, hvor brugergrænsefladen internt anvender PHP. I sådanne tilfælde viser en kommando på værten ofte ikke den faktisk anvendte runtime. En opdatering af operativsystemet løser heller ikke automatisk et sårbart PHP-komponent i et billede eller et producentprodukt.

En firewall, en webapplikationsfirewall eller strenge upload-begrænsninger kan gøre det vanskeligere at sende enkelte forespørgsler og dermed begrænse angrebsfladen. De er dog ikke en erstatning for selve rettelsen, da de ikke korrigerer den fejlbehæftede hukommelses- og tilstandsstyring i fortolkeren. Selv et fejlfrit CMS er afhængigt af et sikkert kørselsmiljø. Det er derfor afgørende at kontrollere og opdatere patch-status for den PHP-version, der rent faktisk behandler webforespørgslerne.

Sammenlign opdateringsstatus og supportstatus

For de to sikkerhedshuller er det først og fremmest patch-status inden for den anvendte PHP-gren, der er afgørende. PHP-projektet angiver konkrete rettede udgivelser for de understøttede serier. Tidligere opdateringsniveauer i samme serie betragtes som berørte; en opgradering til den angivne eller en nyere version af denne gren er den anbefalede fuldstændige løsning.

En Patch-opdatering forbliver inden for samme udviklingsserie, f.eks. fra 8.3.35 til 8.3.36. Den skal levere sikkerhedsrettelsen og har en snævrere kompatibilitetsramme end et skift fra 8.2 til 8.4. Sidstnævnte er en migration: Afhængigheder, udvidelser, applikationskode og eventuelt implementeringen skal kontrolleres separat i den forbindelse.

PHP 8.2 kan fortsat bruges til akut fejlretning, forudsat at der kører mindst version 8.2.35. Denne gren mister dog sin support den 31. december 2026. Derfor bør driften ikke forblive på denne midlertidige version: Planlæg overgangen til en gren med længere support, efter at applikationen er blevet testet for kompatibilitet i et passende miljø.

I forbindelse med PHP 8.1 og ældre versioner er der grund til særlig forsigtighed. PHP-projektet stiller ikke en regelmæssig, opdateret udgave til rådighed til dette formål; minimale backports af kildekoden kan ikke sidestilles med en almindeligt tilgængelig, vedligeholdt pakke. En sikkerhedsbackport, der er dokumenteret af operativsystemudbyderen, kan være passende, men kræver dokumentation i en sikkerhedsmeddelelse eller i pakkens changelog. Mangler denne dokumentation, er en migrering nødvendig i stedet for en ren versionsopdatering.

Kontroller den faktiske driftstid på nettet

Versionskontrollen begynder med en statusopgørelse, men må ikke stoppe ved shell’en. På en selvadministreret server viser følgende kommandoer versionen af den PHP-kommando, der kaldes der, samt de konfigurationsfiler, som dette kald finder. De ændrer hverken pakker eller konfiguration og er derfor velegnede som et første, risikofrit kontroltrin.

php -v
php --ini

Udskriften beskriver kun den, der kaldes via denne shell-kommando CLI-kørselstid. En hjemmeside kan derimod køre via PHP-FPM, Apache med mod_php, php-cgi eller en container. Dette web-runtime-miljø kan anvende en anden PHP-version og andre konfigurationsfiler end kommandoen php -v på værten. Det er den proces, der behandler de faktiske HTTP-anmodninger, der er afgørende for sikkerhedsvurderingen.

I Managed Hosting skal du derfor i kundepanelet kontrollere den valgte PHP-version pr. projekt eller domæne og om nødvendigt tjekke, om den leverede tjeneste er opdateret med den seneste patch. Ved flere domæner skal hver tildeling kontrolleres separat: Et hoveddomæne kan allerede bruge den opdaterede version, mens en webshop, en staging-instans eller et underdomæne stadig bruger en ældre fortolker.

På servere med PHP-FPM hører servicekonfiguration, pakkebestand og implementeringsdokumentation sammen. I containermiljøer skal du desuden kontrollere det faktisk implementerede image og ikke blot et lokalt build-manifest. Det afgørende er, hvilken revision der modtager webforespørgsler i den kørende pod eller container; et opdateret basisimage beskytter ikke en ældre instans, der allerede kører.

Planlægning af opdateringsveje efter driftsform

Den rette opdateringsmetode afhænger af, hvem der leverer fortolkeren, og hvor den kører. Først når dette ansvarsområde er afklaret, kan man pålideligt afgøre, om der er behov for et panelskift, en pakkeopdatering, et nyt image eller en producentopdatering. Den følgende klassificering skelner mellem disse tilfælde uden at sidestille driftsformerne med hensyn til deres risiko.

Ved shared hosting bør udbyderen stille den sikre patch-status til rådighed for den valgte PHP-serie; operatøren kontrollerer derefter applikationen. Ved PHP-FPM eller mod_php opdaterer administrationen som regel pakkerne og genstarter derefter den faktisk relevante tjeneste på en kontrolleret måde. En ren genstart uden installation af en rettelse erstatter ikke opdateringen.

Linux-distributioner leverer ofte sikkerhedsrettelser som Backport. I så fald kan det synlige pakkeversionsnummer afvige fra udgivelserne på php.net, selvom rettelsen er inkluderet. Du bør derfor ikke kun sammenligne tegnstrenge som „8.4.26“, men også læse distributørens sikkerhedsmeddelelse og ændringslog. PHP-projektet påpeger, at distributioner og LTS-udbydere kan modtage patches.

Containere kræver en særskilt proces: man skal enten opbygge et korrigeret image eller hente det fra udbyderen, implementere det og erstatte gamle instanser. Når det gælder NAS-grænseflader, netværksenheder eller færdige webapplikationer, ligger rettelsen derimod hos producentens produkt. En patch til værtsoperativsystemet når ikke nødvendigvis den indlejrede fortolker; derfor er det stadig uundværligt at foretage en opgørelse og følge producentens anvisninger.

Hasteforanstaltninger uden falsk tryghed

På patch-dagen skal du først og fremmest lave en oversigt over dine systemer: domæner, API’er, administrationsgrænseflader, containere og produkter, der muligvis indeholder indlejret PHP. Notér for hver tjeneste, hvordan den kører på nettet, hvilken opdateringsvej der anvendes, og hvilken PHP-runtime der rent faktisk bruges. Derefter prioriteres alle offentligt tilgængelige eller forretningskritiske tjenester, ikke blot den server med det mest iøjnefaldende versionsnummer.

Installer derefter den sikkerhedsopdatering, der er frigivet af webhost, Linux-distributør, image- eller produktproducent. For de understøttede PHP-grene udgør opdateringen til den korrigerede patch-status den fuldstændige løsning; en WAF, upload-regler eller en genstart af webserveren kan ikke erstatte den. Planlæg processen således, at opdateringer af pakker, images eller fra producenten dokumenteres på en overskuelig måde og kan spores tilbage i tilfælde af problemer.

Efter opdateringen skal alle tidligere medarbejdere afsluttes og erstattes af processer, der påviseligt har indlæst den opdaterede runtime. Brug kun en genindlæsning, hvis den pågældende tjenesteadministration sikrer denne fuldstændige udskiftning; ellers er en kontrolleret genstart nødvendig. Kontroller derefter processtarttidspunkter, tjenestestatus eller den internt fastlagte web-kørselstid, i stedet for blot at antage, at udskiftningen er gennemført. Ved containere skal du rulle det korrigerede image ud og fjerne alle gamle instanser.

Kontroller derefter centrale anvendelsesveje såsom login, formularer, upload, checkout og API’er. Testene viser, om applikationen og udvidelserne fungerer med den opdaterede patchstatus; de beviser dog hver for sig hverken, at alle arbejdsprocesser er udskiftet, eller at der ikke tidligere har været tale om en sikkerhedsbrud. Disse punkter skal vurderes separat gennem drifts- og sikkerhedskontrol.

Hvis det ikke er muligt at installere en patch med kort varsel, kan enkelte indstillinger begrænse kendte angrebsveje, men ikke sikre fuldstændig sikkerhed. Deaktivering af upload-statusindikatoren skal være aktiv, inden en anmodning parsers. Kontroller på forhånd, om applikationer eller brugergrænseflader har brug for denne fremskridtsindikator, og genstart derefter alle relevante PHP-workere. Kontroller derefter, at ingen gamle processer fortsætter med den tidligere indstilling.

session.upload_progress.enabled = 0

Konservative grænser for POST-data og andre indstillinger, der er nævnt i sikkerhedsmeddelelsen, kan ligeledes kun delvist reducere angrebsfladen. Senere læste .user.ini-filer eller en ini_set() Inden for selve applikationen er disse tiltag ikke tilstrækkelige. Betragt sådanne foranstaltninger som en midlertidig risikoreduktion, og hold fast i sikkerhedsopdateringen som målet.

Dette skal skelnes fra den almindelige administration af gemte møder. Bidraget til Garbage collection i PHP-sessioner forklarer, hvordan oprydning, filadgang og worker-processer samvirker under normal drift. Denne driftsoptimering afhjælper dog ikke de her omtalte sårbarheder og erstatter hverken den korrigerede PHP-patchversion eller den efterfølgende udskiftning af de kørende processer.

Efter opdateringen: Kontroller driften og eventuelle afvigelser

En vellykket pakkeopdatering beviser i første omgang kun, at filer eller pakker er blevet installeret. Den bekræfter hverken, at webprocessen har indlæst den nye runtime, eller at applikationen fungerer fejlfrit med den. Kontroller derfor efter genstart den web-runtime, der er relevant for tjenesten, og dokumenter tidspunkt, version, den genstartede tjeneste samt resultatet af funktionskontrollen.

Funktionskontrollen bør omfatte reelle kerneprocesser: vigtige offentlige sider, login og logout, afsendelse af formularer, filoverførsel, checkout eller booking samt API-endepunkter og baggrundsopgaver. Test kun de processer, du har adgang til, og brug om muligt testdata, der er beregnet til dette formål, når du tester produktive webshops. Kontroller samtidig webserver-, PHP- og applikationslogfiler for nye fejl, gentagne nedbrud eller uventede statuskoder.

En ny start er nødvendig for at skabe bæredygtige processer og Arbejder at indlæse med opdateret kode, men skaber ikke i sig selv en rettelse. Uden en installeret opdatering forbliver sårbarheden. Ved høj belastning bør vedligeholdelsesvinduet vælges således, at forespørgsler kan behandles i rækkefølge, og at virkningerne af en genstart af en worker forbliver synlige.

Hvor stor indflydelse en kontrolleret genstart har på gennemstrømningen, afhænger af antallet af PHP-processer og deres udnyttelsesgrad. I forbindelse med planlægningen er det en fordel at tage højde for køer, igangværende opgaver og kritiske transaktioner i stedet for at afslutte processer på en ukoordineret måde. Vejledningen At forstå PHP-workers forklarer disse processers rolle ved parallelle dynamiske forespørgsler.

Hvis der opstår problemer efter patchen, skal du skelne mellem kompatibilitetsfejl i applikationen og en ufuldstændig udrulning. Sammenlign konfigurationen, de aktiverede udvidelser og web-runtime med tilstanden før vedligeholdelsen. En tilbageførsel må ikke medføre, at en offentligt tilgængelig tjeneste forbliver permanent i en sårbar tilstand; find i så fald hurtigt en kompatibel, patchet opdateringsvej.

Prioriter gamle og skjulte PHP-installationer

Der skal lægges særlig vægt på systemer, hvor PHP ikke er synligt som en bevidst installeret runtime: Docker-images, virtuelle apparater, NAS- og netværksgrænseflader samt færdige softwareprodukter. En opdatering af værten opdaterer hverken automatisk et container-image eller den interne runtime, der følger med et producentprodukt. Spørg derfor producenten specifikt om deres vurdering og om en sikkerhedsopdatering til det konkrete produkt.

Når det gælder gamle grene, skal der skelnes klart mellem tre tilfælde. En PHP-udgave, der understøttes som standard, modtager de sikkerhedsopdateringer, der udgives af PHP-projektet. En backport fra en distributør eller udbyder kan indeholde rettelsen på trods af et afvigende synligt versionsnummer, men skal være dokumenteret via udbyderens sikkerhedsmeddelelse eller changelog. Selvvedligeholdt kildekode kræver derimod eget ansvar for kompilering, test og drift; den er ikke en fuldgyldig erstatning for en regulær opdateringskanal.

PHP 8.1 og ældre grene modtager ikke længere regelmæssige upstream-udgivelser. Der findes ganske vist en korrigeret patch til PHP 8.2, men denne gren udløber ved udgangen af 2026. Brug en tilgængelig rettelse til den aktuelle situation, men planlæg desuden en testet Migration til en gren, der understøttes i længere tid.

1. Opdater først offentligt tilgængelige tjenester med en PHP-runtime, der ikke er opdateret, især hvis der er adgang til upload- eller administrationsfunktioner.
2. Apache med mod_php og forretningskritiske webshops, API’er eller kundeportaler skal behandles umiddelbart derefter; den officielle sikkerhedsmeddelelse fremhæver et særligt kritisk risikofokus for mod_php.
3. Registrer containere, apparater og tredjepartsprodukter på baggrund af images, inventar og producentstatus; manglende synlige PHP-pakker er ikke et tegn på, at alt er i orden.
4. Isoler tjenester, der ikke understøttes eller ikke kan patchees rettidigt, og begræns adgangen til dem, samtidig med at der planlægges en obligatorisk udskiftning, opgradering eller migrering.

Netværkssegmentering, obligatorisk brug af VPN eller restriktive adgangsregler kan give lidt ekstra tid, hvis administrationsgrænsefladerne ikke kan opdateres med det samme. De er dog kun Overgangsforanstaltninger, fordi interne brugerkonti, kompromitterede enheder og forkert konfigurerede delingsindstillinger fortsat kan udgøre angrebsveje. Hvis der ikke tilbydes en rettelse til et produkt, eller hvis PHP-grenen permanent er uden for support, er udskiftning eller migrering den mest pålidelige løsning.