PHP-sikkerhedshul fra 21. oktober: hvad der skete, og hvordan det ser ud nu

Onsdag den 21. oktober blev der opdaget to alvorlige sikkerhedshuller i PHP, det programmeringssprog som langt størstedelen af alle websites kører på, heriblandt WordPress. Du har måske bemærket noget, for en del af dagen var websites hos os offline. I denne artikel gennemgår vi, hvad der skete, hvordan vi har håndteret det, og hvordan situationen ser ud nu.

Hvad var der galt?

Hullerne (CVE-2026-109618 og CVE-2026-109619) gjorde det muligt for uautoriserede at udføre kode på en webserver. Det er stort set den værste type sikkerhedshul, der findes: en angriber har ikke brug for en adgangskode, og det rammer stort set hele internettet.

Hvordan vi har håndteret det

1. Midlertidig foranstaltningonsdag 21. oktober, 10:00

   På det tidspunkt var det kun kendt, at der var to alvorlige huller i alle PHP-versioner med en CVE-score på 9,2. Der var endnu ingen detaljer, og der var endnu ingen kendte vellykkede hacks, selvom for eksempel Cloudflare så et stigende antal forsøg. Fordi detaljerne om hullet ikke var kendt, vidste ingen præcis, hvordan det forholdt sig, og hvad der kunne gøres for at begrænse risikoen. Der kom løbende flere modforanstaltninger og mulige handlinger til at begrænse risikoen. Dem har vi gennemført med det samme, som at deaktivere bestemte PHP-funktioner og opdatere firewallen flere gange.
   Fra kl. 10:00 har vi også kørt meget strenge malwarescanninger kontinuerligt, så vi straks ville opdage det, hvis der blev placeret et script et sted på vores servere eller i vores kunders konti. Det skete ikke.

2. Websites offlineonsdag 21. oktober, 15:15

   Selvom vi ikke så forsøg på misbrug på vores servere, besluttede vi at vælge den sikreste løsning: alt offline. Den vigtigste grund til dette er, at vi var i tvivl om effektiviteten af de modforanstaltninger (midlertidige løsninger), der cirkulerede på internettet, fordi ingen kunne bekræfte, at dette ville give tilstrækkelig beskyttelse.
   I en situation med så mange uklarheder og potentielt enorme konsekvenser kan nogle timers nedetid forsvares, det kan risikoen ikke.

3. Officiel løsningonsdag 21. oktober, 16:00

   PHP-udviklerne udgav den officielle opdatering med rettelsen for versionerne 8.3, 8.4 og 8.5. Derefter ventede vi på opdaterede pakker fra CloudLinux, leverandøren af PHP-versionerne på vores servere.
   Da opdateringen blev offentliggjort, blev detaljerne om sårbarhederne også kendt, hvilket bekræftede vores mistanke: de kendte modforanstaltninger og ekstra firewallregler reducerede ganske vist risikoen for et hack, men det var ikke tilstrækkeligt til at beskytte serveren.

4. Midlertidig løsningonsdag 21. oktober, 19:00

   Desværre tog det meget længere tid, end vi håbede og havde forventet, før CloudLinux havde opdateringerne klar. Vores kontakt med andre udbydere viste, at vi ikke var de eneste, der var overraskede. Fordi vi kunne se, at de allerede flere gange ikke havde overholdt deres egne deadlines, arbejdede vi på en midlertidig løsning.
   Vi installerede selv PHP-version 8.3.36 på alle vores servere og satte midlertidigt alle vores kunder på denne version. 90% af websites kom online igen mellem kl. 19:00 og 20:30. De eneste websites, der ikke kom online, var forældede og kunne ikke håndtere en moderne PHP-version.

5. Opdateringtorsdag 22. oktober, 00:30

   Opdateringerne blev tilgængelige, og vi begyndte straks at installere og kontrollere, server for server.

6. Løsttorsdag 22. oktober, 02:30

   Alle servere var opdateret, og alle websites var online igen, på den PHP-version de også brugte tidligere.

Vi forstår udmærket, at det er ærgerligt, hvis din website ikke er tilgængelig en eftermiddag og aften. Denne ulempe vejer dog ikke op mod de mulige konsekvenser. Vi har aldrig tidligere skullet beslutte at tage alt offline som forholdsregel, men hvis den samme situation opstår igen, gør vi præcis det samme.

Hvordan ser situationen ud nu?

• Alle PHP-versioner, vi tilbyder, fra 5.2 til og med 8.5, indeholder sikkerhedsrettelserne for begge huller.
• De få websites, der kørte på en endnu ældre PHP-version, som der ikke findes en rettelse til, har vi flyttet til en rettet version.
• Vi har kontrolleret serverne under og efter hullet for spor af misbrug, som fastlåste PHP-processer, mistænkelige processer, uploadede filer og forespørgsler, der stemmer overens med det kendte angreb. Vi har ikke fundet tegn på, at hullet er blevet misbrugt på vores servere, og før vi gik offline, blev der heller ikke fundet forsøg herpå.

Er min website adskilt fra andres?

Ja. Hver hostingpakke kører hos os i sit eget, afskærmede miljø. PHP kører under brugeren for din pakke, uden administratorrettigheder på serveren, og kan ikke få adgang til andre kunders filer eller databaser. Også brugen af processor og hukommelse er begrænset pr. pakke. Flere detaljer om vores sikkerhed deler vi bevidst ikke offentligt: jo mindre en angriber ved, jo bedre.