PHP-läcka från 21 oktober: vad som hände och hur läget är nu

Onsdagen den 21 oktober blev två allvarliga säkerhetsbrister i PHP kända, programmeringsspråket som majoriteten av alla webbplatser körs på, inklusive WordPress. Du kanske märkte av det, eftersom webbplatserna hos oss låg nere en del av dagen. I den här artikeln går vi igenom vad som hände, hur vi agerade och hur läget är nu.

Vad var det som hände?

Bristerna (CVE-2026-109618 och CVE-2026-109619) gjorde det möjligt för obehöriga att köra kod på en webbserver. Det är ungefär den värsta typen av säkerhetsbrist som finns: en angripare behöver inget lösenord och den påverkar så gott som hela internet.

Hur vi agerade

1. Tillfällig åtgärdonsdag 21 oktober, 10:00

   Vid den tidpunkten var det bara känt att det fanns två allvarliga brister i alla PHP-versioner, med en CVE-poäng på 9,2. Det fanns ännu inga detaljer och inga lyckade attacker var kända, även om till exempel Cloudflare såg allt fler försök. Eftersom detaljerna om bristen inte var kända visste ingen exakt hur det låg till eller vad som kunde göras för att begränsa risken. Det kom dock successivt fler mitigeringar och möjliga åtgärder för att minska risken. De genomförde vi direkt, till exempel att stänga av vissa PHP-funktioner och uppdatera brandväggen flera gånger.
   Från klockan 10:00 lät vi också kontinuerligt mycket noggranna skadeprogramskontroller köra, så att vi direkt skulle upptäcka om ett skript placerades någonstans på våra servrar eller i våra kunders konton. Det inträffade inte.

2. Webbplatser offlineonsdag 21 oktober, 15:15

   Även om vi inte såg några försök till missbruk på våra servrar valde vi det säkraste alternativet: allt offline. Den främsta anledningen till det var att vi tvivlade på effektiviteten av de mitigeringar (tillfälliga lösningar) som cirkulerade på internet, eftersom ingen kunde bekräfta att detta skulle ge tillräckligt skydd.
   I en situation med så mycket osäkerhet och potentiellt enorma konsekvenser går några timmars driftstopp att försvara; att ta risken gör det inte.

3. Officiell lösningonsdag 21 oktober, 16:00

   Utvecklarna av PHP släppte den officiella uppdateringen med rättningen för versionerna 8.3, 8.4 och 8.5. Därefter väntade vi på uppdaterade paket från CloudLinux, leverantören av PHP-versionerna på våra servrar.
   När uppdateringen publicerades blev även detaljerna om sårbarheterna kända, vilket bekräftade vår misstanke: de kända mitigeringarna och extra brandväggsreglerna minskade visserligen risken för en attack, men det räckte inte för att skydda servern.

4. Tillfällig lösningonsdag 21 oktober, 19:00

   Tyvärr tog det betydligt längre tid än vi hoppats och förväntat oss innan CloudLinux hade uppdateringarna klara. Vår kontakt med andra leverantörer visade att vi inte var ensamma om att bli överraskade. Eftersom vi såg att de redan flera gånger hade missat sina egna satta deadlines arbetade vi på en tillfällig lösning.
   Vi installerade själva PHP-version 8.3.36 på alla våra servrar och satte tillfälligt alla våra kunder på den här versionen. 90 % av webbplatserna kom tillbaka online mellan 19:00 och 20:30. De enda webbplatser som inte kom online var föråldrade och kunde inte hantera en modern PHP-version.

5. Uppdateringtorsdag 22 oktober, 00:30

   Uppdateringarna blev tillgängliga och vi började direkt installera och kontrollera, server för server.

6. Lösttorsdag 22 oktober, 02:30

   Alla servrar var uppdaterade och alla webbplatser var tillbaka online, på samma PHP-version som de använde tidigare.

Vi förstår att det är frustrerande om din webbplats är otillgänglig under en eftermiddag och kväll. Det här obehaget väger dock inte upp mot de möjliga konsekvenserna. Vi har aldrig tidigare behövt besluta att ta allt offline som en försiktighetsåtgärd, men om samma situation skulle uppstå igen gör vi precis samma sak.

Hur ser läget ut nu?

• Alla PHP-versioner vi erbjuder, från 5.2 till och med 8.5, innehåller säkerhetsrättningarna för båda bristerna.
• De få webbplatser som körde på en ännu äldre PHP-version, för vilken det inte finns någon rättning, har vi flyttat till en rättad version.
• Vi har under och efter säkerhetsbristen kontrollerat servrarna för spår av missbruk, till exempel hängande PHP-processer, misstänkta processer, uppladdade filer och förfrågningar som stämmer med den kända attacken. Vi har inte hittat några tecken på att bristen utnyttjats på våra servrar, och innan vi gick offline hittades heller inga försök till det.

Är min webbplats åtskild från andras?

Ja. Varje hostingpaket körs hos oss i en egen, avskärmad miljö. PHP körs under användaren för ditt paket, utan administratörsrättigheter på servern, och kan inte komma åt andra kunders filer eller databaser. Även användningen av processor och minne är begränsad per paket. Vi delar medvetet inte fler detaljer om vår säkerhet offentligt: ju mindre en angripare vet, desto bättre.