PHP2Shell: CVE-2026-109618 e CVE-2026-109619 — RCE critica in PHP, patch oggi

Il 20 ottobre il team di sicurezza di PHP ha fatto una cosa inusuale: ha pre-annunciato una release d'emergenza senza dire cosa correggesse. Due vulnerabilità, entrambe valutate CVSS v4.0 9.2 (critiche), correzione prevista per mercoledì 21 ottobre 2026 alle 14:00 UTC. Nel giro di poche ore l'embargo è saltato — un post su Hacker News, gli screenshot di uno strumento offensivo chiamato "PHP2Shell" e la conferma di watchTowr che i bug sono reali e sfruttabili da remoto. La release è stata anticipata di un giorno pieno. Se usate PHP su qualsiasi percorso esposto in rete, la finestra tra "la patch esiste" e "la patch è applicata ovunque" è dove questa storia si decide, e quella finestra si misura in minuti.

Notizia in evoluzione — pubblicata alle 12:29 (10:29 UTC) del 21 ottobre 2026. Aggiornata man mano che vendor e CISA pubblicano.

In breve

CVE	CVE-2026-109618 · CVE-2026-109619 (identificativi dall'advisory trapelato; l'avviso ufficiale di PHP non li cita; nessun record NVD al momento)
Prodotto / versioni colpite	PHP (core dell'interprete) · secondo Sansec e il banner del tool trapelato colpisce ogni release da PHP 5.4.0 in poi; elenco ufficiale delle versioni atteso con la release
Corretta in	Non ancora rilasciata · release di sicurezza prevista il 2026-10-21 alle 14:00 UTC; PHP 8.1 e precedenti sono fuori supporto e non avranno una correzione ufficiale
CVSS	9.2 Critica (CVSS v4.0) · assegnata dal team di sicurezza PHP; CERT-EU legge il vettore come non autenticato
Sfruttata attivamente	Non confermata · watchTowr e Huntress non la osservano; Sansec cita traffico d'attacco visto da Cloudflare dalle 07:43 UTC del 2026-10-21
CISA KEV	Non presente (al 2026-10-21)
PoC pubblico	Nessuno pubblico al 2026-10-21; uno strumento privato "PHP2Shell" (attribuito a Calif.IO) è trapelato come screenshot; watchTowr dichiara di aver riprodotto CVE-2026-109618 ma non diffonde dettagli
Advisory ufficiale	https://www.php.net/archive/2026.php

Cosa è successo: PHP2Shell trapelata prima della correzione

PHP distribuisce le correzioni di sicurezza su un calendario coordinato. Questa volta il calendario si è rotto. Il pre-annuncio ufficiale di PHP del 20 ottobre dava solo l'essenziale: una release imminente per "due vulnerabilità critiche, entrambe CVSS v4.0 9.2", con dettagli, versioni colpite e versioni corrette rinviati alla release stessa. C'era però un segnale — il team si riservava di anticipare "qualora i dettagli di una delle due vulnerabilità diventassero pubblici, o emergessero prove di sfruttamento attivo".

Entrambe le condizioni hanno iniziato ad avverarsi lo stesso giorno. Secondo l'analisi di Sansec, un post su Hacker News del 20 ottobre segnalava la disclosure in arrivo, è stato rimosso, e gli screenshot si sono diffusi comunque — incluso quello di un tool offensivo chiamato PHP2Shell, attribuito a Calif.IO, il cui banner dichiara di funzionare su ogni release PHP dalla 5.4.0 in poi. SecurityWeek ha riferito che Benjamin Harris di watchTowr ha confermato di aver riprodotto CVE-2026-109618 e che si tratta di vera esecuzione di codice da remoto. Gli identificativi CVE provengono dal materiale trapelato; l'avviso di PHP non li elenca e nessuno dei due è ancora in NVD. È la peggiore forma possibile di disclosure: una RCE critica, non autenticata e confermata in uno dei software server più diffusi al mondo, nessuna correzione ancora per la maggior parte delle persone, e un exploit funzionante già in mani private.

Chi è esposto e come verificare

PHP non è un prodotto che si aggiorna una volta sola. È un interprete incorporato in CMS, stack e-commerce, pannelli di controllo e appliance di fornitori terzi. Sansec afferma che i difetti colpiscono "tutti i web server con PHP 5.4 o successivi", il che include Magento, Shopware e WooCommerce. Huntress lo inquadra allo stesso modo — RCE "nel core di PHP" — ed entrambi sottolineano che l'elenco delle versioni colpite resta non confermato fino alla release.

Verificate cosa usate davvero, non cosa pensate di usare:

• php -v su ogni host, e la versione usata dal SAPI web — CLI e FPM possono differire. Per PHP-FPM, controllate ogni pool.
• Il PHP incluso nel vostro CMS o piattaforma e-commerce, spesso più vecchio del PHP di sistema.
• I pannelli di controllo (cPanel, Plesk), che includono build PHP proprie.
• Container e immagini base: fate docker image inspect sul layer PHP; lì l'unica vera correzione è ricostruire l'immagine.
• PHP a fine vita. PHP supporta solo la 8.2 e successive, quindi la 8.1 e le precedenti non avranno patch ufficiali — quegli host richiedono un aggiornamento supportato, un backport del fornitore, o la rimozione da internet.

Remediation

È un bug a livello di interprete. Non potete correggerlo nel codice applicativo — il percorso vulnerabile gira dentro PHP stesso, prima della vostra applicazione o di qualsiasi WAF a livello PHP. Questo vincola cosa può significare "mitigazione".

1. Sono colpito? Inventariate ogni installazione PHP secondo l'elenco sopra. Trattate come in perimetro qualsiasi PHP raggiungibile da internet finché l'elenco ufficiale delle versioni colpite non dice altro.

2. Patch — nell'istante in cui esce. Le versioni corrette vengono pubblicate con la release delle 14:00 UTC del 21 ottobre. Aggiornate prima i sistemi esposti su internet. Controllate l'annuncio ufficiale per la build corretta esatta per ciascun branch e applicatela; non fidatevi di un riassunto di terze parti per il numero di versione. Attenzione: alcune distribuzioni e repository sono in ritardo — Sansec segnala che il repository di Remi non avrà aggiornamenti il giorno del rilascio — quindi verificate che la vostra fonte dei pacchetti contenga davvero la build corretta.

3. Non potete ancora applicare la patch? Controlli compensativi (nessuna garanzia). Il ripiego di Sansec, nell'attesa, è restringere la gestione di sessioni e upload di PHP nel php.ini:

session.upload_progress.enabled = 0
session.use_strict_mode = 1

Per PHP-FPM, impostateli come direttive di pool (ad es. in www.conf) così da non poter essere sovrascritti:

php_admin_flag[session.upload_progress.enabled] = off
php_admin_flag[session.use_strict_mode] = on

Ricaricate i worker (systemctl reload php8.3-fpm) e verificate i valori dentro una richiesta reale. Due avvertenze che Sansec esplicita: la strict mode delle sessioni non fa nulla se le sessioni risiedono in Redis o in un database, e uno sviluppatore del core PHP ha definito la patch l'unica vera mitigazione — non affidatevi al solo toggle di upload-progress. Per il PHP a fine vita che non potete correggere, il controllo onesto è toglierlo da internet o metterlo dietro una VPN o un WAF di rete.

"Non potete correggerlo dall'interno del codice del vostro store." — Sansec, sul perché la soluzione vada all'infrastruttura e non all'applicazione.

4. Cercate tracce di compromissione. Vedi la sezione di rilevamento qui sotto.

5. Bonifica e verifica. Se trovate segni di sfruttamento: isolate l'host, preservate i log del web server e di PHP prima che ruotino, e cercate web shell, file inattesi nella web root, nuovi cron o attività pianificate e nuovi account (come indica Huntress). Applicate la patch o ricostruite, poi ruotate ogni credenziale leggibile dal processo PHP — password dei database, chiavi API, segreti di sessione — perché una RCE riuscita gira con l'utente web e può leggerle tutte. Ripetete il test esatto del percorso d'ingresso dopo; una stringa di versione più alta non prova che il buco sia chiuso.

Rilevamento e caccia

Non sono ancora stati pubblicati IOC, righe di log o percorsi, e non li inventeremo. Ciò che i difensori possono osservare ora è comportamentale, tratto dalla risposta rapida di Huntress: una RCE contro un interprete web emerge quasi sempre come l'interprete che genera un processo figlio che non dovrebbe mai generare.

• Processi PHP (php-fpm, php-cgi, httpd, apache2) che avviano sh, bash, cmd.exe o powershell.exe — classico comportamento web-shell / esecuzione comandi (MITRE ATT&CK T1190 accesso iniziale, T1505.003 web shell, T1059 esecuzione comandi).
• Gli stessi processi che avviano interpreti (python, perl) o strumenti di download/trasferimento (curl, wget, nc, certutil.exe).
• Righe di comando con /dev/tcp/, fsockopen o mkfifo — primitive da reverse shell.
• Ricognizione da un host web: whoami, id, uname -a, ipconfig.

Sui server Linux senza EDR, Huntress segnala il process-watcher di Florian Roth in modalità osservazione. Il punto debole di tutto ciò: questi segnali scattano dopo che il codice è già in esecuzione. Su un difetto dove lo sfruttamento di massa è atteso entro minuti dalla patch, la telemetria di processo a posteriori è una gara in cui siete strutturalmente in ritardo.

Cosa non si sa ancora

• La causa radice delle due CVE. Il ripiego consigliato in php.ini punta verso la gestione upload-progress / multipart delle sessioni di PHP, e un report descrive CVE-2026-109618 come un use-after-free — ma PHP non ha confermato il componente, e lo trattiamo come non verificato.
• Le versioni colpite e corrette esatte, che escono con la release.
• Lo sfruttamento confermato in rete. watchTowr e Huntress non ne osservano al momento in cui scriviamo; Sansec cita traffico d'attacco iniziale visto da Cloudflare alle 07:43 UTC del 21 ottobre, che potrebbe essere scansione più che sfruttamento funzionante. Non c'è ancora un PoC pubblico.
• Se CISA aggiungerà la coppia al catalogo KEV una volta chiariti correzione e sfruttamento.

Aggiorneremo questo articolo man mano che PHP, CISA e i ricercatori pubblicheranno altro.

Sopravvivere alla finestra dei 15 minuti

L'avvertimento di Sansec — sfruttamento di massa "probabilmente entro 15 minuti" dalla release — è il vero enunciato del problema. Nessuno applica una patch PHP su una flotta di web server, runtime incorporati e host a fine vita in quindici minuti. La domanda non è solo "ho applicato la patch" ma "vedrò l'istante in cui qualcuno piazza l'exploit su una macchina che non ho ancora raggiunto". Come ammette la sezione di rilevamento, la telemetria lato host lo coglie solo dopo che la shell è già aperta.

È il caso per cui è nata l'AI Traffic Analysis di Zero Hunt: un modello di deep learning con quattro teste di inferenza (traffico sospetto, classificazione malware, identificazione del tipo di attacco, fingerprinting applicativo), addestrato su miliardi di sequenze PCAP, a un baseline di 2,7+ Gbit/s, localmente sulla GPU dell'apparato. Il tentativo di sfruttamento, la prima callback della web shell, lo staging di strumenti via curl/wget, il beacon della reverse shell — tutto attraversa la rete mentre accade, non nel digest del SIEM del mattino dopo. Quando il divario tra patch ed exploit è di minuti, vedere il tentativo sulla rete è la differenza tra un incidente che contenete e uno di cui leggete dopo.

La gara alla patch è l'altra metà, ed è un problema di prioritizzazione. L'AI Remediation Advisor di Zero Hunt ordina per sfruttabilità reale — prima KEV, poi ciò che una campagna ha dimostrato raggiungibile, poi CVSS ed EPSS — fornisce la correzione esatta con note di rollout/rollback e un controllo compensativo per gli host che oggi non potete aggiornare, poi riverifica con la stessa prova che ha dimostrato l'esposizione. Per il PHP a fine vita che non avrà mai una build ufficiale, quella riverifica è ciò che vi dice se il controllo di rete davanti ad esso tiene davvero.

Zero Hunt opera come un red team AI autonomo, on-premise sui propri modelli privati, con un essere umano nel ciclo per ogni azione che conta. Per vedere dove si nasconde PHP nel vostro parco prima delle 14:00 UTC, partite dalla nostra guida al penetration testing automatizzato, e il nostro team può accompagnarvi. Per il quadro più ampio, vedi la nostra analisi precedente su wp2shell nel core di WordPress.