PHP2Shell: RCE non autenticata in PHP e come verificare se le Sue build sono colpite

PHP2Shell sono due vulnerabilità critiche in PHP stesso, CVE-2026-109618 e CVE-2026-109619, che possono permettere a una richiesta web non autenticata di eseguire codice su qualsiasi installazione PHP che serve richieste web: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Entrambe sono sfruttate attivamente e presenti nel catalogo KEV della CISA. La correzione è PHP 8.5.12, 8.4.27, 8.3.36 o 8.2.35; PHP 8.1 e le versioni precedenti non ricevono alcuna release upstream. Aggiorni, poi ricostruisca e ridistribuisca ogni immagine container che contiene PHP, compresi i vecchi tag ancora in esecuzione e le immagini consegnate ai clienti.

Applicare la patch al server che conosce è la parte facile. L'esposizione che resta è il PHP che ha dimenticato: un runtime compilato in un'immagine di base, un tag di immagine dell'anno scorso ancora in produzione, un'immagine CI o un prodotto consegnato ai clienti con un PHP a fine vita. Questa pagina La aiuta prima ad applicare la patch, poi mostra come trovare il resto.

Che cosa è successo

Data (2026)	Evento	Fonte
11 e 21 agosto	Calif segnala i due bug al progetto PHP	Calif
17 ottobre	Il primo tentativo di sfruttamento osservato da Amazon nei suoi honeypot, prima della divulgazione	Amazon Threat Intelligence
20 ottobre	PHP annuncia una release di sicurezza per il 21 ottobre, alle 14:00 UTC, che corregge due vulnerabilità con punteggio CVSS 4.0 di 9,2	php.net
21 ottobre	PHP rilascia 8.5.12, 8.4.27, 8.3.36 e 8.2.35 e pubblica il suo advisory; i record CVE diventano pubblici; NCSC-NL apre il suo repository php2shell	Advisory di PHP, NCSC-NL
21 ottobre	Le immagini Docker ufficiali php vengono aggiornate alle versioni corrette	docker-library/php
21 ottobre	watchTowr segnala lo sfruttamento attivo di entrambe le CVE; la CISA pubblica un alert	watchTowr, CISA
22 ottobre	Searchlight Cyber pubblica php2shell-scanner	GitHub
23 ottobre	PHP consiglia di impostare session.upload_progress.enabled=0 per un vettore RCE distinto e improbabile, CVE-2026-115560	php.net
26 ottobre	La CISA aggiunge entrambe le CVE al catalogo KEV, con scadenza al 29 ottobre per le agenzie federali statunitensi	CISA KEV

Il nome PHP2Shell deriva dall'analisi di Calif ed è usato in tutta la copertura del settore; gli advisory di PHP non lo usano. I record CVE riconoscono il merito a Calif, Wiz e OpenAI.

Chi è colpito

Qualsiasi PHP che serve richieste web. L'advisory di PHP indica PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed, e considera il rischio più alto per mod_php, "con un exploit dimostrato in cui una richiesta non autenticata può avviare l'attacco prima che venga eseguito qualsiasi codice dell'applicazione". Poiché i bug sono in PHP stesso, le applicazioni basate su Laravel, Symfony o WordPress sono esposte ogni volta che lo è il PHP sottostante.

Branch	Colpite	Corretto in	Supporto upstream
8.5	precedenti a 8.5.12	8.5.12	Attivo
8.4	precedenti a 8.4.27	8.4.27	Attivo
8.3	precedenti a 8.3.36	8.3.36	Solo correzioni di sicurezza, fino al 31 dicembre 2027
8.2	precedenti a 8.2.35	8.2.35	Solo correzioni di sicurezza, fino al 31 dicembre 2026
8.1, 8.0, 7.4	tutte le versioni, secondo Calif e watchTowr	nessuna release; backport minimi del sorgente in php-src	Fine vita
7.3 e precedenti, incluso PHP 5	tutte le versioni, secondo Calif e watchTowr	nessuna correzione upstream	Fine vita

Gli advisory di PHP elencano solo i branch supportati. Per quelli più vecchi, Calif riferisce che "il percorso colpito più vecchio che abbiamo trovato risale a PHP 5.4.0", e watchTowr indica PHP 7 e PHP 5 come colpiti e senza correzione. PHP afferma che i branch 8.1 e precedenti "non ricevono più aggiornamenti dal progetto PHP", ma ha pubblicato backport minimi del sorgente per 7.4, 8.0 e 8.1 per chi compila dal sorgente. Alcune distribuzioni e alcuni fornitori commerciali di supporto a lungo termine distribuiscono correzioni con backport per i branch a fine vita; chieda al Suo. Se sta testando la prossima versione major, anche PHP 8.6.0 RC4, rilasciata lo stesso giorno, contiene le correzioni.

Come funziona

Entrambe le CVE sono bug di sicurezza della memoria nel modo in cui PHP prepara e chiude una richiesta, al di sotto di qualsiasi codice applicativo. I record CVE classificano entrambe come use after free (CWE-416), insieme a gestione impropria di condizioni eccezionali, accesso a un puntatore non inizializzato, allocazione di memoria non controllata e inizializzazione errata (CWE-755, CWE-824, CWE-1325, CWE-1419). Con le parole di PHP:

• CVE-2026-109618, RCE tramite corruzione OOM: "la gestione dell'esaurimento della memoria può interrompere PHP mentre i dati interni della richiesta sono inizializzati solo in parte. La pulizia della richiesta può quindi trattare i dati non validi come validi." Un corpo della richiesta costruito per esaurire la memoria mentre PHP lo analizza può provocare questa uscita. Apache con mod_php esegue la pulizia anche quando l'avvio della richiesta non è riuscito, ed è per questo che lì l'attacco funziona prima che venga eseguito qualsiasi codice applicativo. Per PHP-FPM, l'advisory di PHP afferma che l'analisi del sorgente indica che è vulnerabile, anche se non è stato dimostrato alcun exploit completo per FPM.
• CVE-2026-109619, RCE tramite stato globale obsoleto: "lo stato interno appartenente a una richiesta può sopravvivere dopo che la memoria che lo contiene è stata liberata. Una richiesta successiva gestita dallo stesso worker può usare quello stato obsoleto prima che la normale inizializzazione lo reimposti." Servono due richieste che arrivino allo stesso worker: una che lascia lo stato residuo, per esempio tramite un errore fatale, e una che lo usa. L'advisory di PHP conferma il percorso dell'upload progress della sessione contro mod_php e FPM, e il percorso dei backtrace degli errori fatali di PHP 8.5 contro mod_php.

Per questo le impostazioni temporanee di PHP agiscono su limiti di memoria, dimensione del corpo della richiesta, upload progress della sessione e backtrace degli errori fatali: ciascuna chiude un percorso verso i bug, non i bug stessi. PHP, in qualità di CNA, assegna a entrambe un punteggio di 9,2 secondo CVSS 4.0. Le valutazioni CVSS 3.1 dello NVD sono 9,8 per CVE-2026-109618 e 8,1 per CVE-2026-109619.

Come verificare se è colpito

Inizi dagli host che conosce, poi cerchi PHP in tutto ciò che compila e distribuisce.

Su un host o una VM, controlli la versione che PHP riporta. Controlli anche la SAPI web, perché php-fpm o il modulo Apache possono provenire da un pacchetto diverso da quello della riga di comando:

php -v
php-fpm -v

I pacchetti delle distribuzioni (Debian, Ubuntu, Alpine, RHEL) ricevono spesso la correzione come backport senza una nuova versione upstream: Ubuntu 24.04, per esempio, distribuisce la correzione come 8.3.6-0ubuntu0.24.04.13. Qui un semplice controllo della versione è fuorviante. Elenchi il pacchetto installato e lo confronti con la versione corretta del pacchetto nel security tracker della Sua distribuzione:

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

Nelle immagini container. Le immagini ufficiali php: compilano PHP dal sorgente, quindi la versione si trova nell'immagine stessa, non in un elenco di pacchetti della distribuzione. Lo chieda direttamente all'immagine:

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

Per controllare ogni immagine che esegue davvero, le elenchi e interroghi ciascuna. Per 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

Le immagini costruite FROM debian o FROM alpine con PHP installato dal gestore di pacchetti richiedono il controllo dei pacchetti descritto sopra, eseguito all'interno dell'immagine.

Nei Suoi repository, cerchi ogni punto in cui viene scelto PHP:

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

I tag fissati come php:8.3.30-fpm restano vulnerabili finché qualcuno non li cambia. I tag mobili come php:8.3-fpm sono stati ricostruiti con le versioni corrette dal 21 ottobre, ma un'immagine costruita prima di quella data mantiene il vecchio PHP finché non la ricostruisce. Il vincolo php in composer.json indica quali versioni il Suo codice accetta, non quale viene eseguita.

In CI. I job di build e di test usano spesso un proprio PHP: un service container php:, una setup action con un input php-version o un'immagine del runner. Non servono traffico di produzione, ma mostrano quali immagini e versioni produce la Sua pipeline.

Host esposti. Il php2shell-scanner di Searchlight Cyber sonda un URL con grandi richieste multipart, circa 29 MiB per percorso. Lo esegua solo su host che è autorizzato a testare. Il suo README avverte di falsi positivi su PHP con patch e un memory_limit basso, e quando PHP non rivela la propria versione lo scanner non riesce a distinguere un server con patch da uno vulnerabile. Lo consideri un indizio, non una prova. Il repository di NCSC-NL raccoglie regole di rilevamento e un elenco di prodotti che includono PHP, con il loro stato.

Che cosa la scansione di oggi non può dirLe. Scansionare oggi le immagini nel Suo registry copre ciò che distribuirebbe oggi. Non copre una release precedente consegnata a un cliente, il vecchio tag che un cliente esegue ancora, né quali delle Sue build hanno prodotto immagini con un PHP vulnerabile. Per questo serve un registro di ciò che ogni build ha incluso, per release. Veda siamo colpiti? come valutare una nuova CVE in tutte le build.

Come correggere e che cosa fare se non può ancora applicare la patch

1. Aggiorni a 8.5.12, 8.4.27, 8.3.36 o 8.2.35, oppure al pacchetto corretto della Sua distribuzione. Con 8.1 o versioni precedenti, passi a un branch supportato; i backport di PHP e le build dei fornitori sono soluzioni temporanee.
2. Ricostruisca ogni immagine da una base corretta (scarichi di nuovo l'immagine di base o compili senza cache) e la ridistribuisca. Le immagini già in esecuzione mantengono il vecchio PHP finché non vengono sostituite, quindi riavvii anche i workload.
3. Verifichi con la checklist qui sotto, sui container in esecuzione, non solo sulla nuova immagine.

Se non può ancora aggiornare, l'advisory di PHP elenca misure che "riducono l'esposizione a specifici percorsi di attacco ma non rendono sicura un'installazione". Per CVE-2026-109618:

• "Impostare memory_limit=-1, preferibilmente in un modo che le applicazioni non possano sovrascrivere, ad esempio con php_admin_value nel pool FPM o nella configurazione di Apache, e verificare che nessuna impostazione di pool, directory o applicazione reintroduca un limite finito."
• "Per le applicazioni che non richiedono upload di file, impostare post_max_size = 8M. Se gli upload di file sono necessari, impostare post_max_size = 32M. Mantenere upload_max_filesize al di sotto di post_max_size."
• Usi un limite di memoria del container o del cgroup come confine di disponibilità, e non lo sostituisca con RLIMIT_AS o RLIMIT_DATA, "perché possono causare l'errore di allocazione vulnerabile".

Per CVE-2026-109619:

• "Impostare session.upload_progress.enabled=0 e riavviare ogni worker. Usare php.ini, un pool FPM o una configurazione del server che si applichi prima del parsing della richiesta. Non affidarsi a ini_set() o a .user.ini di FPM."
• "Su PHP 8.5, impostare fatal_error_backtraces=0 e riavviare ogni worker."

Controlli con quali impostazioni viene effettivamente eseguito ogni worker:

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

L'alert della CISA va oltre: le organizzazioni che non possono aggiornare subito, o che eseguono ancora PHP 8.1 o versioni precedenti, "dovrebbero mettere offline i sistemi basati su PHP finché non possono essere corretti o aggiornati". Consiglia inoltre di sorvegliare i processi worker di PHP che avviano shell o scaricano strumenti.

Verificare la correzione

1. Interroghi il PHP in esecuzione, non l'immagine che intendeva distribuire. Esegua php-fpm -v (o php -v) dentro ogni container in esecuzione e su ogni host, e verifichi che la versione sia 8.5.12, 8.4.27, 8.3.36, 8.2.35 o successiva.
2. Non si fidi della sola stringa di versione nei pacchetti delle distribuzioni. Debian, Ubuntu, RHEL e altre distribuzioni applicano la correzione con un backport alla versione che già distribuiscono, quindi un PHP corretto può ancora riportare 8.3.6: la correzione di Ubuntu 24.04 è 8.3.6-0ubuntu0.24.04.13. Confronti la versione completa del pacchetto con il security tracker della Sua distribuzione, o cerchi la CVE nel changelog del pacchetto, che di solito la cita. La trappola funziona anche al contrario: uno scanner che confronta solo i numeri di versione upstream può segnalare come vulnerabile un pacchetto con backport.
3. Verifichi che ogni workload esegua l'immagine ricostruita. Un tag che ora punta a un'immagine corretta non cambia un pod che ha scaricato quella vecchia. Confronti il digest dell'immagine eseguita da ogni container con il digest che ha compilato:

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

4. Verifichi che ogni worker sia stato riavviato. PHP-FPM e Apache mantengono caricato il vecchio codice finché non si riavviano; il controllo dei processi in "Verificare una possibile compromissione" mostra quelli che lo eseguono ancora.
5. Se si affida ancora alle impostazioni temporanee, controlli ogni pool con il comando php-fpm -i riportato sopra e le mantenga finché l'aggiornamento non è completato ovunque.
6. Ripeta l'inventario della sezione sulla verifica nel Suo registry, nelle immagini CI e nelle release eseguite dai clienti, non solo in produzione.

Verificare una possibile compromissione

PHP2Shell è sfruttata attivamente, e Amazon ha osservato il primo tentativo il 17 ottobre 2026, quattro giorni prima della correzione. Se un PHP esposto su internet ha eseguito una versione colpita senza le impostazioni temporanee in qualsiasi momento da allora, lo controlli.

Quanto è ampia l'esposizione. I conteggi dei banner Shodan pubblicati da Mallory il 20 ottobre, riportati da CybelAngel, hanno trovato 2,24 milioni di host esposti su internet che dichiarano PHP; dei circa 1,5 milioni che mostrano una versione, 883.717 (59%) eseguono un branch senza correzione ufficiale. Sono conteggi di host, non di sistemi vulnerabili confermati: i pacchetti con backport possono sembrare vecchi ed essere corretti, e circa 740.000 host nascondono la propria versione.

Appliance e prodotti che includono PHP. PHP gira anche all'interno di appliance, dispositivi di rete, interfacce di gestione e prodotti di fornitori in cui potrebbe non essere in grado di aggiornarlo da solo. L'inventario di NCSC-NL contava 968 prodotti di questo tipo al 9 novembre 2026: 205 corretti, 215 vulnerabili, 93 in fase di analisi, 240 dipendenti dal runtime e 214 non colpiti. Controlli questi prodotti separatamente e applichi gli aggiornamenti dei fornitori appena disponibili.

Si assicuri che la correzione sia davvero in esecuzione. Su host e VM, un processo PHP-FPM, php-cgi o Apache avviato prima dell'aggiornamento esegue ancora il vecchio codice. La sua mappa di memoria mostra allora il binario sostituito o libphp come eliminato. Confronti anche l'ora di avvio dei processi con l'ora dell'aggiornamento:

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

Indicatori dalle fonti primarie:

• Richieste: richieste POST di upload di form contenenti la stringa PHP_SESSION_UPLOAD_PROGRESS, che Amazon Threat Intelligence ha osservato nei tentativi di sfruttamento. Amazon elenca anche gli indirizzi di origine (103.216.220.92, 31.223.184.166, 37.19.200.5, 134.209.159.64, 103.114.163.188, 95.217.98.37), ma precisa che appartengono a un'infrastruttura di anonimizzazione condivisa: indaghi su una corrispondenza, non la consideri una prova.
• Processi e file: processi worker di PHP che avviano shell o scaricano strumenti (CISA, che ha aggiunto una regola di rilevamento Sigma il 23 ottobre), ed esecuzioni di processi o modifiche ai file impreviste sui server web (Amazon).
• Log: nei log di Apache, PHP-FPM, reverse proxy e servizi, avvisi o errori del core ripetuti prima dell'esecuzione degli script, errori fatali e di parsing, e Maximum execution time exceeded. L'advisory di PHP aggiunge che "l'assenza di un errore nei log non è una prova di sicurezza."

Quando presumere la compromissione. Se trova uno qualsiasi di questi indicatori, o se un server esposto ha eseguito un PHP colpito senza mitigazioni e i Suoi log non permettono di escludere lo sfruttamento, lo consideri compromesso. PHP descrive l'impatto come esecuzione di codice remoto con l'account del worker web, e quell'account di solito può leggere la configurazione e i secret dell'applicazione.

Ruoti ciò che il worker poteva leggere. Password dei database, chiavi API e token nelle variabili d'ambiente e nei file di configurazione, chiavi che firmano sessioni o cookie (e le sessioni firmate con esse), e qualsiasi credenziale cloud disponibile sull'host. Esegua la rotazione dopo aver ricostruito l'host, così i nuovi secret non si trovano mai su una macchina compromessa.

Ricostruisca invece di ripulire. Sostituisca un host o un container compromesso partendo da un'immagine affidabile, e non trasferisca i file che il worker poteva scrivere, come directory di upload, cache o codice generato. Non riutilizzi immagini, cache di build o artefatti prodotti su un host compromesso.

Che cosa dire ai Suoi clienti

Se distribuisce software che gira su PHP, i Suoi clienti glielo chiederanno. Risponda con versioni e azioni, anche prima di avere tutte le risposte. Una risposta che può adattare:

PHP2Shell (CVE-2026-109618, CVE-2026-109619) colpisce le versioni di PHP precedenti a 8.5.12, 8.4.27, 8.3.36 e 8.2.35 e tutti i branch PHP più vecchi. Le versioni [x–y] di [Prodotto] includono PHP [versione] e sono colpite; la versione [z], rilasciata il [data], include PHP [versione corretta]. Vi invitiamo ad aggiornare a [z]. Se non potete aggiornare subito, applicate le impostazioni PHP indicate nel nostro advisory [link] e limitate l'accesso di rete all'applicazione. Le versioni [a–b] di [Prodotto] non sono colpite. Aggiorneremo questo avviso entro il [data].

Se sta ancora verificando, lo dica, e dica quando risponderà. Per una prima dichiarazione e modelli per ogni esito, consulti come rispondere ai clienti dopo un attacco alla supply chain.

Il ruolo di CRACI

CRACI esegue i Suoi job GitHub Actions e registra ciò che ogni job scarica durante la build, comprese immagini container, pacchetti apt e apk e pacchetti Composer, e conserva ogni build passata con la sua SBOM. Quando viene pubblicata una CVE, la rivalutazione continua segnala le build passate che contenevano il pacchetto colpito, così vede quali release sono state esposte e per quanto tempo, non solo ciò che trova la scansione di oggi. I policy gate possono bloccare le build che contengono una specifica CVE.

Un limite per questo incidente: il PHP compilato in un'immagine ufficiale php: arriva dentro l'immagine, non come download di un pacchetto. CRACI registra il riferimento all'immagine scaricata da ogni build, quindi cerchi nelle Sue build i tag php: oltre ai pacchetti PHP.

Trovi ogni build che ha distribuito un PHP vulnerabile

Approfondimenti sui registri delle build: SBOM in fase di build, SBOM delle immagini Docker, che cosa sfugge alla scansione dei container, il catalogo CISA KEV e l'andamento delle pubblicazioni di CVE. Altri incidenti: tutte le vulnerabilità.

Per la sicurezza di PHP oltre questo incidente, consulta la nostra guida alla sicurezza di PHP.

Fonti e aggiornamenti

Fonti primarie:

• PHP: advisory di sicurezza del 21 ottobre 2026, advisory informativo del 23 ottobre 2026, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp, versioni supportate
• Record CVE: CVE-2026-109618, CVE-2026-109619
• CISA: alert del 21 ottobre 2026, catalogo KEV
• NCSC-NL: repository php2shell
• NVD: CVE-2026-109618, CVE-2026-109619
• FIRST: punteggi EPSS

Ricerche e analisi:

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

Aggiornamenti:

• 2026-11-11: aggiunti al riquadro i punteggi NVD, l'EPSS, le classi CWE, i crediti, le ultime versioni sicure e le date di fine vita, PHP 8.6.0 RC4 e sezioni su come funzionano i bug, sulla verifica della correzione e sul controllo di una possibile compromissione.
• 2026-11-11: prima pubblicazione.