~/ / Articoli sull'IA / L'IA ha aiutato a trovare PHP2Shell: le vulnerabilità critiche di PHP dell'ottobre 2026

L'IA ha aiutato a trovare PHP2Shell: le vulnerabilità critiche di PHP dell'ottobre 2026

Secondo le notizie di stampa, modelli di IA hanno aiutato i ricercatori a trovare due vulnerabilità critiche in PHP stesso, CVE-2026-109618 e CVE-2026-109619, che possono consentire l'esecuzione di codice da remoto (RCE) senza autenticazione. PHP ha rilasciato le versioni corrette il 21 ottobre 2026. Questo articolo riassume cosa dicono gli annunci ufficiali e le notizie di stampa sulle falle e sul modo in cui è stata coinvolta l'IA, e ti permette di verificare se il PHP che usi include la correzione.

Verificato con gli annunci ufficiali il 2026-10-24. Questa pagina non è un bollettino di sicurezza ufficiale e i dettagli possono cambiare: consulta le fonti in fondo alla pagina.

Che cosa fare per prima cosa

Aggiorna PHP a una versione corretta (8.5.12, 8.4.27, 8.3.36 o 8.2.35) oppure al pacchetto corretto della tua distribuzione Linux. PHP dichiara che non esistono mitigazioni complete e che aggiornare è l'unica scelta sicura.
Dopo l'aggiornamento, riavvia PHP-FPM, Apache e tutti i worker PHP di lunga durata, in modo che carichino il codice corretto. Un servizio avviato prima dell'aggiornamento sta ancora eseguendo il codice vecchio.
Se PHP proviene dal pacchetto di una distribuzione, controlla la versione completa del pacchetto, compresa la parte dopo il primo trattino. Le distribuzioni possono includere la correzione senza cambiare la prima parte del numero.
Se non puoi aggiornare subito, vedi le mitigazioni qui sotto. PHP dichiara che riducono l'esposizione a specifici percorsi di attacco ma non rendono sicura un'installazione.

Che cosa è successo

Il 21 ottobre 2026 PHP ha rilasciato 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Correggono due vulnerabilità critiche, entrambe valutate CVSS v4.0 9.2.

CVE-2026-109618, chiamata RCE via OOM corruption: la gestione dell'esaurimento della memoria può interrompere PHP mentre i dati interni della richiesta sono inizializzati solo in parte, e la pulizia della richiesta può poi trattare i dati non validi come validi.

CVE-2026-109619, chiamata RCE via stale global state: lo stato interno proprio di una richiesta può sopravvivere dopo che la memoria che lo conteneva è stata liberata, e una richiesta successiva gestita dallo stesso worker può usare quello stato obsoleto.

CVE-2026-109618 · CVSS 4.0 9.2
CVE-2026-109619 · CVSS 4.0 9.2

Il ruolo dell'IA

Secondo The Next Web, la società di sicurezza Calif ha trovato il primo bug ad agosto con l'aiuto di un modello di OpenAI, durante un audit del codice sorgente di PHP finanziato da OpenAI. Wiz ha dichiarato di aver trovato le falle in modo indipendente, settimane dopo, usando strumenti di IA tra cui i modelli Gemini di Google.

Il sito php2shell.com attribuisce la ricerca a Wiz Research, OpenAI Codex Security e Calif. Calif ha dichiarato di aver usato modelli disponibili al pubblico e che conoscere la storia di PHP contava più del modello.

Lo stesso articolo riferisce che Cloudflare ha attivato regole WAF per i propri clienti circa nove ore prima della divulgazione e che in seguito è circolato online un exploit proof-of-concept. Il sito php2shell.com afferma che una regola WAF o CDN non va considerata un sostituto dell'aggiornamento di PHP.

Cronologia

2026-10-20PHP annuncia un imminente rilascio di sicurezza critico, previsto per il 21 ottobre alle 14:00 UTC.
2026-10-21Vengono rilasciati PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 con un bollettino di sicurezza, e Ubuntu pubblica USN-8948-1.
2026-10-23PHP pubblica un bollettino informativo su session.upload_progress.enabled, relativo a un ulteriore vettore improbabile tracciato come CVE-2026-115560.

Chi è interessato

PHP dichiara che tutte le installazioni di PHP che servono richieste web sono a rischio, tra cui PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. Considera il rischio più alto per mod_php, dove una richiesta non autenticata può innescare l'attacco prima che venga eseguito qualsiasi codice dell'applicazione.

Gli advisory di GitHub indicano come interessate le versioni precedenti a 8.2.35, 8.3.36, 8.4.27 e 8.5.12. Il sito php2shell.com, indicato come gestito da Wiz, afferma che le versioni interessate risalgono fino a PHP 5.4.

PHP 8.1 e le versioni precedenti non ricevono più aggiornamenti dal progetto PHP. Alcune distribuzioni e fornitori LTS offrono correzioni riportate (backport), e PHP ha fornito backport minimi del sorgente per PHP 7.4, 8.0 e 8.1 per chi compila dal sorgente.

Versioni corrette

Una versione uguale o successiva alla versione corretta del proprio ramo include la correzione. Un pacchetto di distribuzione è corretto in base alla versione del pacchetto, quindi per Ubuntu e Debian usa la seconda tabella.

Le versioni di PHP

Ramo	Prima versione corretta
PHP 8.5	8.5.12
PHP 8.4	8.4.27
PHP 8.3	8.3.36
PHP 8.2	8.2.35

Pacchetti Ubuntu e Debian

Distribuzione	Pacchetto	Versione corretta del pacchetto	Avviso
Ubuntu 26.10	php8.5	8.5.9-0ubuntu2.1	USN-8948-1
Ubuntu 26.04 LTS	php8.5	8.5.4-0ubuntu1.5	USN-8948-1
Ubuntu 24.04 LTS	php8.3	8.3.6-0ubuntu0.24.04.13	USN-8948-1
Ubuntu 22.04 LTS	php8.1	8.1.2-1ubuntu2.28	USN-8948-1
Debian 12 (bookworm)	php8.2	8.2.35-1~deb12u1	DLA-4848-1
Debian 13 (trixie)	php8.4	8.4.27-1~deb13u1	DSA-6574-1

Le tabelle mostrano solo ciò che indicano gli avvisi ufficiali. Per le altre distribuzioni, consulta l'avviso di sicurezza del tuo fornitore.

Controlla il tuo PHP

Scegli da dove proviene il tuo PHP, incolla il testo della versione e lo strumento lo confronta con le versioni corrette indicate sopra. Giudica solo il testo che incolli. Non può vedere quale versione è in esecuzione, quindi verifica anche che il servizio sia stato riavviato dopo l'aggiornamento.

Comandi che mostrano la versione

php -v
dpkg -l 'php*' | grep ^ii
apt-cache policy php8.3-fpm | grep Installed

Da dove proviene il tuo PHP?

Testo della versione

Tutto viene eseguito nel tuo browser. Il testo che incolli non viene caricato.

Se non puoi aggiornare subito

PHP elenca queste misure. Dichiara che riducono l'esposizione a specifici percorsi di attacco ma non rendono sicura un'installazione, e che solo un aggiornamento è una soluzione completa.

CVE-2026-109618

Imposta memory_limit=-1, preferibilmente in un modo che le applicazioni non possano sovrascrivere, come php_admin_value nel pool FPM o nella configurazione di Apache. Un errore di allocazione sottostante può comunque raggiungere il percorso vulnerabile.
Imposta un post_max_size basso: 8M per le applicazioni che non richiedono il caricamento di file e 32M se i caricamenti servono. Mantieni upload_max_filesize al di sotto di post_max_size.
Applica limiti sul web server o sul proxy per la dimensione decodificata della richiesta, il numero di campi di input, il numero di parti multipart, il numero di header e la profondità di annidamento.
Usa un limite del container o di cgroup come confine di disponibilità. Non usare RLIMIT_AS o RLIMIT_DATA, perché possono causare l'errore di allocazione vulnerabile.

CVE-2026-109619

Imposta session.upload_progress.enabled=0 in php.ini, in un pool FPM o nella configurazione del server, e riavvia ogni worker. Non fare affidamento su ini_set() né su un file .user.ini di FPM.
Su PHP 8.5, imposta fatal_error_backtraces=0 e riavvia ogni worker.
Rimuovi le impostazioni non valide o obsolete applicate a ogni richiesta che emettono messaggi diagnostici prima dell'inizializzazione. Nascondere i messaggi diagnostici non aiuta.
Correggi gli errori fatali e i timeout di esecuzione che un attaccante può raggiungere.

Il bollettino informativo del 23 ottobre

PHP suggerisce di impostare session.upload_progress.enabled=0 fino al prossimo rilascio regolare di correzione dei bug, per proteggersi completamente da un ulteriore vettore improbabile di esecuzione di codice remoto. Se l'hai già applicato in base al bollettino del 21 ottobre, mantienilo.

PHP dichiara che il problema può verificarsi solo in una combinazione insolita: un'applicazione imposta session.serialize_handler su php_binary o php_serialize nella propria configurazione, lo porta a php in fase di esecuzione con ini_set() prima di session_start(), e il session upload progress è ancora abilitato. PHP pubblicherà un bollettino completo per CVE-2026-115560 con il prossimo rilascio.

Che cosa questa pagina non fa

Non è un bollettino ufficiale e non fornisce dettagli sull'exploit. Gli annunci e i bollettini ufficiali qui sotto sono la fonte autorevole.
Non può dire se un sistema sia stato attaccato. Il sito php2shell.com osserva che l'assenza di attività sospette non dimostra che un sistema non sia interessato.
L'esposizione dipende dalla versione, dalla configurazione e dalla singola vulnerabilità. Le mitigazioni possono influire sul funzionamento di un'applicazione.