php2shell: la falla PHP trovata dall'AI e come aggiornare

Martedì 20 ottobre qualcuno ha scritto su Hacker News che giovedì sarebbero uscite due falle critiche di PHP. Come prova ha portato un onesto "source: trust me, bro". Il giorno dopo la Finlandia, l'Olanda e la Francia avevano spento una parte dei loro siti governativi, e la falla aveva un nome: php2shell.

A trovarla, in buona parte, è stata un'intelligenza artificiale. Secondo OpenAI la prima segnalazione nasce da una ricerca fatta con GPT-5.6 Sol, il modello che diversi titoli chiamano "ChatGPT Sol".

Di falle gravi nel motore di PHP ne abbiamo viste parecchie. Questa si distingue perché funziona con la configurazione di default, su qualunque modo di far girare PHP, e perché i primi attacchi sono arrivati prima ancora della patch. Qui trovi cos'è php2shell, come capire se sei vulnerabile e come aggiornare PHP senza dimenticare i processi che restano accesi.

Cos'è php2shell (e perché riguarda chiunque usi PHP)

php2shell è il nome dato a due vulnerabilità del motore di PHP, la CVE-2026-109618 e la CVE-2026-109619. Le CVE (Common Vulnerabilities and Exposures) sono il catalogo pubblico delle falle di sicurezza: ognuna ha un codice univoco e un punteggio di gravità, il CVSS, da 0 a 10. Il team di PHP assegna a entrambe 9.2 (CVSS 4.0), il National Vulnerability Database americano 9.8 (CVSS 3.1): permettono a un attaccante senza credenziali di eseguire codice sul server.

In Italia il CSIRT dell'Agenzia per la Cybersicurezza Nazionale le ha classificate come critiche, nell'avviso AL07/261021/CSIRT-ITA.

Non è la prima volta che il problema sta nel motore e non in un'applicazione. Nel 2019 la CVE-2019-11043 permetteva di eseguire codice con certe configurazioni di nginx e PHP-FPM; nel 2024 la CVE-2024-4577 colpiva php-cgi su Windows con alcune impostazioni di lingua del sistema. In entrambi i casi serviva una configurazione particolare.

Con php2shell no. Calif, la società che ha trovato il primo pezzo, ha dimostrato l'esecuzione di codice senza login su WordPress, Drupal, Joomla, Magento, Nextcloud, phpMyAdmin, Symfony 8.1 e Laravel 13.11, con la configurazione di default. E secondo W3Techs PHP gira dietro circa il 70% dei siti di cui si conosce il linguaggio lato server.

Aggiornare il CMS o il framework, quindi, non serve: il bug sta sotto, nel runtime. Le descrizioni ufficiali sono nell'avviso di sicurezza di PHP e nei due advisory su GitHub, GHSA-w8hw-w9fx-j79w e GHSA-6wmf-4rv5-p3rp:

Il meccanismo, senza entrare nel C

Il cuore del problema è un errore che tutti abbiamo visto mille volte nei log: Allowed memory size of 134217728 bytes exhausted. Quando una richiesta supera il memory_limit, PHP la interrompe con un fatal error.

Il guaio è il punto esatto in cui la interrompe. Se il fatal arriva a metà di un'operazione interna, alcune strutture restano in uno stato incoerente. Calif ne descrive un esempio molto chiaro nelle hash table di PHP, che in versione semplificata (non è il codice reale) suona così:

// Inserimento di un elemento in una hash table, versione semplificata
ht->nNumOfElements++;              // 1. il contatore dice "c'è un elemento in più"
bucket->key = allocate_key(len);   // 2. qui scatta il fatal per memory_limit
// Il punto 2 non finisce mai, ma in fase di pulizia
// il contatore dice che l'elemento esiste: PHP lo tratta come valido.

Un attaccante sa come gonfiare la memoria di una richiesta, per esempio con upload multipart costruiti apposta, con nomi di campo annidati. Così provoca il fatal nel punto giusto. La richiesta successiva che finisce sullo stesso worker (il processo PHP che serve le richieste una dopo l'altra) trova memoria già liberata e la usa. È un use-after-free, cioè codice che lavora su memoria già restituita, e con abbastanza lavoro diventa esecuzione di codice.

Wiz ha mostrato anche una variante più subdola: un pezzo di memoria del processo che esce in un cookie PHPSESSID nella risposta, anche se l'applicazione non chiama mai session_start().

Chi ha trovato php2shell: GPT-5.6 Sol, Calif e vent'anni di indizi

Un'AI che trova un bug, nel 2026, non è più una notizia. Questo bug però ha una storia: in tanti l'hanno sfiorato, nessuno l'aveva mai trovato del tutto.

La riga che conta è quella del 2024. Il problema era stato visto durante l'audit esterno di Quarkslab. Non è stato corretto perché nessuno era riuscito a trasformarlo in un attacco reale, e senza un exploit un bug di memoria esaurita sembra un fastidio, non un'emergenza.

Quello che i modelli hanno cambiato è il costo di quella dimostrazione. Wiz scrive che un singolo ricercatore, con Gemini 4 Argon, GPT-5.6 Sol e la loro piattaforma Wiz Atlas, ha fatto in circa una settimana un lavoro che prima avrebbe richiesto mesi a un team.

Come ha lavorato Calif

Il resoconto di Calif è la parte che consiglio di leggere a chiunque usi l'AI per scrivere codice. Il modello non lo nominano mai (parlano di un "LLM companion", il legame con GPT-5.6 Sol lo dichiara OpenAI) e non descrivono un prompt magico. Descrivono un ricercatore che conosce la storia delle vulnerabilità di PHP e usa il modello come compagno di lavoro: per trovare modi di sforare il memory_limit, per far rileggere a un agente il codice dell'allocatore e dello shutdown delle richieste.

Un dettaglio mi ha colpito: dopo il primo bug hanno chiesto al modello di generalizzare lo schema in un file SKILL.md. Da quella skill è uscita la seconda falla, quella sull'upload progress delle sessioni.

La loro lezione principale la riassumono così:

"Know your target" resta valido anche nell'era della ricerca di vulnerabilità guidata dagli LLM. Nessun modello trova "tutti i bug" con un prompt semplice, almeno per ora.

È il rovescio di quello che raccontavo a proposito delle allucinazioni dell'AI e di chi si fida senza verificare. Qui il risultato è arrivato perché un esperto guidava il modello e verificava ogni passo, fino a un attacco che PHP ha potuto confermare. E un consiglio pratico: i modelli partono dai bug più recenti e famosi, le tecniche di attacco vecchie bisogna chiederle esplicitamente.

Trovata prima degli attaccanti? Non proprio

OpenAI presenta php2shell come il caso in cui, "per quanto ne sappiamo", l'AI di frontiera è arrivata prima dei criminali. I fatti raccontano una storia meno pulita.

Amazon ha registrato un primo tentativo di exploit sui suoi honeypot (server esca, messi online apposta per attirare gli attacchi) il 17 ottobre, quattro giorni prima della pubblicazione. Martedì 20 è arrivato il post su Hacker News, watchTowr ha confermato che i bug esistevano ed erano sotto embargo, e PHP ha anticipato il rilascio di un giorno.

Mercoledì mattina il CTO di Cloudflare, Dane Knecht, scriveva che vedevano "i primi attacchi" circa sei ore prima della patch, come racconta Decrypt. Cloudflare aveva attivato regole di protezione alle 03:02 UTC e ha visto gli attaccanti modificare i payload per aggirarle. In serata contava milioni di tentativi.

La frase più onesta di tutta la vicenda l'ha scritta Amazon:

"Un embargo protegge chi difende solo finché qualcun altro non trova lo stesso bug."

Calif precisa che la scoperta iniziale non ha usato harness speciali né modelli non disponibili al pubblico. Ecco perché la finestra si accorcia: se un modello che chiunque può pagare trova un bug così, il secondo che lo trova può essere chiunque.

Sei vulnerabile a php2shell? Come verificarlo

La risposta breve è sì, finché non aggiorni. Ogni versione di PHP dalla 5.4 in poi contiene almeno uno dei percorsi vulnerabili, e non ti salva il modo in cui lo fai girare: il team di PHP cita PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed, e indica mod_php come il caso più a rischio. Su PHP-FPM Calif ha dovuto lavorare di più per arrivare all'attacco, ma ci è arrivato.

Queste sono le prime versioni corrette (il dettaglio delle modifiche è nel ChangeLog di PHP 8):

Attenzione: php -v può ingannarti

Ci sono due trappole.

La CLI non è il PHP che serve il sito. php -v ti dice la versione da riga di comando. Quella che risponde alle richieste web la vedi con php-fpm8.4 -v (adatta il numero alla tua versione), e non è detto che coincidano.

Le distribuzioni correggono senza cambiare il numero di versione. Si chiama backport: Ubuntu e Debian prendono la correzione e la applicano alla versione che distribuiscono. Su Ubuntu 24.04 PHP resta "8.3.6", ma il pacchetto corretto è 8.3.6-0ubuntu0.24.04.13. Se guardi solo il numero di PHP, pensi di essere vulnerabile quando non lo sei, o peggio il contrario.

I dati vengono dal blog di Ubuntu e dal security tracker di Debian. Ubuntu 20.04 e precedenti ricevono la correzione solo con Ubuntu Pro (gratuito fino a 5 macchine).

# Versione della CLI e del PHP-FPM che serve davvero il sito
php -v
php-fpm8.4 -v

# Su Ubuntu e Debian: versione esatta dei pacchetti installati
dpkg -l | grep -E '^ii +php[0-9.]+-(fpm|cli|common) '

Se invece installi PHP dai pacchetti di Ondřej Surý (il repository usato da molti, tra cui Laravel Forge), la numerazione segue quella ufficiale: lì il numero da vedere è proprio 8.4.27, 8.3.36 e così via.

Il checker di OpenAI e i suoi limiti

OpenAI ha pubblicato php2shell-checker, uno script Node.js che controlla un sito o il PHP locale:

node phpcheck.js "https://tuosito.it"   # legge gli header X-Powered-By e Server
node phpcheck.js --local                # esegue php -v sulla macchina

Il risultato è OK, VULNERABLE o UNKNOWN. Due avvertenze che il README stesso mette in evidenza: UNKNOWN non vuol dire che sei al sicuro, e OK è solo un confronto di numeri, quindi non vede i backport. Lo trovo utile per fare l'inventario di tanti siti in una volta. Ma se il checker legge la tua versione di PHP dagli header, la leggono anche gli attaccanti: nel php.ini imposta expose_php = Off.

Se sei su un hosting condiviso

Qui non puoi aggiornare tu: deve farlo il provider. Cloudflare lo ricorda nel suo articolo sulle protezioni: aggiornare il codice del sito o i plugin non risolve, va aggiornato il runtime di PHP.

La versione la trovi nel pannello dell'hosting o, se usi WordPress, in Strumenti → Salute del sito → Info → Server. Per via dei backport, il numero da solo non basta: chiedi al provider per iscritto se la build installata include la correzione per CVE-2026-109618 e CVE-2026-109619.

Come aggiornare PHP contro php2shell

Non ci sono mitigazioni complete: il team di PHP lo scrive chiaramente, aggiornare è l'unica scelta sicura. Le versioni corrette sono uscite il 21 ottobre intorno alle 13:30 UTC.

Su Ubuntu e Debian con i pacchetti della distribuzione

Se usi il PHP della distribuzione, basta un aggiornamento normale seguito dal riavvio del servizio:

sudo apt update && sudo apt upgrade

# Poi riavvia quello che usa PHP
sudo systemctl restart php8.3-fpm   # oppure apache2, se usi mod_php

Gli aggiornamenti automatici di sicurezza di Ubuntu applicano la correzione entro circa 24 ore, ma non riavviano le applicazioni. Finché non riavvii, gira ancora il PHP di prima.

Riavvia tutto quello che esegue PHP

Questo è il passaggio che si dimentica. Riavviare PHP-FPM o Apache è il minimo, ma qualunque processo PHP che resta acceso a lungo continua a girare con il PHP che aveva in memoria quando è partito: worker delle code, demoni gestiti da Supervisor, application server come Swoole, RoadRunner o FrankenPHP. Finché non li riavvii, la falla resta aperta.

# Elenca i processi PHP attivi e da quando girano
ps -eo pid,lstart,cmd | grep -E '[p]hp'

# Riavvia i demoni gestiti da Supervisor
sudo supervisorctl status
sudo supervisorctl restart <nome-del-programma>:*

# Verifica che CLI e FPM girino davvero sulla versione corretta
php -v
php-fpm8.4 -v

Con gli application server conviene un riavvio completo, non un semplice reload dei worker. Il motivo: con Swoole, per esempio, i worker nascono dal processo principale, che ha ancora in memoria il PHP di prima.

Se usi Laravel, i comandi da ricordare sono questi:

php artisan queue:restart       # i worker finiscono il job in corso e ripartono
php artisan horizon:terminate   # Supervisor rilancia Horizon con il nuovo PHP
# Octane e Reverb: riavvio completo del daemon con supervisorctl, non octane:reload

Docker e FrankenPHP

Con Docker riavviare il container non basta: dentro c'è ancora il PHP di prima. Le immagini ufficiali hanno già i tag 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Se usi un tag generico come php:8.4-fpm, ricostruisci forzando il download dell'immagine base:

docker compose build --pull
docker compose up -d

FrankenPHP merita una nota a parte: PHP è compilato dentro il suo binario. Aggiornare il PHP di sistema non cambia niente, devi sostituire il binario o l'immagine con una build che includa PHP corretto. Vale anche se lo usi tramite Laravel Octane. La prima versione corretta è la 1.13.2, uscita il 21 ottobre: le sue immagini Docker usano PHP 8.2.35, 8.3.36, 8.4.27 e 8.5.12, i binari statici PHP 8.5.12.

Se usi un pannello: l'esempio di Laravel Forge

I pannelli di gestione dei server hanno spesso una regola tutta loro, e Forge è un buon esempio di trappola. I suoi aggiornamenti automatici di sicurezza non toccano PHP: Forge lo installa dai pacchetti di Ondřej Surý, mentre gli aggiornamenti automatici di Ubuntu prendono solo dal repository di Ubuntu.

Dal pannello: apri il server, tab PHP, menu della versione, Update PHP X.X. Ripeti per ogni versione installata, anche quelle che nessun sito usa. Se hai molti server puoi usare l'API di Forge o una Recipe (uno script che Forge lancia come root su più server).

Lo stesso vale per qualunque server con PHP preso dal repository di Ondřej Surý: prima controlla che il pacchetto corretto sia già arrivato, poi aggiorna.

# Quali versioni di PHP ci sono sul server
ls /etc/php

# La versione "Candidate" deve essere quella corretta (es. 8.4.27)
sudo apt-get update
apt-cache policy php8.4-fpm

# Aggiorna tutti i pacchetti di quella versione mantenendo php.ini e pool FPM
sudo apt-get install --only-upgrade -y \
  -o Dpkg::Options::="--force-confold" \
  $(dpkg -l 'php8.4*' | awk '/^ii/ {print $2}')

Se sei ancora su PHP 8.1 o più vecchio

Qui c'è il numero che mi ha fatto più impressione. Secondo Mallory, citata da Decrypt, il 20 ottobre circa 884.000 host esposti su internet dichiaravano PHP 8.1 o precedente: il 59% di quelli che mostrano la versione.

Per questi server PHP non rilascerà patch. Il team di sicurezza ha pubblicato dei backport minimi per 7.4, 8.0 e 8.1, utili a chi compila da sorgente, e alcune distribuzioni e fornitori LTS offrono le loro correzioni. Ma la strada vera è passare a un ramo supportato. E tieni a mente che PHP 8.2 arriva a fine vita il 31 dicembre 2026, tra poco più di due mesi.

Se non puoi aggiornare subito: le mitigazioni temporanee

Esistono mitigazioni parziali, da usare solo per qualche ora mentre organizzi l'aggiornamento. Riducono alcune strade di attacco, non le chiudono tutte.

; Mitigazioni TEMPORANEE: non sostituiscono l'aggiornamento.
; Impostale in php.ini o nel pool FPM (php_admin_value), non con ini_set() né .user.ini,
; poi riavvia tutti i worker.

memory_limit = -1                    ; niente fatal per memoria esaurita (vedi nota sotto)
post_max_size = 8M                   ; 32M se ti servono gli upload
upload_max_filesize = 6M             ; sempre sotto post_max_size
session.upload_progress.enabled = 0
fatal_error_backtraces = 0           ; solo PHP 8.5

Togliere il limite di memoria ha un prezzo ovvio: una richiesta può mangiarsi la RAM del server. Il team di PHP suggerisce di mettere un limite a livello di container o cgroup, che uccida solo il worker coinvolto.

Altre tre cose che puoi fare nel frattempo:

Blocca gli upload multipart dove non servono. È il suggerimento di Amazon: se una parte dell'applicazione non riceve file, chiudila agli upload. Prima prova che non rompa niente.

Tieni attivo il WAF, ma non contarci. Un WAF (Web Application Firewall, il filtro che blocca le richieste sospette prima che arrivino al server) aiuta. Le regole di Cloudflare sono attive in automatico anche sul piano gratuito; sui piani a pagamento controlla che il ruleset gestito sia in modalità blocco. Ma lo stesso Knecht le ha definite "solo un tampone", e abbiamo visto che gli attaccanti modificano i payload per aggirarle.

Se il servizio non è indispensabile, spegnilo. È quello che raccomanda il CSIRT Italia per i siti che non si possono aggiornare in tempi brevi, ed è quello che hanno fatto Finlandia, Olanda e Francia.

Come capire se php2shell ti ha già colpito

Il consiglio di Amazon è di partire dal 17 ottobre, non dalla data di pubblicazione. I segnali da cercare: richieste POST multipart seguite da errori di memoria esaurita, raffiche di errori 500, cookie PHPSESSID strani o enormi nelle risposte, worker PHP che muoiono e ripartono senza motivo. Il CSIRT aggiunge processi eseguiti in modo inatteso, file dell'applicazione modificati e connessioni di rete anomale.

# Fatal per memoria esaurita negli error log di nginx (anche nei file ruotati .gz)
sudo zgrep -h "Allowed memory size" /var/log/nginx/*error.log* | tail -n 50

# File PHP modificati dal 17 ottobre, esclusi vendor e storage (adatta il percorso)
# Confrontali con i tuoi deploy: quelli che non hai toccato tu sono il problema
find /var/www -name "*.php" -newermt "2026-10-17" \
  -not -path "*/vendor/*" -not -path "*/storage/*"

Wiz avverte che il problema si gioca sotto il livello applicativo, quindi i log di Laravel potrebbero non mostrare niente. Se hai un WAF o log dei body, cerca le richieste che contengono PHP_SESSION_UPLOAD_PROGRESS nei form di upload.

Se trovi segnali sospetti, considera esposto tutto quello che stava nella memoria dei worker: password del database, chiavi API, segreti nel .env. Ruotali. Se l'applicazione è Laravel, per l'APP_KEY dalla versione 11 puoi spostare la vecchia chiave in APP_PREVIOUS_KEYS, così i dati cifrati restano leggibili mentre passi alla nuova. In Italia gli incidenti si possono segnalare al CSIRT su csirt.gov.it.

Domande frequenti su php2shell

Serve un account per sfruttare php2shell?

No. L'attacco è non autenticato: basta poter mandare richieste HTTP costruite apposta a una qualunque pagina servita da PHP.

Basta aggiornare WordPress o Laravel?

No. Le falle stanno nel motore di PHP, sotto qualsiasi CMS o framework. Va aggiornato PHP e vanno riavviati i processi che lo eseguono.

Cloudflare o un WAF bastano a proteggermi?

No. Riducono il rischio mentre aggiorni, ma Cloudflare stessa chiede di aggiornare PHP anche con le protezioni attive.

Il mio server dice PHP 8.3.6: sono vulnerabile?

Dipende da chi ha compilato quel PHP. Se viene dai pacchetti di Ubuntu 24.04, la versione 8.3.6-0ubuntu0.24.04.13 è corretta grazie al backport. Se viene da un'altra fonte, 8.3.6 è vulnerabile e devi passare almeno alla 8.3.36.

php2shell è già sfruttata?

Sì. Amazon scrive che è "ampiamente sfruttata" e ha visto tentativi già quattro giorni prima della pubblicazione.

Basta disattivare session.upload_progress?

No. Chiude solo una delle strade d'attacco. È una delle mitigazioni temporanee, non una soluzione.

Uso PHP 7.4, 8.0 o 8.1: cosa faccio?

Non avrai patch ufficiali. Puoi appoggiarti a una distribuzione o a un fornitore LTS che fa il backport (per esempio Ubuntu Pro), ma la scelta giusta è passare a un ramo supportato.

Glasswing contro Patch the Planet: due idee di sicurezza con l'AI

A maggio ho scritto di Project Glasswing, la scelta di Anthropic di dare Claude Mythos solo a una quarantina di organizzazioni perché troppo bravo a trovare vulnerabilità. L'idea era: teniamo l'arma chiusa a chiave e facciamola usare solo a chi difende.

php2shell racconta l'approccio opposto. Il primo pezzo del bug l'ha trovato un modello pubblico, usato da una società di sicurezza dentro Patch the Planet, l'iniziativa di OpenAI che ha coordinato per due mesi PHP, Wiz, Calif, Cloudflare, Quarkslab e le agenzie americane. Il risultato è stato una patch pronta per tutti, ma anche un exploit in giro prima che la patch uscisse.

Non penso che uno dei due approcci abbia "vinto". Penso però che php2shell mostri il limite di Glasswing: se un modello disponibile a tutti trova una falla di questo livello in PHP, chiudere a chiave il modello più forte compra poco tempo. Il collo di bottiglia si è spostato: trovare i bug costa sempre meno, correggerli e far arrivare le correzioni sui server resta lento. E di bug ne arriveranno altri: Greg Brockman, presidente di OpenAI, ha detto che si aspettano di trovarne "molti altri nei prossimi mesi".

Cosa cambia per chi gestisce PHP in produzione

Gli indizi di php2shell c'erano nel 2004, nel 2020, nel 2024. Mancava il tempo per andare fino in fondo, e adesso quel tempo costa una settimana di lavoro a un ricercatore con un modello AI. Vale anche per chi attacca: Amazon ha visto i primi tentativi quattro giorni prima della pubblicazione e i proof of concept girare poche ore dopo.

Chi gestisce server sa benissimo quale versione di PHP ci gira sopra. Il punto debole che php2shell ha messo in luce è un altro: quanto ci vuole perché una patch rilasciata giri davvero ovunque. Il pacchetto che tarda ad arrivare nel repository, il pannello che non aggiorna PHP da solo, l'immagine Docker da ricostruire, i worker da riavviare, le applicazioni ferme su PHP 8.1 perché migrarle costa. Il 21 ottobre ognuno di questi passaggi valeva qualche ora di esposizione in più, e Amazon lo dice in modo esplicito: per le falle critiche esposte su internet, i tempi di patch si misurano in ore, non in giorni.

Se Brockman ha ragione e nei prossimi mesi ne arriveranno altre, credo che la conseguenza sarà trattare gli aggiornamenti di PHP come quelli di sicurezza del sistema operativo: automatici, con il riavvio dei processi compreso, e con il passaggio di versione pianificato prima della fine del supporto. PHP 8.2 esce dal supporto il 31 dicembre. Chi ci sarà ancora sopra alla prossima php2shell, una patch ufficiale non la avrà.