PHP2Shell: Hvad betyder sårbarheden for organisationer, og hvad bør I gøre?

PHP2Shell viste, hvor hurtigt en kritisk sårbarhed i udbredt software kan udvikle sig til en reel sikkerhedsrisiko. Her får du overblikket over, hvad der skete, hvorfor sårbarheden er vigtig, og hvad organisationer bør gøre for at beskytte deres systemer.

I oktober blev offentlige tjenester, kommunale hjemmesider, biblioteker og webshops i Europa og andre dele af verden taget offline med få timers mellemrum. Ikke nødvendigvis fordi de var blevet hacket, men som en sikkerhedsforanstaltning.

Årsagen var en alvorlig sårbarhed i PHP, det programmeringssprog, der ligger bag en stor del af verdens hjemmesider. Besøgende ser det ikke, men PHP er med til at få hjemmesider og webapplikationer til at fungere ved blandt andet at håndtere login, indkøbskurve, formularer og forbindelser til underliggende databaser.

Sårbarheden, kaldet PHP2Shell, kunne give en angriber mulighed for at overtage kontrollen med en webserver uden en adgangskode. Da oplysninger om sårbarheden blev lækket, før en rettelse var klar, anbefalede sikkerhedsmyndigheder i flere lande, at organisationer tog sårbare tjenester offline, indtil de kunne blive opdateret.

Der opdages løbende nye sikkerhedssårbarheder, men de fleste rammer et enkelt produkt eller en mere afgrænset gruppe af systemer. PHP2Shell ramte derimod software, som anvendes af millioner af hjemmesider. Derfor kunne et meget stort antal systemer potentielt være sårbare på samme tid.

En rettelse blev efterfølgende udsendt, men hændelsen peger på en større udfordring: Organisationer skal både vide, hvor sårbar software befinder sig, kunne reagere hurtigt og undersøge, om sårbarheden allerede er blevet udnyttet.

Hvorfor er PHP2Shell vigtig på længere sigt?

Sikkerhedsforskere fra Calif, Wiz og OpenAI opdagede sårbarheden i august ved hjælp af AI-værktøjer som led i et OpenAI-initiativ, der har til formål at identificere svagheder i udbredt software.

Problemet havde eksisteret i PHP i årevis, men blev tidligere anset for at være vanskeligt at udnytte. AI gjorde imidlertid arbejdet væsentligt lettere. Planen var at offentliggøre detaljerne sammen med en rettelse, så organisationer fik mulighed for at opdatere deres systemer. Oplysningerne blev imidlertid lækket, før rettelsen var klar.

Hændelsen illustrerer en bredere udvikling. AI-værktøjer kan hjælpe sikkerhedsforskere med at identificere sårbarheder hurtigere, men de samme teknologier kan også gøre det lettere for angribere at finde og udnytte svagheder.

Det stiller større krav til organisationers evne til hurtigt at identificere berørte systemer, installere sikkerhedsopdateringer og opdage tegn på kompromittering.

Er vi berørt?

Hvis jeres organisation anvender systemer baseret på PHP, bør I undersøge, om de berørte versioner findes i jeres IT-miljø.

Udfordringen er ofte at afdække, hvor PHP faktisk anvendes. Det er sjældent begrænset til den offentlige hjemmeside. PHP kan også indgå i interne applikationer, webshops, intranet eller software fra eksterne leverandører, som organisationen ikke selv kan opdatere.

Når en kritisk sårbarhed bliver offentliggjort, er det derfor ikke nødvendigvis selve opdateringen, der er den største udfordring. Det kan være manglen på overblik over, hvilke systemer og komponenter der er berørt.

Er vi blevet kompromitteret?

At installere en sikkerhedsopdatering løser sårbarheden fremadrettet, men fortæller ikke nødvendigvis, om den allerede er blevet udnyttet.

Angribere forsøgte at udnytte PHP2Shell, før rettelsen blev frigivet. Derfor kan et system potentielt være blevet kompromitteret, selv om det efterfølgende er blevet opdateret.

Hvis I ikke allerede har kontinuerlig sikkerhedsovervågning, bør I derfor gennemgå relevante systemer for tegn på usædvanlig aktivitet fra perioden, hvor sårbarheden kunne udnyttes.

NetNordics Security Operations Center har overvåget kundemiljøer i mere end et årti. Det giver os overblik over, hvor sårbare komponenter befinder sig i de miljøer, vi overvåger, og mulighed for at identificere usædvanlig aktivitet.

Vi har gennem årene set flere eksempler på, at sårbarheder i udbredt software bliver forsøgt udnyttet i stor skala. Vores detekteringssystemer er derfor udviklet til blandt andet at identificere angreb, der forsøger at udnytte sårbarheder i webapplikationer.

Hvad bør I gøre?

De konkrete tiltag afhænger af jeres IT-miljø, men for PHP2Shell bør organisationer grundlæggende arbejde i denne rækkefølge:

• Kortlæg, hvor PHP anvendes. Undersøg både interneteksponerede tjenester, interne systemer og software fra eksterne leverandører.
• Opdater til en rettet version. Ældre versioner, PHP 8.1 og tidligere, opdateres ikke længere af PHP-projektet selv, men operativsystem- og hostingudbydere kan have udsendt egne rettede versioner. Hvis der ikke findes en rettet version til jeres opsætning, kan en større opgradering være nødvendig.
• Genstart tjenester, der anvender PHP. Det sikrer, at ældre og sårbar kode ikke fortsat kører efter opdateringen.
• Kontakt jeres leverandører. Få bekræftet, om software og tjenester, som I ikke selv administrerer, er blevet opdateret.
• Undersøg systemerne for tegn på kompromittering. Prioritér de systemer og tjenester, der har været eksponeret mod internettet.

For IT-teams drejer det sig om sårbarhederne CVE-2026-109618 og CVE-2026-109619, som er rettet i PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35. Hvis du bruger PHP fra din operativsystemudbyder, skal du tjekke udbyderens sikkerhedsmeddelelse, da opdaterede pakker ofte beholder deres gamle versionsnummer.

PHP2Shell synliggør teknisk gæld

PHP2Shell handler ikke kun om én konkret sårbarhed. Hændelsen viser også konsekvenserne af forældede softwareversioner, komplekse afhængigheder og manglende overblik over organisationens IT-miljø.

Jo vanskeligere det er at identificere, opdatere eller isolere en sårbar komponent, desto længere tid kan det tage at håndtere en kritisk sikkerhedshændelse.

Det er teknisk gæld, der bliver synlig, når en alvorlig sårbarhed rammer.