Kritisk PHP-sårbarhet (PHP2Shell): dette gjelder, og dette gjorde vi

Skjold med varseltrekant og oppdateringspil ved siden av en PHP-sjekkliste og en server – illustrasjon av kritisk PHP-sårbarhet og sikkerhetsoppdatering

21. oktober 2026 slapp PHP-teamet en hastepatch for to kritiske hull i selve PHP-motoren. De to sårbarhetene har fått navnet PHP2Shell, de er begge vurdert til 9,2 av 10, og de kan utnyttes av hvem som helst over internett uten innlogging. Koden som er feil har ligget i PHP siden 2012.

Dette er ikke en sårbarhet i WordPress, Magento eller et tema du har installert. Den ligger i PHP selv, og den treffer derfor nesten alle nettsteder som kjører PHP, uansett hvor ryddig koden på nettstedet er.

Kort oppsummert

  • To sårbarheter: CVE-2026-109618 og CVE-2026-109619, begge CVSS 9,2.
  • Angriperen kan kjøre vilkårlig kode på serveren, og lese minne som kan inneholde passord, sesjonsnøkler og API-nøkler.
  • Rettet i PHP 8.5.12, 8.4.27, 8.3.36 og 8.2.35. Eldre grener får ingen offisiell retting.
  • Utnyttelse ble observert før patchen kom. Dette haster.
  • Er du kunde hos oss, er alt allerede oppdatert. Du trenger ikke gjøre noe.

Hva er PHP2Shell?

PHP2Shell er navnet på et angrep som kjeder sammen to feil i PHP til én vei inn på serveren.

  • CVE-2026-109618 er en use-after-free-feil i koden som håndterer opplastingsstatus. Den kan lekke minne fra en PHP-prosess som nettopp har jobbet med noe annet. I praksis betyr det at en angriper kan få ut passord, sesjonsnøkler, API-nøkler og i verste fall private TLS-nøkler – fra en helt annen brukers forespørsel.
  • CVE-2026-109619 er en use-after-free-feil i håndteringen av feilmeldinger, kombinert med typeforveksling i OPcache. Den gir kjøring av egen kode.

Det som gjør dette alvorlig er hvor tidlig angrepet treffer. Alle kjente angrepsveier går gjennom en vanlig multipart/form-data-forespørsel, altså samme type forespørsel som brukes når noen laster opp en fil. PHP tolker den før koden på nettstedet ditt i det hele tatt får se den. Et skjema trenger ikke finnes. Innlogging trenger ikke finnes. Standardoppsettet er sårbart, både med Apache og PHP-FPM.

Hvilke PHP-versjoner er berørt?

Den sårbare koden stammer fra PHP 5.4, som kom i 2012. Alt fra og med den versjonen må regnes som berørt.

PHP-grenRettet i versjonStatus
8.58.5.12Offisiell retting
8.48.4.27Offisiell retting
8.38.3.36Offisiell retting
8.28.2.35Offisiell retting
7.4 – 8.1Ingen utgivelseKun kildekode-patch, eller retting fra distribusjonen din
5.4 – 7.3IngenUtgått. Må oppgraderes

Kjører nettstedet ditt PHP 8.1 eller eldre, er ikke dette lenger bare en oppdateringssak. Da bør nettstedet flyttes til en PHP-versjon som fortsatt får sikkerhetsretting.

Hvorfor det haster mer enn vanlig

Detaljene om sårbarhetene lekket ut dagen før patchen var klar, 20. oktober. Cloudflare observerte de første angrepsforsøkene klokken 09.43 norsk tid 21. oktober – drøyt seks timer før den offisielle rettingen forelå. Angrepsverktøy og tekniske gjennomganger er nå offentlige.

CISA i USA har lagt ut eget varsel og ber om umiddelbar oppdatering. Når en sårbarhet først er beskrevet offentlig i detalj, går det vanligvis timer, ikke uker, før automatiserte angrep skanner bredt etter servere som ikke er oppdatert.

Slik forløp vår respons

Vi fulgte saken fra den lekket, og oppdateringene gikk ut fortløpende gjennom dagen og kvelden 21. oktober.

  1. Proaktiv beskyttelse (WAF via Imunify360). Før PHP-teamet slapp sin offisielle oppdatering, var flere av angrepsvektorene allerede kjent for Imunify360. Disse ble lagt inn i brannmurens kjerne, noe som umiddelbart reduserte eksponeringen for alle våre kunder i påvente av oppdateringen.
  2. 21. oktober kl. 16:00. PHP-teamet lanserte de offisielle, patchede versjonene av PHP.
  3. 21. oktober kl. 16:03 til 16:30. cPanel-teamet startet distribusjon. Samtlige standardoppdateringer landet på våre servere og ble umiddelbart rullet ut.
  4. 21. oktober kl. 16:30 til 23:00. Vi oppdaterte fortløpende alle spesialpakker og Hardened PHP (alt-php) fra CloudLinux etter hvert som disse ble tilgjengeliggjort gjennom dagen og kvelden.

Status for våre kunder

Våre logger viser ingen tegn til at denne sårbarheten har blitt utnyttet mot noen av våre kunder.

Alle våre PHP-miljøer ble oppdatert samme dag som sikkerhetspatchen ble utgitt. Som kunde trenger du ikke å foreta deg noe – oppdateringen er allerede automatisk implementert på alle våre webhotell.

Hva du bør gjøre hvis nettstedet ligger et annet sted

  1. Finn ut hvilken PHP-versjon du kjører. I WordPress står den under Verktøy → Nettstedshelse → Info → Server. Hos de fleste webhotell kan du også se og bytte versjon i kontrollpanelet.
  2. Sammenlign med tabellen over. Er du på en lavere versjon enn 8.2.35, 8.3.36, 8.4.27 eller 8.5.12, er du eksponert.
  3. Spør leverandøren direkte. Still ett konkret spørsmål: «Er PHP oppdatert mot CVE-2026-109618 og CVE-2026-109619, og når ble det gjort?» Et svar om at «serverne overvåkes» er ikke et svar.
  4. Pass på at PHP faktisk ble startet på nytt. En oppdatering som ikke er fulgt av omstart av PHP-prosessene, betyr at den gamle koden fortsatt kjører.
  5. Bytt ut hemmeligheter hvis du har grunn til å tro at nettstedet var eksponert. Sårbarheten kan lekke minne, så databasepassord, API-nøkler og saltene i wp-config.php bør byttes.

Hvis du ikke får oppdatert med en gang

PHP-teamet er tydelige på at oppdatering er den eneste fullstendige rettingen. Tiltakene under reduserer eksponeringen, men de gjør ikke installasjonen trygg:

  • Slå av session.upload_progress.enabled, og på PHP 8.5 også fatal_error_backtraces.
  • Sett memory_limit=-1 på en måte applikasjonen ikke kan overstyre. Merk at dette lar én enkelt forespørsel spise all hukommelse på serveren, så det krever en grense på container- eller cgroup-nivå.
  • Blokker multipart/form-data-forespørsler i webserveren der du kan klare deg uten opplasting.
  • Start alle PHP-prosesser på nytt etter endringene.

En brannmur foran nettstedet, enten hos leverandøren eller via Cloudflare, fanger kjente angrepsmønstre. Det er en midlertidig demning, ikke en reparasjon.

Spørsmål og svar

Er WordPress-nettstedet mitt rammet?

Hvis serveren kjører en PHP-versjon som ikke er oppdatert, ja. Sårbarheten ligger i PHP, ikke i WordPress, så den rammer uavhengig av hvilke temaer og utvidelser du bruker. Et fullt oppdatert WordPress på en gammel PHP-versjon er fortsatt eksponert.

Hjelper det å oppdatere WordPress, temaer og utvidelser?

Nei, ikke mot denne. Det er alltid lurt, men rettingen må skje i PHP på serveren. Det er leverandøren din som må gjøre den jobben.

Hvordan vet jeg om noen har utnyttet dette hos meg?

Se etter POST-forespørsler med multipart/form-data mot adresser som ikke har skjemaer, PHP-prosesser som har krasjet eller startet uventet på nytt, og nye eller endrede filer i nettstedsmappen. Finner du spor, er det ikke nok å oppdatere PHP – da må hemmeligheter byttes og nettstedet gjennomgås.

Jeg kjører PHP 8.1 eller eldre. Hva gjør jeg?

PHP-prosjektet gir ingen ferdig oppdatering for disse. Noen distribusjoner lager egne rettinger, men den varige løsningen er å flytte nettstedet til PHP 8.2 eller nyere. Er du usikker på om nettstedet tåler det, er det nettopp den jobben vi gjør ofte.

Trenger jeg å gjøre noe som kunde hos dere?

Nei. Alle PHP-miljøer ble oppdatert samme dag som patchen kom, og brannmuren hadde allerede regler på plass i mellomtiden.

Lærdommen fra denne uken

Nettstedet ditt er like trygt som laget under det. Du kan ha ryddig kode, oppdaterte utvidelser og sterke passord, og likevel stå åpent fordi PHP på serveren har en feil fra 2012. Det du faktisk kan styre, er hvor raskt den som drifter serveren reagerer når noe slikt skjer – og om de forteller deg om det.

Les også