Fra it-praksis

PHP2Shell: to kritiske PHP-sårbarheder og vores reaktion

To kritiske PHP-sårbarheder kræver opdateringer og en præcis gennemgang af systemoversigten. Sådan kombinerer DAXS vurdering, adgangsbegrænsning og teknisk kontrol.

IT-sikkerhed
DAXS-gravhunden med abstrakte beskyttelseslag og et orange opdateringssymbol.

Siden forhåndsvarslet den 20. oktober har PHP2Shell stået på mange IT-ansvarliges kontrollister. Den 21. oktober 2026 offentliggjorde PHP-projektet sikkerhedsopdateringer til to kritiske sårbarheder. For DAXS betød det at vurdere meldingerne teknisk, finde potentielt berørte tjenester og prioritere tiltag efter den faktiske tilgængelighed. Det afgørende er, hvad der reelt kører på det enkelte system, ud over at en opdateringsopgave er afsluttet.

Hvad der er offentliggjort

Sårbarhederne CVE-2026-109618 og CVE-2026-109619 kan gøre det muligt at afvikle kode uden forudgående autentificering. Forhåndsvarslet angiver CVSS v4.0 9,2 for begge. Den kritiske vurdering kræver hurtig undersøgelse, men beviser ikke, hvilken konkret kundeinstallation der er blevet angrebet med succes.

PHP-projektet angiver de rettede versioner 8.5.12, 8.4.27, 8.3.36 og 8.2.35. Pakker, som vedligeholdes af distributioner, kan få sikkerhedsrettelser som backports. Et lavere vist grundversionsnummer beviser derfor hverken manglende beskyttelse eller en vellykket rettelse i sig selv. Den præcise pakke, leverandørens meddelelse og det faktisk anvendte afviklingsmiljø er afgørende.

Meddelelserne omfatter forskellige forbindelser til webservere. PHP fremhæver risikoen ved Apache med mod_php; det er ikke en generel frikendelse af PHP-FPM eller andre driftsformer. Komponenter, udvidelser og indstillinger vurderes særskilt for hvert miljø. Et produktnavn i en systemoversigt er ikke tilstrækkeligt.

Tidslinje: forhåndsvarsel den 20. oktober, PHP-opdateringer den 21. og fortsatte individuelle kontroller den 22. oktober 2026.
Fra advarsel til efterprøvelig reaktion

Vores første spørgsmål: hvor kører PHP faktisk?

Vi sammenholdt de tilgængelige meldinger med den eksisterende viden om systemerne. Oversigten omfatter offentlige websites, administrationsflader, ekstra applikationer og tjenester, der leverer PHP som del af produktet. Prioriteringen afhænger af ekstern adgang, tjenestens formål og ansvaret for opdateringen. Uklare poster får en konkret kontrolopgave.

Vi skelner mellem den installerede pakke og den aktive webtjeneste. Flere PHP-versioner kan eksistere side om side. Selv et vellykket opdateret kommandolinjeprogram viser ikke, hvilket afviklingsmiljø en bestemt webserverproces bruger. Efter en ændring skal de berørte tjenester og deres effektive indstillinger derfor kontrolleres på en sporbar måde. En offentligt tilgængelig diagnoseside er ikke en permanent løsning.

Oversigten skal også omfatte mindre iøjnefaldende systemer. Webadministration kan være en sekundær funktion i en enhed og stadig skabe en ekstra angrebsflade. Om den overhovedet bruger PHP og kræver en rettelse, er et teknisk spørgsmål. Alene en webgrænseflades tilstedeværelse beviser ikke, at enheden er berørt.

Opdater, kontroller virkningen og registrer åbne punkter

Arbejdet begynder med registrering og vurdering. Derefter installeres tilgængelige sikkerhedsopdateringer efter prioritet. Kontrollen omfatter pakkeversion, nødvendige genstarter, effektiv konfiguration og påkrævede applikationsfunktioner. De ansvarlige skal kunne se, hvilke tjenester der er kontrolleret, og hvor et leverandørsvar, en egnet pakke eller en teknisk godkendelse stadig mangler.

Hvis en specialiseret tjeneste ikke straks kan opdateres, undersøger vi først, hvilke direkte offentlige adgangsveje der faktisk er nødvendige. Unødvendig internetadgang kan fjernes midlertidigt. Berettiget intern brug kan eventuelt fortsætte gennem passende isolerede adgangsveje. Det er et bevidst begrænset tiltag, hvis virkning og driftsmæssige følger skal kontrolleres; det gør ikke automatisk den underliggende software fejlfri.

En opgave er ikke afsluttet, blot fordi opdateringen er startet. Der skal være en sporbar afslutning eller et navngivet åbent punkt med en ansvarlig. Begrænses adgangen, kontrolleres den resterende tilgængelighed også. Installeres en rettelse, følger kontrol af den tjeneste, der faktisk anvendes. Begge dele hører til i en vedligeholdt driftsdokumentation.

Kontrolresultatet omfatter også softwarens leverancekanal. Ved en installation, som vedligeholdes af operativsystemet, sammenholdes distributionens sikkerhedsmeddelelse med den installerede pakke. Ved et medleveret afviklingsmiljø er produktleverandørens oplysninger afgørende. Det forebygger fejlfortolkning af et versionsnummer alene. Er dokumentationen utilstrækkelig, forbliver punktet åbent med et næste kontroltrin. En grøn status uden efterprøveligt grundlag ville være misvisende.

Beslutningsforløb: registrer tjenesten, find en egnet rettelse, opdater eller begræns unødvendig offentlig adgang, og kontroller derefter virkningen og overvåg åbne punkter.
Kontroller opdatering og adgang hver for sig

Hvad WAF, proxy, firewall og adskilte netværk bidrager med

WAF, reverse proxy, firewall og VLAN bruges allerede til at begrænse adgang og dataveje. En firewall styrer tilladte forbindelser, en proxy samler defineret webadgang, og adskilte netværk hjælper med at afgrænse tilladt kommunikation. Det er værdifulde funktioner, men de fjerner ikke enhver sårbarhed i en PHP-proces.

PHP2Shell må især ikke fremstilles som fuldt løst af en WAF foran applikationen eller inde i den. PHP-projektet angiver opdatering som den fulde løsning; midlertidige begrænsninger dækker kun bestemte angrebsveje. Vi vurderer derfor disse lag sammen med opdateringsstatus og undersøger, om en anden vej kan omgå den tilsigtede adgangsbegrænsning.

Forenklet lagmodel med internet, firewall, adskilte netværk, proxy eller WAF og PHP-applikationen. Adgangskontrol erstatter ikke en PHP-sikkerhedsopdatering.
Beskyttelseslag og softwarevedligeholdelse hører sammen

Isolerede test og AI understøtter den faglige vurdering

Til den tekniske vurdering brugte vi også egne isolerede testmiljøer. Claude og OpenAI Codex hjalp med research og forberedelse af miljøerne. Faglig vurdering og pålidelige tekniske kilder var afgørende. Et plausibelt AI-svar erstatter hverken dokumentation for den installerede version eller kontrol af en virksom indstilling.

Observation er også nødvendig efter opdateringen. Usædvanlige fejl, uventede processer og forbindelser vurderes i forhold til normal systemadfærd. En installeret rettelse beviser ikke bagudrettet, at der ikke skete noget før. Omvendt er en enkelt usædvanlig logpost ikke et pålideligt bevis på et vellykket angreb.

Sæt offentlige meddelelser i sammenhæng

Universitetet i Wiens meddelelse om begrænsninger i centrale IT-tjenester viser, hvor indgribende forebyggende tiltag kan være. Den opdaterede meddelelse oplyser, at de fleste tjenester igen er tilgængelige. Sådanne offentlige oplysninger hjælper med at forklare situationen, men beskriver ikke forholdene i andre organisationer eller et konkret miljø, som DAXS understøtter.

Leverandørmeddelelser skal også passe til den pågældende tjeneste. En leverandør kan skelne mellem sine produkter og en hostet portal, som vedkommende driver. En udtalelse om ét produkt gælder ikke automatisk alle tredjepartsapplikationer. For OPNsense, FreePBX, Sophos eller en konkret gateway er præcis version, medleverede komponenter, leverandørvejledning og faktisk adgangssituation derfor afgørende.

Forberedelse gør reaktionen efterprøvelig

En brugbar systemoversigt, tydelige ansvar og forberedte opdateringsveje gør håndtering af kritiske advarsler lettere. Vi offentliggør hverken en udokumenteret opdateringsprocent eller en generel frikendelse af alle systemer. Sporbare individuelle kontroller og fortsat håndtering af åbne sager er afgørende. Fredag ser vi på, hvordan AI kan hjælpe med at få let oversete enheder med på kontrollisten.

Tal med os om sikkerhed og opdateringsstyring

Mere om systematisk sikkerhedsvurdering