PHP-lekkasjen fra 21 oktober: hva som skjedde og hvordan status er nå

Onsdag 21. oktober ble det kjent to alvorlige sikkerhetshull i PHP, programmeringsspråket som størstedelen av alle nettsider kjører på, inkludert WordPress. Kanskje du merket noe til det, for en del av dagen var nettsidene hos oss nede. I denne artikkelen oppsummerer vi hva som skjedde, hvordan vi håndterte det og hvordan status er nå.

Hva var problemet?

Sårbarhetene (CVE-2026-109618 og CVE-2026-109619) gjorde det mulig for uautoriserte å kjøre kode på en webserver. Det er omtrent den verste typen sårbarhet som finnes: en angriper trenger ikke passord for dette, og det rammer nesten hele internett.

Hvordan vi håndterte det

1. Midlertidig tiltakonsdag 21. oktober, 10:00

   På det tidspunktet var det bare kjent at det fantes to alvorlige sårbarheter i alle PHP-versjoner, med en CVE-score på 9,2. Detaljer var ennå ikke tilgjengelige, og det var ingen kjente vellykkede hack, selv om for eksempel Cloudflare så stadig flere forsøk. Fordi detaljene om sårbarheten ikke var kjent, visste ingen nøyaktig hvordan det hang sammen, og hva som kunne gjøres for å begrense risikoen. Det kom stadig flere avbøtende tiltak og mulige handlinger for å begrense risikoen. Disse gjennomførte vi umiddelbart, som å deaktivere bestemte PHP-funksjoner og oppdatere brannmuren flere ganger.
   Fra kl. 10:00 kjørte vi også kontinuerlig svært strenge skadevarescanninger, slik at vi umiddelbart ville se om det ble plassert et skript noe sted på serverne våre eller i kontoene til kundene våre. Det skjedde ikke.

2. Nettsider nedeonsdag 21. oktober, 15:15

   Selv om vi ikke så forsøk på misbruk på serverne våre, valgte vi den sikreste løsningen: alt ned. Hovedgrunnen til dette var at vi hadde våre tvil om effektiviteten av de avbøtende tiltakene (midlertidige løsningene) som gikk rundt på internett, fordi ingen kunne bekrefte at dette ville gi tilstrekkelig beskyttelse.
   I en situasjon med så mye usikkerhet og potensielt enorme konsekvenser kan noen timers nedetid forsvares; å ta risikoen kan ikke.

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

   Utviklerne av PHP ga ut den offisielle oppdateringen med fiksen for versjon 8.3, 8.4 og 8.5. Deretter gjensto det å vente på oppdaterte pakker fra CloudLinux, leverandøren av PHP-versjonene på serverne våre.
   Da oppdateringen ble publisert, ble også detaljene om sårbarhetene kjent, og det bekreftet mistanken vår: de kjente avbøtende tiltakene og de ekstra brannmurreglene reduserte riktignok risikoen for et hack, men dette var ikke tilstrekkelig for å beskytte serveren.

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

   Dessverre tok det mye lengre tid enn vi håpet og hadde forventet før CloudLinux hadde oppdateringene klare. Kontakten vår med andre leverandører viste at vi ikke var de eneste som ble overrasket. Fordi vi så at de allerede flere ganger ikke hadde holdt sine egne tidsfrister, jobbet vi med en midlertidig løsning.
   Vi installerte selv PHP-versjon 8.3.36 på alle serverne våre og satte alle kundene midlertidig på denne versjonen. 90 % av nettsidene kom tilbake på nett mellom 19:00 og 20:30. De eneste nettsidene som ikke kom på nett, var utdaterte og kunne ikke håndtere en moderne PHP-versjon.

5. Oppdateringtorsdag 22. oktober, 00:30

   Oppdateringene ble tilgjengelige, og vi begynte umiddelbart å installere og kontrollere, server for server.

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

   Alle servere var oppdatert, og alle nettsider var tilbake på nett, med den PHP-versjonen de brukte fra før.

Vi forstår godt at det er kjedelig hvis nettsiden din ikke er tilgjengelig en ettermiddag og kveld. Denne ulempen veier likevel ikke opp for de mulige konsekvensene. Vi har aldri tidligere måttet ta beslutningen om å ta alt ned som en forholdsregel, men skulle samme situasjon oppstå igjen, gjør vi nøyaktig det samme.

Hvordan er status nå?

• Alle PHP-versjoner vi tilbyr, fra 5.2 til og med 8.5, inneholder sikkerhetsrettelsene for begge sårbarhetene.
• De få nettsidene som kjørte på en enda eldre PHP-versjon, som det ikke finnes rettelse for, har vi flyttet til en rettet versjon.
• Vi har kontrollert serverne under og etter sårbarheten for spor av misbruk, som fastlåste PHP-prosesser, mistenkelige prosesser, opplastede filer og forespørsler som samsvarer med det kjente angrepet. Vi har ikke funnet noen holdepunkter for at sårbarheten er utnyttet på serverne våre, og før vi tok alt ned, ble det heller ikke funnet forsøk på dette.

Er nettsiden min adskilt fra andres?

Ja. Hver hostingpakke kjører hos oss i et eget, avskjermet miljø. PHP kjører under brukeren til din pakke, uten administratorrettigheter på serveren, og kan ikke få tilgang til filene eller databasene til andre kunder. Også bruken av prosessor og minne er begrenset per pakke. Flere detaljer om sikkerheten vår deler vi bevisst ikke offentlig: jo mindre en angriper vet, jo bedre.