PHP2Shell: todentamaton RCE PHP:ssä ja näin tarkistat, koskeeko se buildejasi

PHP2Shell on kaksi kriittistä haavoittuvuutta itse PHP:ssä, CVE-2026-109618 ja CVE-2026-109619, jotka voivat antaa todentamattoman verkkopyynnön suorittaa koodia missä tahansa verkkopyyntöjä palvelevassa PHP-asennuksessa: PHP-FPM, Apache ja mod_php, php-cgi, FrankenPHP ja LiteSpeed. Kumpaakin hyödynnetään aktiivisesti, ja molemmat ovat CISA:n KEV-luettelossa. Korjaus on PHP 8.5.12, 8.4.27, 8.3.36 tai 8.2.35; PHP 8.1 ja vanhemmat eivät saa upstream-julkaisua. Päivitä, ja rakenna ja julkaise sitten uudelleen jokainen konttikuva, jossa on PHP, mukaan lukien yhä käynnissä olevat vanhat tagit ja asiakkaille toimittamasi kuvat.

Tuntemasi palvelimen paikkaaminen on helppo osa. Altistus, joka jää elämään, on se PHP, jonka unohdit: peruskonttikuvaan käännetty ajoympäristö, viime vuoden kuvatagi, joka on yhä tuotannossa, CI-kuva tai asiakkaille toimitettu tuote, jonka PHP on elinkaarensa lopussa. Tämä sivu auttaa sinua ensin paikkaamaan ja näyttää sitten, miten löydät loput.

Mitä tapahtui

Päivämäärä (2026)	Tapahtuma	Lähde
11. ja 21. elokuuta	Calif raportoi kaksi virhettä PHP-projektille	Calif
17. lokakuuta	Ensimmäinen hyödyntämisyritys, jonka Amazon havaitsi houkutuslaitteissaan (honeypot), ennen julkistamista	Amazon Threat Intelligence
20. lokakuuta	PHP ilmoittaa tietoturvajulkaisusta 21.10. klo 14.00 UTC, joka korjaa kaksi CVSS 4.0 -pisteillä 9,2 arvioitua haavoittuvuutta	php.net
21. lokakuuta	PHP julkaisee versiot 8.5.12, 8.4.27, 8.3.36 ja 8.2.35 sekä tietoturvatiedotteensa; CVE-tietueet julkistetaan; NCSC-NL avaa php2shell-repositorionsa	PHP:n tietoturvatiedote, NCSC-NL
21. lokakuuta	Viralliset Dockerin php-kuvat päivitetään korjattuihin versioihin	docker-library/php
21. lokakuuta	watchTowr raportoi molempien CVE:iden aktiivisesta hyödyntämisestä; CISA julkaisee varoituksen	watchTowr, CISA
22. lokakuuta	Searchlight Cyber julkaisee php2shell-scanner-työkalun	GitHub
23. lokakuuta	PHP neuvoo asettamaan session.upload_progress.enabled=0 erillisen, epätodennäköisen RCE-reitin, CVE-2026-115560:n, vuoksi	php.net
26. lokakuuta	CISA lisää molemmat CVE:t KEV-luetteloon, ja Yhdysvaltain liittovaltion virastojen määräpäivä on 29.10.	CISA KEV

Nimi PHP2Shell tulee Califin kirjoituksesta, ja sitä käytetään laajasti alan uutisoinnissa; PHP:n omat tietoturvatiedotteet eivät käytä sitä. CVE-tietueet nimeävät löytäjiksi ja raportoijiksi Califin, Wizin ja OpenAI:n.

Ketä haavoittuvuus koskee

Kaikkea PHP:tä, joka palvelee verkkopyyntöjä. PHP:n tietoturvatiedote nimeää PHP-FPM:n, Apachen ja mod_php:n, php-cgi:n, FrankenPHP:n ja LiteSpeedin ja pitää riskiä suurimpana mod_php:llä, ”jolle on osoitettu toimiva hyökkäys, jossa todentamaton pyyntö voi käynnistää hyökkäyksen ennen kuin mitään sovelluskoodia ajetaan.” Koska virheet ovat itse PHP:ssä, Laravelin, Symfonyn tai WordPressin päälle rakennetut sovellukset ovat alttiina aina, kun niiden alla oleva PHP on.

Haara	Haavoittuvat	Korjattu versiossa	Upstream-tuki
8.5	ennen 8.5.12:ta	8.5.12	Aktiivinen
8.4	ennen 8.4.27:ää	8.4.27	Aktiivinen
8.3	ennen 8.3.36:ta	8.3.36	Vain tietoturvakorjauksia 31.12.2027 asti
8.2	ennen 8.2.35:tä	8.2.35	Vain tietoturvakorjauksia 31.12.2026 asti
8.1, 8.0, 7.4	kaikki versiot Califin ja watchTowrin mukaan	ei julkaisua; minimaaliset lähdekoodin takaisinsiirrot php-src:ssä	Elinkaaren lopussa
7.3 ja vanhemmat, PHP 5 mukaan lukien	kaikki versiot Califin ja watchTowrin mukaan	ei upstream-korjausta	Elinkaaren lopussa

PHP:n tietoturvatiedotteet listaavat vain tuetut haarat. Vanhemmista Calif raportoi, että ”aikaisin löytämämme haavoittuva koodipolku ulottuu PHP 5.4.0:aan”, ja watchTowr listaa PHP 7:n ja PHP 5:n haavoittuviksi ilman korjausta. PHP:n mukaan haarat 8.1 ja vanhemmat ”eivät enää saa päivityksiä PHP-projektilta”, mutta se julkaisi minimaaliset lähdekoodin takaisinsiirrot versioille 7.4, 8.0 ja 8.1 niille, jotka rakentavat lähdekoodista. Osa jakeluista ja kaupallisista pitkäaikaistuen toimittajista toimittaa takaisinsiirrettyjä korjauksia elinkaarensa lopussa oleville haaroille; kysy omaltasi. Jos testaat seuraavaa pääversiota, samana päivänä julkaistu PHP 8.6.0 RC4 sisältää myös korjaukset.

Miten se toimii

Kumpikin CVE on muistiturvallisuusvirhe siinä, miten PHP alustaa ja purkaa pyynnön, kaiken sovelluskoodin alapuolella. CVE-tietueet luokittelevat molemmat use after free -virheiksi (CWE-416) sekä poikkeustilanteiden virheelliseksi käsittelyksi, alustamattoman osoittimen käytöksi, hallitsemattomaksi muistinvaraukseksi ja virheelliseksi alustukseksi (CWE-755, CWE-824, CWE-1325, CWE-1419). PHP:n sanoin:

• CVE-2026-109618, RCE muistin loppumisen aiheuttaman korruption kautta: ”muistin loppumisen käsittely voi keskeyttää PHP:n, kun pyynnön sisäinen data on vain osittain alustettu. Pyynnön siivous voi silloin käsitellä virheellistä dataa kelvollisena.” Pyynnön runko, joka on rakennettu kuluttamaan muisti loppuun PHP:n jäsentäessä sitä, voi laukaista tämän keskeytyksen. Apache ja mod_php ajavat siivouksen silloinkin, kun pyynnön käynnistys epäonnistui, minkä vuoksi hyökkäys toimii siellä ennen kuin mitään sovelluskoodia ajetaan. PHP-FPM:n osalta PHP:n tietoturvatiedote sanoo, että lähdekoodianalyysin perusteella se on altis, vaikka täydellistä FPM-hyökkäystä ei ole osoitettu.
• CVE-2026-109619, RCE vanhentuneen globaalin tilan kautta: ”pyynnön omistama sisäinen tila voi säilyä senkin jälkeen, kun sen taustalla oleva muisti on vapautettu. Saman workerin myöhemmin käsittelemä pyyntö voi käyttää tätä vanhentunutta tilaa ennen kuin normaali alustus nollaa sen.” Tarvitaan kaksi samaan workeriin päätyvää pyyntöä: yksi, joka jättää tilan jälkeensä esimerkiksi vakavan virheen (fatal error) kautta, ja yksi, joka käyttää sitä. PHP:n tietoturvatiedote vahvistaa session upload progress -polun mod_php:tä ja FPM:ää vastaan sekä PHP 8.5:n vakavien virheiden backtrace-polun mod_php:tä vastaan.

Siksi PHP:n väliaikaiset asetukset kohdistuvat muistirajoihin, pyynnön rungon kokoon, session upload progressiin ja vakavien virheiden backtraceihin: kukin sulkee yhden polun virheisiin, ei virheitä itseään. PHP antaa CNA:na molemmille pisteet 9,2 CVSS 4.0:n mukaan. NVD:n omat CVSS 3.1 -arviot ovat 9,8 CVE-2026-109618:lle ja 8,1 CVE-2026-109619:lle.

Näin tarkistat, koskeeko haavoittuvuus sinua

Aloita tuntemistasi palvelimista ja etsi sitten PHP:tä kaikesta, mitä rakennat ja toimitat.

Palvelimella tai virtuaalikoneessa tarkista PHP:n ilmoittama versio. Tarkista myös verkko-SAPI, koska php-fpm tai Apache-moduuli voi tulla eri paketista kuin komentorivi:

php -v
php-fpm -v

Jakelupaketit (Debian, Ubuntu, Alpine, RHEL) saavat korjauksen usein takaisinsiirtona ilman uutta upstream-versiota: esimerkiksi Ubuntu 24.04 toimittaa korjauksen versiona 8.3.6-0ubuntu0.24.04.13. Pelkkä versiotarkistus johtaa tässä harhaan. Listaa asennettu paketti ja vertaa sitä jakelusi tietoturvaseurannan korjattuun pakettiversioon:

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

Konttikuvissa. Viralliset php:-kuvat kääntävät PHP:n lähdekoodista, joten versio on itse kuvassa eikä jakelun pakettilistassa. Kysy suoraan kuvalta:

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

Kun haluat tarkistaa jokaisen kuvan, jota todella ajat, listaa ne ja kysy kultakin. Kubernetesissa:

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

Kuvat, jotka on rakennettu FROM debian- tai FROM alpine-pohjalta ja joihin PHP on asennettu paketinhallinnalla, tarvitsevat yllä olevan pakettitarkistuksen kuvan sisällä ajettuna.

Repositorioissasi etsi jokainen kohta, jossa PHP valitaan:

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

Kiinnitetyt tagit, kuten php:8.3.30-fpm, pysyvät haavoittuvina, kunnes joku muuttaa ne. Liukuvat tagit, kuten php:8.3-fpm, rakennettiin korjatuilla versioilla 21.10. alkaen, mutta sitä ennen rakennettu kuva pitää vanhan PHP:n, kunnes rakennat sen uudelleen. php-rajoite composer.json-tiedostossa kertoo, mitkä versiot koodisi hyväksyy, ei sitä, mikä on käytössä.

CI:ssä. Build- ja testijobit käyttävät usein omaa PHP:tään: php:-palvelukonttia, setup-actionia php-version-syötteellä tai runnerin kuvaa. Ne eivät palvele tuotantoliikennettä, mutta ne näyttävät, mitä kuvia ja versioita putkesi tuottaa.

Näkyvissä olevat palvelimet. Searchlight Cyberin php2shell-scanner testaa URL-osoitteen suurilla multipart-pyynnöillä, noin 29 MiB polkua kohden. Aja sitä vain palvelimia vastaan, joiden testaamiseen sinulla on lupa. Sen README varoittaa vääristä positiivisista tuloksista paikatulla PHP:llä, jonka memory_limit on matala, ja kun PHP ei kerro versiotaan, skanneri ei erota paikattua palvelinta haavoittuvasta. Pidä sitä vihjeenä, ei todisteena. NCSC-NL:n repositorio kokoaa havaitsemissääntöjä ja listan PHP:tä sisältävistä tuotteista tiloineen.

Mitä tämänpäiväinen skannaus ei kerro. Rekisterisi kuvien skannaus tänään kattaa sen, mitä julkaisisit tänään. Se ei kata aiempaa julkaisua, jonka toimitit asiakkaalle, vanhaa tagia, jota asiakas yhä ajaa, eikä sitä, mitkä buildisi tuottivat kuvia, joissa on haavoittuva PHP. Siihen tarvitset kirjauksen siitä, mitä kukin buildi otti mukaan, julkaisu kerrallaan. Katso koskeeko tämä meitä? näin arvioit uuden CVE:n kaikissa buildeissasi.

Näin korjaat sen, ja mitä tehdä, jos et voi vielä paikata

1. Päivitä versioon 8.5.12, 8.4.27, 8.3.36 tai 8.2.35 tai jakelusi korjattuun pakettiin. Versiossa 8.1 tai vanhemmassa siirry tuettuun haaraan; PHP:n takaisinsiirrot ja toimittajien buildit ovat väliaikaisratkaisuja.
2. Rakenna jokainen kuva uudelleen korjatusta pohjasta (vedä peruskuva uudelleen tai rakenna ilman välimuistia) ja julkaise uudelleen. Jo käynnissä olevat kuvat pitävät vanhan PHP:nsä, kunnes ne korvataan, joten käynnistä myös kuormat uudelleen.
3. Varmista alla olevalla tarkistuslistalla käynnissä olevista konteista, ei vain uudesta kuvasta.

Jos et voi vielä päivittää, PHP:n tietoturvatiedote listaa toimia, jotka ”vähentävät altistumista tietyille hyökkäyspoluille mutta eivät tee asennuksesta turvallista.” CVE-2026-109618:lle:

• ”Aseta memory_limit=-1, mieluiten tavalla, jota sovellukset eivät voi ohittaa, kuten php_admin_value FPM-poolissa tai Apachen konfiguraatiossa, ja tarkista, ettei mikään pooli-, hakemisto- tai sovellusasetus palauta äärellistä rajaa.”
• ”Sovelluksille, jotka eivät tarvitse tiedostolatauksia, aseta post_max_size = 8M. Jos tiedostolataukset ovat tarpeen, aseta post_max_size = 32M. Pidä upload_max_filesize pienempänä kuin post_max_size.”
• Käytä kontin tai cgroupin muistirajaa saatavuuden rajana, äläkä korvaa sitä RLIMIT_AS- tai RLIMIT_DATA-rajalla, ”koska ne voivat aiheuttaa haavoittuvan muistinvarauksen epäonnistumisen.”

CVE-2026-109619:lle:

• ”Aseta session.upload_progress.enabled=0 ja käynnistä jokainen worker uudelleen. Käytä php.ini-tiedostoa, FPM-poolia tai palvelinkonfiguraatiota, joka on voimassa ennen pyynnön jäsentämistä. Älä luota ini_set()-kutsuun tai FPM:n .user.ini-tiedostoon.”
• ”Aseta PHP 8.5:ssä fatal_error_backtraces=0 ja käynnistä jokainen worker uudelleen.”

Tarkista, millä asetuksilla kukin worker todella toimii:

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

CISA:n varoitus menee pidemmälle: organisaatioiden, jotka eivät voi päivittää heti tai jotka ajavat yhä PHP 8.1:tä tai vanhempaa, ”tulisi ottaa PHP-pohjaiset järjestelmät pois verkosta, kunnes ne voidaan paikata tai päivittää.” Se neuvoo myös seuraamaan PHP-workeriprosesseja, jotka käynnistävät komentotulkkeja tai lataavat työkaluja.

Varmista korjaus

1. Kysy käynnissä olevalta PHP:ltä, älä kuvalta, jonka aioit julkaista. Aja php-fpm -v (tai php -v) jokaisessa käynnissä olevassa kontissa ja jokaisella palvelimella, ja varmista, että versio on 8.5.12, 8.4.27, 8.3.36, 8.2.35 tai uudempi.
2. Älä luota jakelupaketeissa pelkkään versiomerkkijonoon. Debian, Ubuntu, RHEL ja muut jakelut siirtävät korjauksen takaisin jo toimittamaansa versioon, joten paikattu PHP voi silti ilmoittaa versioksi 8.3.6: Ubuntu 24.04:n korjaus on 8.3.6-0ubuntu0.24.04.13. Vertaa koko pakettiversiota jakelusi tietoturvaseurantaan tai etsi CVE paketin muutoslokista, jossa se yleensä mainitaan. Ansa toimii myös toisin päin: skanneri, joka vertaa vain upstream-versionumeroita, voi merkitä takaisinsiirretyn paketin haavoittuvaksi.
3. Tarkista, että jokainen kuorma ajaa uudelleen rakennettua kuvaa. Tagi, joka nyt osoittaa korjattuun kuvaan, ei muuta podia, joka veti vanhan. Vertaa kunkin kontin ajaman kuvan tiivistettä (digest) rakentamaasi tiivisteeseen:

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

4. Tarkista, että jokainen worker käynnistyi uudelleen. PHP-FPM ja Apache pitävät vanhan koodin ladattuna, kunnes ne käynnistyvät uudelleen; kohdan ”Tarkista, onko järjestelmä murrettu” prosessitarkistus näyttää ne, jotka ajavat sitä yhä.
5. Jos luotat yhä väliaikaisiin asetuksiin, tarkista jokainen pooli yllä olevalla php-fpm -i-komennolla ja pidä asetukset voimassa, kunnes päivitys on tehty kaikkialla.
6. Tee inventaario uudelleen tarkistusosion ohjeilla koko rekisterissäsi, CI-kuvissa ja asiakkaiden ajamissa julkaisuissa, ei vain tuotannossa.

Tarkista, onko järjestelmä murrettu

PHP2Shelliä hyödynnetään aktiivisesti, ja Amazon havaitsi ensimmäisen yrityksen 17.10.2026, neljä päivää ennen korjausta. Jos internetiin näkyvä PHP ajoi haavoittuvaa versiota ilman väliaikaisia asetuksia milloin tahansa sen jälkeen, tarkista se.

Kuinka laaja altistus on. Mallory julkaisi 20.10. Shodanin bannerimäärät, joista CybelAngel raportoi: 2,24 miljoonaa internetiin näkyvää palvelinta ilmoitti käyttävänsä PHP:tä; noin 1,5 miljoonasta versionsa näyttävästä 883 717 (59 %) ajaa haaraa, jolle ei ole virallista korjausta. Luvut laskevat palvelimia, eivät vahvistetusti haavoittuvia järjestelmiä: takaisinsiirretyt paketit voivat näyttää vanhoilta ja olla silti paikattuja, ja noin 740 000 palvelinta piilottaa versionsa.

Laitteet ja tuotteet, joihin PHP sisältyy. PHP toimii myös laitteissa, verkkolaitteissa, hallintaliittymissä ja toimittajien tuotteissa, joissa et välttämättä voi päivittää sitä itse. NCSC-NL:n inventaario seurasi 9.11.2026 yhteensä 968 tällaista tuotetta: 205 korjattua, 215 haavoittuvaa, 93 selvityksen alla, 240 ajoympäristöstä riippuvaa ja 214, joita haavoittuvuus ei koske. Tarkista nämä tuotteet erikseen ja asenna toimittajien päivitykset heti, kun niitä on saatavilla.

Varmista, että korjaus on todella käytössä. Palvelimilla ja virtuaalikoneissa ennen päivitystä käynnistynyt PHP-FPM-, php-cgi- tai Apache-prosessi ajaa yhä vanhaa koodia. Sen muistikartta näyttää silloin korvatun binäärin tai libphp:n poistettuna. Vertaa myös prosessien käynnistysaikoja päivityksen ajankohtaan:

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')"

Ensisijaisten lähteiden indikaattorit:

• Pyynnöt: lomakelatauksen POST-pyynnöt, jotka sisältävät merkkijonon PHP_SESSION_UPLOAD_PROGRESS, jonka Amazon Threat Intelligence havaitsi hyödyntämisyrityksissä. Amazon listaa myös lähdeosoitteita (103.216.220.92, 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188, 95.217.98.37), mutta huomauttaa niiden kuuluvan jaettuun anonymisointi-infrastruktuuriin: tutki osuma, mutta älä pidä sitä todisteena.
• Prosessit ja tiedostot: PHP-workeriprosessit, jotka käynnistävät komentotulkkeja tai lataavat työkaluja (CISA, joka lisäsi Sigma-havaitsemissäännön 23.10.), sekä odottamaton prosessien suoritus tai tiedostomuutokset verkkopalvelimilla (Amazon).
• Lokit: Apachen, PHP-FPM:n, käänteisen välityspalvelimen ja palvelujen lokeissa ennen skriptien ajoa toistuvat varoitukset tai ydinvirheet, vakavat virheet ja jäsennysvirheet sekä Maximum execution time exceeded. PHP:n tietoturvatiedote lisää, että ”virheen puuttuminen lokeista ei todista turvallisuutta.”

Milloin olettaa murto. Jos löydät minkä tahansa näistä indikaattoreista, tai jos näkyvissä ollut palvelin ajoi haavoittuvaa PHP:tä ilman lievennyksiä eivätkä lokisi voi sulkea hyödyntämistä pois, käsittele sitä murrettuna. PHP kuvaa vaikutuksen etäkoodin suorittamiseksi verkkoworkerin käyttäjätilillä, ja tämä tili voi yleensä lukea sovelluksen konfiguraation ja salaisuudet.

Vaihda kaikki, mitä worker pystyi lukemaan. Tietokantasalasanat, API-avaimet ja tokenit ympäristömuuttujissa ja konfiguraatiotiedostoissa, istuntoja tai evästeitä allekirjoittavat avaimet (ja niillä allekirjoitetut istunnot) sekä kaikki palvelimen käytettävissä olevat pilvitunnisteet. Vaihda ne vasta, kun palvelin on rakennettu uudelleen, jotta uudet salaisuudet eivät koskaan päädy murretulle koneelle.

Rakenna uudelleen, älä siivoa. Korvaa murrettu palvelin tai kontti tunnetusti puhtaasta kuvasta, äläkä siirrä mukaan tiedostoja, joihin worker pystyi kirjoittamaan, kuten latauskansioita, välimuisteja tai generoitua koodia. Älä käytä uudelleen kuvia, build-välimuisteja tai artefakteja, jotka on tuotettu murretulla palvelimella.

Mitä kertoa asiakkaillesi

Jos toimitat ohjelmistoa, joka toimii PHP:n varassa, asiakkaasi kysyvät. Vastaa versioilla ja toimenpiteillä, jo ennen kuin sinulla on kaikki vastaukset. Vastaus, jota voit muokata:

PHP2Shell (CVE-2026-109618, CVE-2026-109619) koskee PHP-versioita ennen versioita 8.5.12, 8.4.27, 8.3.36 ja 8.2.35 sekä kaikkia vanhempia PHP-haaroja. [Tuotteen] versiot [x–y] sisältävät PHP:n [version] ja ovat haavoittuvia; [pvm] julkaistu versio [z] sisältää PHP:n [korjattu versio]. Päivitä versioon [z]. Jos et voi päivittää heti, ota käyttöön tietoturvatiedotteemme [linkki] PHP-asetukset ja rajoita verkkopääsyä sovellukseen. [Tuotteen] versiot [a–b] eivät ole haavoittuvia. Päivitämme tätä tiedotetta viimeistään [pvm].

Jos tarkistat vielä, kerro se ja kerro, milloin vastaat. Ensimmäisen alustavan tiedotteen ja pohjat kuhunkin lopputulokseen löydät oppaasta näin vastaat asiakkaille toimitusketjuhyökkäyksen jälkeen.

Miten CRACI auttaa

CRACI ajaa GitHub Actions -jobisi ja kirjaa buildin aikana, mitä kukin jobi hakee, mukaan lukien konttikuvat, apt- ja apk-paketit sekä Composer-paketit, ja se säilyttää jokaisen aiemman buildin SBOM:ineen. Kun CVE julkaistaan, jatkuva uudelleenarviointi merkitsee aiemmat buildit, jotka sisälsivät haavoittuvan paketin, joten näet, mitkä julkaisut olivat alttiina ja kuinka kauan, etkä vain sitä, mitä tämänpäiväinen skannaus löytää. Käytäntöportit voivat estää buildit, jotka sisältävät tietyn CVE:n.

Yksi rajoitus tässä tapauksessa: viralliseen php:-kuvaan käännetty PHP tulee kuvan sisällä eikä pakettilatauksena. CRACI kirjaa kuvaviittauksen, jonka kukin buildi haki, joten etsi buildeistasi php:-tageja eikä vain PHP-paketteja.

Löydä jokainen buildi, joka toimitti haavoittuvan PHP:n

Lisää buildien kirjauksista: buildin aikaiset SBOM:t, Docker-kuvien SBOM:t, mitä konttiskannaus ohittaa, CISA KEV -luettelo ja CVE-julkaisujen trendit. Muut tapaukset: kaikki haavoittuvuudet.

PHP:n tietoturvasta tämän tapauksen ulkopuolella kertoo PHP-tietoturvaoppaamme.

Lähteet ja päivitykset

Ensisijaiset lähteet:

• PHP: tietoturvatiedote 21.10.2026, tiedote 23.10.2026, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp, tuetut versiot
• CVE-tietueet: CVE-2026-109618, CVE-2026-109619
• CISA: varoitus 21.10.2026, KEV-luettelo
• NCSC-NL: php2shell-repositorio
• NVD: CVE-2026-109618, CVE-2026-109619
• FIRST: EPSS-pisteet

Tutkimus ja analyysi:

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

Päivitykset:

• 2026-11-11: Lisätty ruutuun NVD:n pisteet, EPSS, CWE-luokat, löytäjät ja raportoijat, uusimmat turvalliset versiot ja tuen päättymispäivät, PHP 8.6.0 RC4 sekä osiot virheiden toiminnasta, korjauksen varmistamisesta ja murron tarkistamisesta.
• 2026-11-11: Julkaistu ensimmäisen kerran.