PHP2Shell er navnet på to kritiske sårbarheter i PHP, registrert som CVE-2026-109618 og CVE-2026-109619. Hvis feilene utnyttes, kan en angriper kjøre kode på en berørt server uten å logge inn. PHP publiserte rettelser 21. oktober 2026, og sikkerhetsselskaper har meldt om forsøk på å utnytte sårbarhetene. Det er likevel viktig å skille mellom angrepsforsøk og bekreftede innbrudd.
11
14
19
Hva er PHP2Shell?
Sårbarhetene ligger i selve PHP-miljøet – kjøretiden som behandler PHP-kode – og ikke bare i et bestemt nettsted eller publiseringssystem. Red Hat beskriver den ene feilen som et problem med minnehåndtering når en minneforespørsel mislykkes under behandling av en forespørsel. Den andre kan etterlate utdatert tilstand når en alvorlig feil avbryter oppryddingen.
7
Til sammen kan feilene åpne for fjernkjøring av kode: En angriper kan i verste fall kjøre egne kommandoer på en sårbar server uten først å skaffe seg en brukerkonto.
11
13 Begge sårbarhetene fikk 9,2 av 10 på CVSS v4.0-skalaen, som plasserer dem i kategorien kritisk.
4
Mulige følger er at en server blir kompromittert, data eksponeres eller tjenester forstyrres. Men at en nettside bruker PHP, betyr ikke i seg selv at den er sårbar eller har vært utsatt for et vellykket angrep.
13
Hvorfor saken fikk så mye oppmerksomhet
Rapporter beskriver feilene som sårbarheter som hadde eksistert i PHP i flere år før de ble kjent.
42 At en feil har vært til stede lenge, beviser imidlertid ikke at angripere kjente til den eller utnyttet den i perioden.
Saken har også satt søkelys på bruk av kunstig intelligens i sikkerhetsforskning. Ifølge omtaler brukte Calif og Wiz KI-verktøy i arbeidet med å undersøke sårbarhetene, og OpenAI var involvert i forsknings- og varslingsarbeidet.
34
44 KI kan hjelpe forskere med å lete etter feil i programvare, men dette viser ikke i seg selv hvor raskt angripere kan bruke tilsvarende verktøy – eller hvem som har et overtak.
PHP omtales ofte som et språk som brukes av en stor andel av verdens nettsteder, i enkelte estimater rundt 70 prosent.
20 Det tallet sier noe om hvor utbredt PHP er, ikke hvor mange servere som er bekreftet sårbare eller kompromittert. Den faktiske risikoen avhenger blant annet av PHP-versjon, oppsett og om rettelsen er installert.
Oppdateringer og rapporterte angrepsforsøk
PHP-prosjektet publiserte rettede versjoner 21. oktober: 8.2.35, 8.3.36, 8.4.27 og 8.5.12.
19 Denne listen gjelder PHP 8.2 til 8.5. Bruker virksomheten en eldre versjon, bør den sjekke sikkerhetsinformasjon fra operativsystem- eller driftstilbyderen for å finne ut om det finnes en verifisert rettelse eller en tilbakeført oppdatering.
Det er meldt om forsøk på å utnytte feilene. SecurityWeek skrev at Amazon registrerte et forsøk 17. oktober, fire dager før oppdateringene ble sluppet.
14 Cloudflare meldte også om en kraftig økning i trafikk som forsøkte å utnytte sårbarhetene, med rapporterte tall på flere millioner forsøk.
27
38 Dette er målinger av forsøk – ikke av vellykkede innbrudd.
Vurderingene av hvor omfattende utnyttelsen er, varierer. Enkelte kilder rapporterer aktive forsøk, mens en annen vurderer masseutnyttelse som mindre sannsynlig enn først antatt.
3
4 Materialet som foreligger, bekrefter ikke omfattende vellykkede kompromitteringer. Ta troverdige varsler alvorlig, men ikke forveksle skanning eller angrepsforsøk med bevis på at en bestemt server er brutt inn i.
2
3
Tjenester ble tatt ned mens virksomheter håndterte risikoen
Noen aktører satte tjenester midlertidig på pause eller gikk i vedlikeholdsmodus under arbeidet med å sikre systemene. Rapporter beskriver slike tiltak i Japan, Frankrike, Finland og Nederland, og amerikanske og europeiske myndigheter oppfordret også virksomheter til å handle.
18
20
35 Å ta en nettside midlertidig ned kan begrense eksponeringen mens man undersøker saken, men er ikke i seg selv tegn på at siden er kompromittert.
Dette bør PHP-ansvarlige gjøre
- Kontroller PHP-miljøet, ikke bare nettsiden. PHP2Shell berører selve PHP-kjøretiden. En oppdatering av et publiseringssystem eller en utvidelse bekrefter derfor ikke at PHP-installasjonen er rettet.
13
- Installer en verifisert rettelse. Oppgrader til en berørt, rettet PHP-versjon, eller følg leverandørens instruksjoner dersom den tilbyr en tilbakeført oppdatering. Kontroller hvilken versjon som faktisk kjører i produksjon.
19
- Undersøk tegn på innbrudd. En oppdatering lukker sårbarheten, men viser ikke at serveren aldri har vært utsatt. Gå gjennom relevante logger og undersøk mistenkelig aktivitet før systemet settes tilbake i normal drift.
- Bruk midlertidige tiltak som et tillegg. Følg oppdatert veiledning fra PHP-prosjektet eller leverandøren. Ikke stol på én enkelt konfigurasjonsendring eller en brannmur for webapplikasjoner (WAF) i stedet for en bekreftet rettelse av PHP-miljøet.
15
27
- Behandle kontosikkerhet som et ekstra lag. Unike passord og flerfaktorautentisering beskytter brukerkontoer, men retter ikke en sårbarhet som kan utnyttes uten innlogging.
For IT-team er skillet mellom en sårbarhet, et angrepsforsøk og et bekreftet innbrudd avgjørende. Det gjør det mulig å handle raskt uten å trekke konklusjoner om hvem som faktisk er rammet.