PHP2Shell: kritiske PHP-sårbarheter rammer store deler av nettet

oktober 2026

To kritiske feil i selve PHP-motoren, kalt PHP2Shell (CVE-2026-109618 og CVE-2026-109619), lar en angriper uten innlogging kjøre kode på webservere. PHP rettet feilene 21. oktober 2026, og samme dag så Amazon, Cloudflare og watchTowr aktive angrepsforsøk. Fordi feilen sitter i PHP og ikke i applikasjonen, er WordPress, Drupal, Joomla, Magento og nær sagt alt annet som kjører på PHP utsatt helt til selve PHP er oppdatert.

Det raskeste tiltaket er å oppdatere PHP til 8.5.12, 8.4.27, 8.3.36 eller 8.2.35 og starte alle PHP-prosesser på nytt. En oppdatering av CMS-et alene hjelper ikke.

Hva er PHP2Shell?

PHP2Shell er to feil i selve PHP-runtimen som sammen gir fjernkjøring av kode uten innlogging, i nesten alle PHP-versjoner tilbake til 5.4. Angriperen kan også lese minne fra PHP-prosessene og dermed få tak i passord, tokener, API-nøkler og sertifikater fra andres forespørsler, uten først å ha kjørt kode. Feilene ble funnet av Wiz Research, Calif og OpenAIs Codex Security-team (The Hacker News).

CVE-2026-109618 er en feil i håndteringen av minne som går tomt. Tegn på den ble sett allerede i PHPs eksterne revisjon i 2024, men da uten en kjent vei til kodekjøring.
CVE-2026-109619 gjelder fremdriftsvisning for filopplasting i sesjoner (session.upload_progress), som kan kjøre før PHP er ferdig med å sette opp forespørselen.

CVE	CVSS v2	CVSS v3.1	CVSS v4.0
CVE-2026-109618	7.5 High	9.8 Critical	9.2 Critical
CVE-2026-109619	10.0 Critical	9.8 Critical	9.2 Critical

Scorene er hentet fra Tenable, som oppgir Mitre og NVD som kilde. PHP selv vurderer begge til 9.2 i CVSS v4.0, og en lekket påstand om 10.0 var ikke PHPs vurdering.

Hvem er mest utsatt

Apache med mod_php er mest utsatt. Én forespørsel uten innlogging kan utløse angrepet før applikasjonskoden i det hele tatt kjører.
PHP-FPM stopper prosessen når en forespørsel feiler tidlig. Det gjør angrepet vanskeligere, men den ene feilen er vist å gi kodekjøring også her, gjennom en operasjon i applikasjonen.
php-cgi, FrankenPHP og LiteSpeed er også berørt.

Rettede versjoner

PHP-gren	Første rettede versjon
8.5	8.5.12
8.4	8.4.27
8.3	8.3.36
8.2	8.2.35

PHP 8.1 og eldre får ikke offisielle oppdateringer, men det finnes kildekode-rettinger for 7.4, 8.0 og 8.1. Linux-distribusjoner kan ha rettingen i en pakke med et gammelt versjonsnummer, så sjekk endringsloggen etter CVE-nummeret og ikke bare versjonen.

Utnyttelse

Detaljer og en angrepskode lekket før den planlagte publiseringen 22. oktober, så PHP slapp rettingene én dag tidligere (The Hacker News).

Tidspunkt (UTC)	Hendelse
21.10. kl. 14:19	watchTowr ser aktive angrepsforsøk mot begge CVE-ene
21.10. kl. 08:36	ELLIO registrerer første forespørsel, under en time etter at Chainguard publiserte rettede images
21.10. ca. kl. 02:00	Amazon ser første angrepsforsøk, samtidig med at rettingene slippes
17.10.	Amazons honeypot MadPot fanger et angrepsforsøk fire dager før feilene ble kjent

Amazon beskriver utnyttelsen som bred, med flere aktører. Pantheon blokkerte over 60 000 mistenkelige forespørsler, og Cloudflare så angripere endre angrepskoden for å komme rundt WAF-reglene. Det var ikke rapportert bekreftede innbrudd da kildene ble skrevet. BambooHR, MijnOverheid, DigiD og flere nederlandske utdanningssystemer tok tjenester ned i forebyggende hensikt.

WordPress, Drupal og andre CMS er berørt

Alle CMS og rammeverk som kjører på en sårbar PHP-versjon er utsatt, uansett hvor godt CMS-et selv er oppdatert. Wiz har vist fjernkjøring av kode uten innlogging mot WordPress, Drupal og Joomla med CVE-2026-109618, og mot WordPress og Drupal med CVE-2026-109619 (Recorded Future). CrowdStrike understreker at eksponeringen ikke avhenger av CMS, rammeverk eller tillegg (The Hacker News).

Plattform	Andel av alle nettsteder	Merknad
WordPress	39,6 %	Wiz viste kodekjøring med begge CVE-ene
Joomla	1,1 %	Wiz viste kodekjøring med CVE-2026-109618
Drupal	0,6 %	Wiz viste kodekjøring med begge CVE-ene. Mye brukt i offentlig sektor og UH-sektoren.

Tallene er fra W3Techs per 22. oktober 2026. I tillegg kommer nettbutikker på Magento og WooCommerce, rammeverk som Laravel og Symfony, og egenutviklede PHP-løsninger. Cloudflare trekker frem WordPress og Magento som plattformer som kan rammes i stor skala.

For Drupal kommer dette rett etter den kritiske kjernesårbarheten SA-CORE-2026-014 (CVE-2026-108097) fra 14. oktober. Drupal-nettsteder må derfor både oppdatere Drupal og PHP.

Omfanget

PHP brukes av 69,3 % av nettstedene der serverspråket er kjent.
Av disse kjører 34,7 % fortsatt PHP 7 eller eldre, som ikke lenger får offisielle sikkerhetsoppdateringer.
Modat fant 4,4 millioner PHP-tjenester på 1,9 millioner verter, og rundt 79 % av dem med synlig versjon kjører en gren uten støtte (Recorded Future).
VulnCheck fant PHP på rundt 2,6 millioner verter mot internett.

Hvem som må oppdatere, avhenger av driftsformen. På administrerte plattformer som WordPress.com og Pantheon er det leverandøren som oppdaterer PHP. Ved egen drift, på VPS eller i containere må du gjøre det selv. En oppdatering av WordPress eller Drupal endrer ikke PHP-versjonen under.

Hva med Facebook?

Facebook startet som en PHP-applikasjon i 2004, men har i dag forlatt vanlig PHP til fordel for egen runtime og eget språk. PHP2Shell sitter i den offisielle PHP-motoren (Zend Engine), som Facebook ikke bruker, så Meta er etter alt å dømme ikke direkte rammet. Det er ikke funnet noen uttalelse fra Meta om PHP2Shell.

Dette var Facebooks vei bort fra PHP (Wikipedia: HHVM, Phoronix):

År	Hendelse
2019	HHVM 4.0 kommer 11. februar som første versjon uten offisiell PHP-støtte
2014	Språket Hack lanseres sammen med HHVM 3.0, en PHP-variant med valgfri statisk typing
2013	facebook.com går over til HHVM i produksjon i første kvartal
2011	HHVM, en virtuell maskin med JIT-kompilering, slippes 9. desember
2010	HipHop for PHP oversetter PHP til C++ for å spare servere
2004	Facebook starter som en PHP-applikasjon

Facebooks historie viser både styrken og svakheten ved PHP. Språket gjorde det mulig å bygge raskt, men i Facebooks skala ble ytelsen så viktig at selskapet laget egen kompilator, egen runtime og til slutt eget språk. PHP 7 og 8 har siden tatt igjen mye av forspranget med en raskere motor, typing og JIT-kompilering.

Hvorfor så mye er bygget på PHP

PHP ble det dominerende webspråket fordi det var billigst og enklest å komme i gang med, og WordPress gjorde det selvforsterkende. Språket har eksistert siden midten av 1990-tallet og fulgte med nesten alle webhotell gjennom den klassiske LAMP-stakken (Linux, Apache, MySQL, PHP).

Dette er de viktigste grunnene (DreamHost):

Billig og overalt. Nesten alle webhotell har PHP ferdig installert, og delt hosting er billigere enn egne servere.
Ingen byggesteg. Du kopierer en fil til serveren, og endringen er i drift med en gang.
Lav terskel. PHP kan bakes rett inn i HTML, så nybegynnere ser resultater raskt.
Én prosess per forespørsel. Minnet ryddes etter hver forespørsel, så ett dårlig skript tar sjelden ned hele serveren. Det passer godt for delt hosting.
Stort økosystem. WordPress, Drupal, Joomla, Magento, Laravel og Symfony har tusenvis av tillegg og temaer, og det er lett å finne utviklere.
Mye innebygd. Standardbiblioteket håndterer database, JSON, filer, bilder og e-post uten mange eksterne pakker.

Resultatet er at PHP i dag brukes på 69,3 % av nettstedene med kjent serverspråk, inkludert Wikipedia og WordPress.org (W3Techs). Ifølge DreamHost leverer Wikipedia alene rundt 24 milliarder sidevisninger i måneden fra PHP.

Samme styrker forklarer hvorfor PHP2Shell er så alvorlig. Mange PHP-nettsteder er satt opp én gang og deretter lite vedlikeholdt, og W3Techs viser at over en tredjedel fortsatt kjører PHP 7 eller eldre.

Er PHP effektivt?

Moderne PHP er effektivt nok for de aller fleste nettsteder, men den klassiske driftsmodellen bruker mer serverkraft per forespørsel enn Node.js og Go. I vanlige webapplikasjoner er det likevel som regel databasen, ikke språket, som avgjør ytelsen.

En sammenligning av PHP 8.4 og Node.js 22 på samme maskinvare (4 vCPU, 8 GB RAM) viser mønsteret (HackerNoon):

Test	PHP 8.4 (foresp./s)	Node.js 22 (foresp./s)	PHP i forhold til Node
CPU-tung beregning (Fibonacci 35)	890	210	4,2 ganger raskere
Hello World, FrankenPHP worker-modus	29 100	38 200	76 %
Databaselesing (50 rader)	4 200	5 800	72 %
Databaseskriving	3 100	4 400	70 %
Hello World, PHP-FPM	12 400	38 200	32 %
JSON-serialisering	9 800	31 500	31 %

Testene er gjort av én forfatter og må leses som en pekepinn, ikke en fasit.

Hvorfor PHP koster mer på serveren

Oppstart per forespørsel. Med PHP-FPM bygges applikasjonen opp og rives ned for hver forespørsel. Det gir god isolasjon, men koster CPU og minne. Node.js, Go og .NET holder applikasjonen i minnet mellom forespørslene.
Én prosess per samtidig forespørsel. Mange samtidige brukere krever mange PHP-prosesser, og hver av dem bruker minne. Node.js håndterer mange ventende forespørsler i én prosess.
Godt på CPU-tungt arbeid. Her vant PHP i testen fordi hver forespørsel har sin egen prosess, mens en tung forespørsel i Node.js blokkerer de andre.

Gapet minker

PHP 7 doblet omtrent antall forespørsler per sekund sammenlignet med PHP 5.6 (DreamHost, som viser til Phoronix).
Fra PHP 7.4 til 8.5 er gevinsten i ren beregning bare rundt 3 % med JIT slått av (PHPBenchLab). Det store hoppet kom med PHP 7.
Worker-modus i FrankenPHP, Swoole og RoadRunner holder applikasjonen i minnet slik Node.js gjør. I testen over reduserte FrankenPHP avstanden til Node.js fra rundt 3 ganger til rundt 1,3 ganger.
OPcache og hurtigbuffer som Redis eller Varnish fjerner det meste av forskjellen for typiske CMS-nettsteder.

Konklusjon: For et CMS eller en vanlig webapplikasjon er PHP sjelden flaskehalsen. Ressursbruken er høyere enn i nyere plattformer, men forskjellen betyr mest for API-er med veldig mange samtidige kall, sanntidstjenester og websockets. Der er Node.js, Go eller .NET ofte et bedre valg. For sikkerheten betyr versjon og vedlikehold mer enn valg av språk, og PHP2Shell rammer hardest der PHP ikke har vært oppdatert på lenge.

Hva IT-avdelingen bør gjøre nå

Oppdater PHP på alle servere som er nåbare fra internett i dag, og anta at systemer med gammel PHP kan være kompromittert. Tiltakene under bygger på PHPs og forskernes anbefalinger (The Hacker News).

Haster

[ ] Kartlegg alle servere, containere og tjenester som kjører PHP, også interne verktøy og glemte nettsteder.
[ ] Oppdater til PHP 8.5.12, 8.4.27, 8.3.36 eller 8.2.35. Sjekk distribusjonens endringslogg for CVE-numrene hvis pakken har et eldre versjonsnummer.
[ ] Start Apache, PHP-FPM og alle andre PHP-prosesser på nytt etter oppdateringen.
[ ] Bygg containere på nytt fra oppdaterte images. Rettingen kommer ikke inn i en container som allerede kjører.
[ ] Spør leverandører av webhotell og administrert drift om når PHP er oppdatert hos dem.

Hvis du ikke kan oppdatere med en gang

[ ] Sett session.upload_progress.enabled=0 og start prosessene på nytt. På PHP 8.5 setter du også fatal_error_backtraces=0. Dette stopper bare kjente angrepsveier for CVE-2026-109619.
[ ] Hold post_max_size lav og begrens størrelsen på forespørsler i webserver eller proxy. Det reduserer risikoen for CVE-2026-109618, men fjerner den ikke.
[ ] Slå på WAF-regler for PHP2Shell hos Cloudflare eller tilsvarende. Angriperne endrer allerede angrepskoden for å komme rundt dem.

Etter oppdatering

[ ] Let etter tegn på angrep før oppdateringen: uvanlige multipart-forespørsler fulgt av minnefeil eller gjentatte HTTP 500, uvanlig store PHPSESSID-informasjonskapsler og uforklarte omstarter av PHP-prosesser.
[ ] Bytt passord, API-nøkler og tokener som PHP-applikasjonene bruker, fordi feilene kan lekke minne fra andre forespørsler.
[ ] Kontroller at memory_limit og post_max_size passer applikasjonene. Rettingen innfører en hard minnegrense som avslutter prosessen når den nås.
[ ] Oppdater Drupal for SA-CORE-2026-014 samtidig, hvis det ikke allerede er gjort.
[ ] Lag en plan for å fase ut PHP 8.1 og eldre, og PHP 8.2, som mister støtte 31. desember 2026.

For brukerne er det viktigste at enkelte nettsteder og tjenester kan være nede en kort periode under oppdatering, slik flere nederlandske offentlige tjenester var. Hvis tjenester har vært kompromittert, kan brukere få beskjed om å bytte passord.

Node-RED LoRaWAN CouchDB and more

PHP2Shell

Serverdrift: legacy eller container

Count Panic in PanicPoll

Basic introduction of the four first activities