PHP2Shell: uautentisert RCE i PHP, og slik sjekker du om byggene dine er berørt

PHP2Shell er to kritiske sårbarheter i selve PHP, CVE-2026-109618 og CVE-2026-109619, som kan la en uautentisert webforespørsel kjøre kode på enhver PHP-installasjon som håndterer webforespørsler: PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP og LiteSpeed. Begge utnyttes aktivt og står i CISAs KEV-katalog. Rettelsen er PHP 8.5.12, 8.4.27, 8.3.36 eller 8.2.35; PHP 8.1 og eldre får ingen utgivelse fra upstream. Oppgrader, og bygg og rull deretter ut på nytt hvert container-image som inneholder PHP, inkludert gamle tagger som fortsatt kjører, og images du har levert til kunder.

Å patche serveren du vet om, er den enkle delen. Eksponeringen som blir hengende igjen, er PHP-en du har glemt: en kjøretid kompilert inn i et base-image, en image-tagg fra i fjor som fortsatt kjører i produksjon, et CI-image eller et produkt levert til kunder med en PHP som har nådd end of life. Denne siden får deg patchet først og viser deretter hvordan du finner resten.

Hva som skjedde

Dato (2026)	Hendelse	Kilde
11. og 21. august	Calif rapporterer de to feilene til PHP-prosjektet	Calif
17. oktober	Det første utnyttelsesforsøket Amazon så i honeypotene sine, før offentliggjøringen	Amazon Threat Intelligence
20. oktober	PHP varsler en sikkerhetsutgivelse 21. oktober kl. 14.00 UTC som retter to sårbarheter vurdert til CVSS 4.0 9,2	php.net
21. oktober	PHP gir ut 8.5.12, 8.4.27, 8.3.36 og 8.2.35 og publiserer sikkerhetsvarselet sitt; CVE-oppføringene blir offentlige; NCSC-NL åpner repositoriet php2shell	PHPs sikkerhetsvarsel, NCSC-NL
21. oktober	De offisielle Docker-imagene php oppdateres til de rettede versjonene	docker-library/php
21. oktober	watchTowr rapporterer at begge CVE-ene utnyttes aktivt; CISA publiserer et varsel	watchTowr, CISA
22. oktober	Searchlight Cyber publiserer php2shell-scanner	GitHub
23. oktober	PHP anbefaler å sette session.upload_progress.enabled=0 mot en separat, lite sannsynlig RCE-vei, CVE-2026-115560	php.net
26. oktober	CISA legger begge CVE-ene til i KEV-katalogen, med 29. oktober som frist for amerikanske føderale myndigheter	CISA KEV

Navnet PHP2Shell kommer fra Califs gjennomgang og brukes bredt i bransjens dekning; PHPs egne sikkerhetsvarsler bruker det ikke. CVE-oppføringene krediterer Calif, Wiz og OpenAI.

Hvem som er berørt

All PHP som håndterer webforespørsler. PHPs sikkerhetsvarsel nevner PHP-FPM, Apache med mod_php, php-cgi, FrankenPHP og LiteSpeed, og vurderer risikoen som størst for mod_php, «med en demonstrert exploit der en uautentisert forespørsel kan utløse angrepet før noen applikasjonskode kjører.» Fordi feilene ligger i selve PHP, er applikasjoner bygget på Laravel, Symfony eller WordPress eksponert så snart PHP-en under dem er det.

Gren	Berørt	Rettet i	Støtte fra upstream
8.5	før 8.5.12	8.5.12	Aktiv
8.4	før 8.4.27	8.4.27	Aktiv
8.3	før 8.3.36	8.3.36	Kun sikkerhetsrettelser, til og med 31. desember 2027
8.2	før 8.2.35	8.2.35	Kun sikkerhetsrettelser, til og med 31. desember 2026
8.1, 8.0, 7.4	alle versjoner, ifølge Calif og watchTowr	ingen utgivelse; minimale tilbakeporteringer i kildekode i php-src	End of life
7.3 og eldre, inkludert PHP 5	alle versjoner, ifølge Calif og watchTowr	ingen rettelse fra upstream	End of life

PHPs sikkerhetsvarsler lister bare grenene som støttes. For eldre grener rapporterer Calif at «den tidligste berørte kodestien vi fant, går tilbake til PHP 5.4.0», og watchTowr oppgir PHP 7 og PHP 5 som berørt uten rettelse. PHP sier at grenene 8.1 og eldre «ikke lenger får oppdateringer fra PHP-prosjektet», men publiserte minimale tilbakeporteringer i kildekode for 7.4, 8.0 og 8.1 for dem som bygger fra kildekode. Noen distribusjoner og kommersielle leverandører av langtidsstøtte leverer tilbakeporterte rettelser for grener som har nådd end of life; spør din. Hvis du tester neste hovedversjon, inneholder også PHP 8.6.0 RC4, utgitt samme dag, rettelsene.

Slik fungerer det

Begge CVE-ene er minnesikkerhetsfeil i måten PHP setter opp og river ned en forespørsel på, under all applikasjonskode. CVE-oppføringene klassifiserer begge som use after free (CWE-416), sammen med feil håndtering av unntakstilstander, tilgang via en uinitialisert peker, ukontrollert minneallokering og feil initialisering (CWE-755, CWE-824, CWE-1325, CWE-1419). Med PHPs egne ord:

• CVE-2026-109618, RCE via OOM-korrupsjon: «håndteringen av minnemangel kan avbryte PHP mens interne forespørselsdata bare er delvis initialisert. Oppryddingen etter forespørselen kan da behandle de ugyldige dataene som gyldige.» En forespørselskropp laget for å bruke opp minnet mens PHP tolker den, kan utløse det avbruddet. Apache med mod_php kjører oppryddingen selv når oppstarten av forespørselen mislyktes, og derfor virker angrepet der før noen applikasjonskode kjører. For PHP-FPM sier PHPs sikkerhetsvarsel at analyse av kildekoden tilsier at den er sårbar, selv om ingen fullstendig exploit mot FPM er demonstrert.
• CVE-2026-109619, RCE via utdatert global tilstand: «intern tilstand som eies av en forespørsel, kan overleve etter at minnet bak den er frigjort. En senere forespørsel som håndteres av den samme workeren, kan bruke den utdaterte tilstanden før den normale initialiseringen tilbakestiller den.» Det krever to forespørsler som når den samme workeren: én som etterlater tilstanden, for eksempel gjennom en fatal feil, og én som bruker den. PHPs sikkerhetsvarsel bekrefter veien via session upload progress mot mod_php og FPM, og veien via backtraces ved fatale feil i PHP 8.5 mot mod_php.

Derfor retter PHPs midlertidige innstillinger seg mot minnegrenser, størrelsen på forespørselskroppen, session upload progress og backtraces ved fatale feil: Hver av dem stenger én vei til feilene, ikke selve feilene. PHP vurderer som CNA begge til 9,2 etter CVSS 4.0. NVDs egne vurderinger etter CVSS 3.1 er 9,8 for CVE-2026-109618 og 8,1 for CVE-2026-109619.

Slik sjekker du om du er berørt

Begynn med vertene du kjenner til, og let deretter etter PHP i alt du bygger og leverer.

På en vert eller VM sjekker du versjonen PHP rapporterer. Sjekk også web-SAPI-en, siden php-fpm eller Apache-modulen kan komme fra en annen pakke enn kommandolinjen:

php -v
php-fpm -v

Distribusjonspakker (Debian, Ubuntu, Alpine, RHEL) får ofte rettelsen som en tilbakeportering uten ny upstream-versjon: Ubuntu 24.04 leverer for eksempel rettelsen som 8.3.6-0ubuntu0.24.04.13. Her villeder en versjonssjekk alene. List opp den installerte pakken og sammenlign den med den rettede pakkeversjonen i sikkerhetssporingen til distribusjonen din:

dpkg -l 'php*' | grep '^ii'    # Debian, Ubuntu
apk info -v | grep '^php'      # Alpine
rpm -qa 'php*'                 # RHEL, Fedora, Rocky, Alma

I container-images. Offisielle php:-images kompilerer PHP fra kildekode, så versjonen ligger i selve imaget, ikke i en pakkeliste fra distribusjonen. Spør imaget direkte:

docker run --rm --entrypoint php php:8.3-fpm -v

For å sjekke hvert image du faktisk kjører, lister du dem opp og spør hvert enkelt. For Kubernetes:

kubectl get pods -A \
  -o jsonpath='{range .items[*]}{range .spec.containers[*]}{.image}{"\n"}{end}{end}' \
  | sort -u \
  | while read -r image; do
      version=$(docker run --rm --entrypoint php "$image" -r 'echo PHP_VERSION;' 2>/dev/null)
      printf '%s\t%s\n' "${version:-no php}" "$image"
    done

Images bygget FROM debian eller FROM alpine med PHP installert via pakkebehandleren trenger pakkesjekken over, kjørt inne i imaget.

I repositoriene dine søker du etter hvert sted PHP blir valgt:

git grep -nE '^FROM[[:space:]]+(.*/)?php:' -- '*Dockerfile*' '*.dockerfile'
git grep -nE 'php-version|image:.*php' -- .github/workflows '*.yml' '*.yaml'

Faste tagger som php:8.3.30-fpm forblir sårbare til noen endrer dem. Flytende tagger som php:8.3-fpm ble bygget på nytt med de rettede versjonene fra 21. oktober, men et image bygget før det beholder den gamle PHP-en til du bygger det på nytt. php-kravet i composer.json sier hvilke versjoner koden din godtar, ikke hvilken som kjører.

I CI. Bygge- og testjobber bruker ofte sin egen PHP: en php:-tjenestecontainer, en setup-action med inndataen php-version eller et runner-image. De håndterer ikke produksjonstrafikk, men de viser hvilke images og versjoner pipelinen din produserer.

Eksponerte verter. Searchlight Cybers php2shell-scanner tester en URL med store multipart-forespørsler, rundt 29 MiB per sti. Kjør den bare mot verter du har tillatelse til å teste. README-en advarer om falske positiver på patchet PHP med lav memory_limit, og når PHP ikke oppgir versjonen sin, kan skanneren ikke skille en patchet server fra en sårbar. Bruk den som en pekepinn, ikke som bevis. NCSC-NLs repositorium samler deteksjonsregler og en liste over produkter som leveres med PHP, med status for hvert.

Det dagens skanning ikke kan fortelle deg. En skanning av imagene i registeret ditt i dag dekker det du ville rullet ut i dag. Den dekker ikke en tidligere utgivelse du har levert til en kunde, den gamle taggen en kunde fortsatt kjører, eller hvilke av byggene dine som produserte images med en sårbar PHP. Til det trenger du en registrering av hva hvert bygg tok inn, per utgivelse. Se er vi berørt? slik vurderer du en ny CVE på tvers av byggene dine.

Slik retter du det, og hva du gjør hvis du ikke kan patche ennå

1. Oppgrader til 8.5.12, 8.4.27, 8.3.36 eller 8.2.35, eller til den rettede pakken fra distribusjonen din. På 8.1 eller eldre går du over til en gren som støttes; PHPs tilbakeporteringer og leverandørenes bygg er nødløsninger.
2. Bygg hvert image på nytt fra en rettet base (hent base-imaget på nytt, eller bygg uten cache) og rull ut på nytt. Images som allerede kjører, beholder den gamle PHP-en til de erstattes, så start arbeidslastene på nytt også.
3. Bekreft med sjekklisten nedenfor, mot containerne som kjører, ikke bare mot det nye imaget.

Hvis du ikke kan oppgradere ennå, lister PHPs sikkerhetsvarsel tiltak som «reduserer eksponeringen for bestemte angrepsveier, men ikke gjør en installasjon trygg.» For CVE-2026-109618:

• «Sett memory_limit=-1, helst på en måte applikasjoner ikke kan overstyre, for eksempel php_admin_value i FPM-poolen eller Apache-konfigurasjonen, og sjekk at ingen pool-, katalog- eller applikasjonsinnstilling setter en endelig grense tilbake.»
• «For applikasjoner som ikke krever filopplasting, sett post_max_size = 8M. Hvis filopplasting er nødvendig, sett post_max_size = 32M. Hold upload_max_filesize under post_max_size.»
• Bruk en minnegrense for containeren eller cgroupen som tilgjengelighetsgrense, og ikke erstatt den med RLIMIT_AS eller RLIMIT_DATA, «siden disse kan forårsake den sårbare allokeringsfeilen.»

For CVE-2026-109619:

• «Sett session.upload_progress.enabled=0 og start hver worker på nytt. Bruk php.ini, en FPM-pool eller serverkonfigurasjon som gjelder før forespørselen tolkes. Ikke stol på ini_set() eller FPMs .user.ini.»
• «På PHP 8.5, sett fatal_error_backtraces=0 og start hver worker på nytt.»

Sjekk hva hver worker faktisk kjører med:

php-fpm -i | grep -E 'memory_limit|post_max_size|session.upload_progress.enabled'

CISAs varsel går lenger: Organisasjoner som ikke kan oppdatere umiddelbart, eller som fortsatt kjører PHP 8.1 eller eldre, «bør ta PHP-baserte systemer offline til de kan patches eller oppdateres.» Det anbefaler også å følge med på PHP-workerprosesser som starter skall eller laster ned verktøy.

Bekreft rettelsen

1. Spør PHP-en som kjører, ikke imaget du hadde tenkt å rulle ut. Kjør php-fpm -v (eller php -v) i hver container som kjører og på hver vert, og bekreft 8.5.12, 8.4.27, 8.3.36, 8.2.35 eller nyere.
2. Ikke stol på versjonsstrengen alene for distribusjonspakker. Debian, Ubuntu, RHEL og andre distribusjoner tilbakeporterer rettelsen til versjonen de allerede leverer, så en patchet PHP kan fortsatt rapportere 8.3.6: Ubuntu 24.04 sin rettelse er 8.3.6-0ubuntu0.24.04.13. Sammenlign hele pakkeversjonen med sikkerhetssporingen til distribusjonen din, eller se etter CVE-en i endringsloggen til pakken, som som regel nevner den. Fellen virker også andre veien: En skanner som bare sammenligner versjonsnumre fra upstream, kan flagge en tilbakeportert pakke som sårbar.
3. Sjekk at hver arbeidslast kjører det nybygde imaget. En tagg som nå peker på et rettet image, endrer ikke en pod som hentet det gamle. Sammenlign image-digesten hver container kjører, med digesten du bygde:

kubectl get pods -A \
  -o jsonpath='{range .items[*]}{range .status.containerStatuses[*]}{.image}{"\t"}{.imageID}{"\n"}{end}{end}'

4. Sjekk at hver worker er startet på nytt. PHP-FPM og Apache har den gamle koden lastet inn til de startes på nytt; prosessjekken under «Sjekk om du er kompromittert» viser dem som fortsatt kjører den.
5. Hvis du fortsatt er avhengig av de midlertidige innstillingene, sjekker du hver pool med kommandoen php-fpm -i over, og beholder dem til oppgraderingen er gjennomført overalt.
6. Kjør oversikten på nytt fra sjekkavsnittet på tvers av registeret ditt, CI-imagene og utgivelsene kundene kjører, ikke bare produksjon.

Sjekk om du er kompromittert

PHP2Shell utnyttes aktivt, og Amazon så det første forsøket 17. oktober 2026, fire dager før rettelsen. Hvis en internetteksponert PHP på noe tidspunkt siden da kjørte en berørt versjon uten de midlertidige innstillingene, bør du sjekke den.

Hvor stor eksponeringen er. Tellinger av Shodan-bannere som Mallory publiserte 20. oktober, omtalt av CybelAngel, fant 2,24 millioner internetteksponerte verter som oppgir PHP; av de rundt 1,5 millioner som viser en versjon, kjører 883 717 (59 %) en gren uten offisiell rettelse. Dette er tellinger av verter, ikke av bekreftet sårbare systemer: Tilbakeporterte pakker kan se gamle ut og likevel være patchet, og rundt 740 000 verter skjuler versjonen sin.

Enheter og produkter som leveres med PHP. PHP kjører også i dedikerte enheter, nettverksutstyr, administrasjonsgrensesnitt og leverandørprodukter der du kanskje ikke kan oppdatere den selv. NCSC-NLs oversikt fulgte 968 slike produkter 9. november 2026: 205 rettet, 215 sårbare, 93 under undersøkelse, 240 avhengige av kjøretiden og 214 ikke berørt. Sjekk disse produktene separat, og installer leverandørenes oppdateringer så snart de er tilgjengelige.

Sørg for at rettelsen faktisk kjører. På verter og VM-er kjører en PHP-FPM-, php-cgi- eller Apache-prosess som startet før oppgraderingen, fortsatt den gamle koden. Minnekartet dens viser da den erstattede binærfilen eller libphp som slettet. Sammenlign også starttidspunktene til prosessene med tidspunktet for oppgraderingen:

for pid in $(pgrep -f 'php-fpm|php-cgi|apache2|httpd|frankenphp'); do
  grep -qE '(php|libphp)[^/]*\(deleted\)' "/proc/$pid/maps" 2>/dev/null \
    && echo "PID $pid still runs a replaced PHP"
done
ps -o pid,lstart,args -p "$(pgrep -d, -f 'php-fpm|php-cgi|apache2|httpd|frankenphp')"

Indikatorer fra primærkilder:

• Forespørsler: POST-forespørsler med skjemaopplasting som inneholder strengen PHP_SESSION_UPLOAD_PROGRESS, som Amazon Threat Intelligence så i utnyttelsesforsøk. Amazon lister også kildeadresser (103.216.220.92, 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188, 95.217.98.37), men påpeker at de tilhører delt anonymiseringsinfrastruktur: Undersøk et treff, men ikke behandle det som bevis.
• Prosesser og filer: PHP-workerprosesser som starter skall eller laster ned verktøy (CISA, som la til en Sigma-deteksjonsregel 23. oktober), og uventet prosesskjøring eller uventede filendringer på webservere (Amazon).
• Logger: i logger fra Apache, PHP-FPM, omvendt proxy og tjenester: advarsler eller kjernefeil som gjentas før skript kjører, fatale feil og tolkningsfeil, og Maximum execution time exceeded. PHPs sikkerhetsvarsel legger til at «fravær av feil i loggene er ikke et bevis på sikkerhet.»

Når du skal anta at du er kompromittert. Hvis du finner noen av disse indikatorene, eller hvis en eksponert server kjørte en berørt PHP uten tiltak og loggene dine ikke kan utelukke utnyttelse, behandler du den som kompromittert. PHP beskriver konsekvensen som fjernkjøring av kode som webworkerens konto, og den kontoen kan som regel lese applikasjonens konfigurasjon og hemmeligheter.

Roter det workeren kunne lese. Databasepassord, API-nøkler og tokens i miljøvariabler og konfigurasjonsfiler, nøkler som signerer økter eller informasjonskapsler (og øktene som er signert med dem), og all skylegitimasjon verten har tilgang til. Roter etter at verten er bygget på nytt, så de nye hemmelighetene aldri ligger på en kompromittert maskin.

Bygg på nytt i stedet for å rydde opp. Erstatt en kompromittert vert eller container fra et kjent rent image, og ikke ta med filer workeren kunne skrive, som opplastingskataloger, cacher eller generert kode. Ikke gjenbruk images, byggecacher eller artefakter som er produsert på en kompromittert vert.

Hva du skal si til kundene dine

Hvis du leverer programvare som kjører på PHP, kommer kundene dine til å spørre. Svar med versjoner og tiltak, også før du har alle svarene. Et svar du kan tilpasse:

PHP2Shell (CVE-2026-109618, CVE-2026-109619) rammer PHP-versjoner før 8.5.12, 8.4.27, 8.3.36 og 8.2.35, og alle eldre PHP-grener. [Produkt] versjon [x til y] leveres med PHP [versjon] og er berørt; versjon [z], utgitt [dato], leveres med PHP [rettet versjon]. Oppgrader til [z]. Hvis du ikke kan oppgradere med en gang, bruk PHP-innstillingene i sikkerhetsvarselet vårt [lenke] og begrens nettverkstilgangen til applikasjonen. [Produkt] versjon [a til b] er ikke berørt. Vi oppdaterer dette varselet innen [dato].

Hvis du fortsatt sjekker, si det, og si når du kommer til å svare. En første uttalelse og maler for hvert utfall finner du i slik svarer du kunder etter et leverandørkjedeangrep.

Slik hjelper CRACI

CRACI kjører GitHub Actions-jobbene dine og registrerer hva hver jobb henter inn mens den bygger, inkludert container-images, apt- og apk-pakker og Composer-pakker, og tar vare på hvert tidligere bygg med SBOM-en. Når en CVE publiseres, flagger den kontinuerlige revurderingen de tidligere byggene som inneholdt den berørte pakken, så du ser hvilke utgivelser som var eksponert og hvor lenge, ikke bare hva dagens skanning finner. Policy gates kan blokkere bygg som inneholder en bestemt CVE.

Én begrensning ved denne hendelsen: PHP som er kompilert inn i et offisielt php:-image, kommer inn som en del av imaget, ikke som en pakkenedlasting. CRACI registrerer image-referansen hvert bygg hentet, så søk i byggene dine etter php:-taggene og ikke bare etter PHP-pakker.

Finn hvert bygg som leverte en sårbar PHP

Mer om registrering av bygg: SBOM-er fra bygget, SBOM-er for Docker-images, hva containerskanning går glipp av, CISA KEV-katalogen og trender i CVE-publisering. Andre hendelser: alle sårbarheter.

For PHP-sikkerhet utover denne hendelsen, se vår veiledning om PHP-sikkerhet.

Kilder og oppdateringer

Primærkilder:

• PHP: sikkerhetsvarsel fra 21. oktober 2026, informasjonsvarsel fra 23. oktober 2026, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp, støttede versjoner
• CVE-oppføringer: CVE-2026-109618, CVE-2026-109619
• CISA: varsel fra 21. oktober 2026, KEV-katalogen
• NCSC-NL: repositoriet php2shell
• NVD: CVE-2026-109618, CVE-2026-109619
• FIRST: EPSS-poeng

Forskning og analyse:

• Calif: PHP2Shell, a tale of two PHP remote vulnerabilities
• Amazon Threat Intelligence
• watchTowr
• Akamai
• CybelAngel
• Searchlight Cyber php2shell-scanner

Oppdateringer:

• 2026-11-11: La til NVDs poeng, EPSS, CWE-klasser, krediteringer, nyeste sikre versjoner og end of life-datoer i boksen, PHP 8.6.0 RC4, og avsnitt om hvordan feilene fungerer, hvordan du bekrefter rettelsen og hvordan du sjekker om du er kompromittert.
• 2026-11-11: Først publisert.