La scoperta di PHP2Shell e cosa fare sulle CVE-2026-109618 e CVE-2026-109619

Il 20 ottobre 2026 il progetto PHP ha fatto una cosa che fa di rado: ha annunciato una release di sicurezza prima di pubblicarla, dicendo che avrebbe corretto due vulnerabilità critiche valutate entrambe 9.2 su CVSS 4.0 e invitando tutti a prepararsi. Nello stesso annuncio c'era una riserva insolita, che con il senno di poi suona come una previsione: ci riserviamo di rilasciare prima, se i dettagli diventano pubblici o se compare evidenza di sfruttamento.

Accaddero entrambe le cose nel giro di poche ore. La sera del 20 i dettagli trapelarono, una società di sicurezza confermò pubblicamente che le vulnerabilità erano reali, e il giorno dopo, alle 14:00 UTC, uscirono le versioni corrette con un giorno di anticipo sull'embargo concordato. Gli avvisi erano stati pubblicati ventisei minuti prima, alle 13:34 UTC: CVE-2026-109618 e CVE-2026-109619, che i ricercatori hanno battezzato insieme PHP2Shell.

Questo è il primo pezzo di una serie di cinque. Qui c'è come ci si è arrivati e cosa fare adesso sulle macchine che amministri, con i tre controlli che in questo caso valgono più del numero di versione. Gli altri quattro scendono nel dettaglio del difetto e di come si vede arrivare il traffico che lo cerca.

TL;DR

• Sono corretti tutti i rami, 5.6 compreso. Release ufficiali 8.2.35, 8.3.36, 8.4.27, 8.5.12; su Debian e Ubuntu i pacchetti sury correggono anche 5.6, 7.0, 7.1, 7.2, 7.3, 7.4, 8.0 e 8.1.
• Il numero di versione mente: sui rami fuori supporto il backport lascia 7.4.33 o 8.1.34. Si verifica dal changelog del pacchetto, mai da php -v.
• Fuori da Debian e Ubuntu la copertura si ferma ai rami supportati: su famiglia Red Hat e su Alpine non esiste un equivalente di sury per i rami morti.
• Il pacchetto non basta: finché non riavvii, i worker in esecuzione servono richieste con il codice vecchio. Vale anche per i processi PHP long-running da riga di comando.
• Chiedilo al processo giusto: la CLI e il pool FPM possono girare versioni e configurazioni diverse. Conta la seconda.
• Se aggiungi un limite di memoria cgroup, metti anche OOMPolicy=continue: il default stop ferma l'intero servizio invece del singolo worker.

Chi ha trovato PHP2Shell, e come

La scoperta non appartiene a un gruppo solo, ed è la ragione per cui gli avvisi elencano quattro segnalatori diversi. La prima segnalazione al team di sicurezza di PHP arriva l'11 agosto 2026 da Calif, una piccola realtà di ricerca offensiva. Tredici giorni dopo, il 24 agosto, arriva una seconda segnalazione indipendente da Wiz Research, che nel frattempo aveva già dimostrato esecuzione di codice non autenticata contro installazioni standard di Drupal e di WordPress. Nello stesso gruppo di crediti compaiono il team di sicurezza di OpenAI e, secondo la ricostruzione pubblicata da Cloudflare, anche Quarkslab.

Il dettaglio che ha fatto discutere riguarda il metodo. Wiz ha dichiarato di aver trovato la prima delle due vulnerabilità usando modelli linguistici di frontiera come strumento di analisi del codice, e ha accompagnato la dichiarazione con una frase da maneggiare con le pinze: un singolo ricercatore avrebbe completato in una settimana quello che a una squadra di livello mondiale avrebbe richiesto mesi. È un'affermazione dell'autore, non una misura verificabile da fuori, e la pubblicità del fornitore e il risultato tecnico qui viaggiano sullo stesso foglio.

Quello che invece si può verificare è il resto, e conviene tenerlo separato dal titolo.

Due righe di questa cronologia meritano più attenzione del resto.

La prima è quella del 17 ottobre. Amazon ha documentato un tentativo intercettato dalla propria rete di sensori quattro giorni prima della divulgazione, da un'infrastruttura di anonimizzazione commerciale, e ha scritto di non sapere come l'autore fosse arrivato a quelle informazioni. La conclusione operativa che ne ha tratto è la cosa più utile dell'intero documento: non si deve dare per scontato che la data di divulgazione sia la prima data di sfruttamento. Chi apre un'indagine su questa vicenda dovrebbe partire dal 17 ottobre, non dal 21.

La seconda è quella del 23 ottobre, due giorni dopo la pubblicazione, quando è uscito un avviso informativo su un terzo problema collegato, CVE-2026-115560, che riguarda anche le versioni già corrette e che sarà risolto con la prossima release ordinaria. Le condizioni per incontrarlo sono insolite e dipendono da come l'applicazione cambia un parametro delle sessioni a runtime, ma la contromisura è la stessa che conviene comunque tenere, cioè disattivare il meccanismo di avanzamento degli upload se non lo usi.

Che cosa sono le due vulnerabilità

La seconda, CVE-2026-109619, ha lo stesso punteggio, le stesse versioni corrette e un meccanismo diverso: riguarda stato interno che sopravvive al termine di una richiesta e viene toccato da quella successiva servita dallo stesso processo. Il suo avviso è il gemello del primo, e i due si rimandano a vicenda nelle raccomandazioni: chi applica le indicazioni di uno e ignora l'altro resta esposto.

Il National Vulnerability Database le valuta diversamente fra loro sulla scala 3.1, 9.8 la prima e 8.1 la seconda, perché la seconda richiede che due richieste finiscano sullo stesso processo. Red Hat, che sulle proprie distribuzioni parte da una configurazione in cui l'interprete gira in processo separato, le classifica come importanti anziché critiche per lo stesso motivo. Per la decisione operativa la differenza non conta: le corregge lo stesso aggiornamento, e la riduzione di rischio della configurazione a processi separati vale per una delle due, non per entrambe.

Una cosa che aiuta a dimensionare il problema: nessuna delle due, al momento in cui scrivo, è nel catalogo delle vulnerabilità sfruttate attivamente della CISA. Chi usa quel catalogo come innesco dell'urgenza, e sono molte organizzazioni strutturate, in questo caso parte in ritardo, perché i tentativi documentati da più fonti indipendenti sono cominciati prima della pubblicazione degli avvisi. Il motivo per cui quel catalogo arriva spesso tardi, con i numeri di dodici anni di osservazioni, è il tema del terzo pezzo della serie.

Perché il numero di versione non dice se sei aggiornato?

Perché sui rami fuori supporto la correzione arriva come backport sul pacchetto della distribuzione, e il backport non cambia la versione upstream. Un server con PHP 7.4.33 può essere corretto o vulnerabile, e php -v restituisce la stessa stringa nei due casi.

Il progetto PHP rilascia una versione nuova solo per i rami in supporto, che oggi sono 8.2, 8.3, 8.4 e 8.5. Per tutto il resto il canale è un altro: chi mantiene i pacchetti prende la correzione, la adatta al codice del ramo vecchio e pubblica una nuova revisione del pacchetto, lasciando intatto il numero di versione di PHP. L'informazione su cui tutti si basano diventa muta proprio dove serve di più.

Data la gravità, in questo caso i canali disponibili sono parecchi.

Il progetto PHP ha fatto una cosa che di solito non fa, cioè ha pubblicato backport minimi da sorgente per 7.4, 8.0 e 8.1 su rami dedicati del proprio repository, per chi compila in proprio o non ha un fornitore di supporto esteso.

La copertura più ampia, però, arriva dal repository di Ondřej Surý, che impacchetta PHP per Debian e Ubuntu: ha corretto tutti e otto i rami fuori supporto che mantiene, da 5.6 a 8.1, con revisioni pubblicate nelle stesse ore della release ufficiale e disponibili per ogni distribuzione servita dal repository. Le voci di changelog portano il numero di entrambe le CVE e la patch si chiama come il commit originale. Nel frattempo Ubuntu ha coperto i propri rami fino al supporto esteso, arrivando a php5 sulle versioni più vecchie, Debian ha emesso gli avvisi per le distribuzioni stabili, Alpine ha aggiornato i propri pacchetti e le immagini Docker ufficiali hanno ricevuto i nuovi tag entro quarantotto ore.

Vale la pena fermarsi un attimo su cosa significhi. Un ramo come il 7.0 è fuori supporto dal 2019 e il 5.6 dal 2018: per queste due vulnerabilità esiste comunque un pacchetto corretto, e la finestra fra la release ufficiale e la sua disponibilità si è misurata in ore. Non è un invito a restare lì, perché su un ramo morto la prossima falla potrebbe non avere lo stesso trattamento, ma toglie l'alibi a chi dice di non poter fare niente.

Questa copertura, però, appartiene a quel repository e non a Linux in generale: impacchetta per Debian e Ubuntu, e per nient'altro. Spostandosi di famiglia il quadro cambia parecchio, e conviene sapere dove ci si trova prima di promettere a un cliente che "tanto una patch c'è".

La riga che fa più male è la quarta. Sulla famiglia Red Hat il riferimento di fatto per PHP è il repository di Remi, che ha pubblicato i pacchetti delle quattro versioni corrette entro il giorno successivo alla release, per Fedora e per Enterprise Linux. I rami fuori supporto, però, lì non li segue nessuno: gli archivi dedicati a 7.4, 8.0 e 8.1 contengono build ferme al 2023. Chi ha un'applicazione su una di quelle versioni e gira su Alma, Rocky o RHEL ha quattro strade, e nessuna è indolore: cambiare ramo di PHP, compilare da sorgente partendo dai rami di backport pubblicati da php.net, comprare supporto esteso da un fornitore commerciale, oppure chiedere a me, perché il passaggio di un applicativo PHP da un ramo morto a uno supportato è uno dei lavori che faccio più spesso e la parte difficile quasi mai è l'interprete.

Se stai leggendo questa sezione pensando "io sono su 7.4, tanto una patch non c'è", la risposta è che quasi certamente c'è e probabilmente l'hai già installata senza accorgertene, perché il tuo gestore di pacchetti l'ha portata dentro in un aggiornamento ordinario.

Passare ai pacchetti sury su Debian e Ubuntu

Se amministri macchine Debian o Ubuntu e stai ancora usando i pacchetti della distribuzione, questa vicenda è un buon momento per valutare il passaggio. Il repository serve bullseye, bookworm, trixie, jammy, noble e resolute, e su ognuna porta tutti i rami di PHP in parallelo: puoi avere 7.4 e 8.4 installati insieme, con pool separati, e muovere un'applicazione alla volta.

La procedura ufficiale è questa, ed è la stessa su Debian e su Ubuntu.

1. Installa il portachiavi del repository

   $ sudo apt-get update
   $ sudo apt-get -y install lsb-release ca-certificates curl
   $ sudo curl -sSLo /tmp/debsuryorg-archive-keyring.deb \
       https://packages.sury.org/debsuryorg-archive-keyring.deb
   $ sudo dpkg -i /tmp/debsuryorg-archive-keyring.deb

   Verifica: il file /usr/share/keyrings/debsuryorg-archive-keyring.gpg deve esistere.

2. Aggiungi la sorgente e aggiorna gli indici

   $ echo "deb [signed-by=/usr/share/keyrings/debsuryorg-archive-keyring.gpg] \
       https://packages.sury.org/php/ $(lsb_release -sc) main" \
       | sudo tee /etc/apt/sources.list.d/php.list
   $ sudo apt-get update

   Verifica: apt-cache policy php8.4-fpm deve mostrare packages.sury.org fra le origini.

3. Aggiorna i pacchetti PHP già installati

   $ sudo apt-get install --only-upgrade -y 'php*'
   $ sudo systemctl restart php8.4-fpm

   Verifica: zgrep -c CVE-2026-109618 /usr/share/doc/php8.4-cli/changelog.Debian.gz deve restituire almeno 1.

Tre cose da sapere prima di farlo in produzione. La prima è che i pacchetti sury sostituiscono quelli della distribuzione, a partire da php-common: è una sostituzione pulita e dichiarata, ma da quel momento gli aggiornamenti di PHP arrivano da lì e non più dal fornitore del sistema operativo. La seconda è che chi usa ancora il vecchio archivio su Launchpad lo trova in via di dismissione, e nelle ore della divulgazione quel canale ha anche risposto con errori per il carico: il passaggio al repository principale è consigliato dal manutentore stesso. La terza riguarda la costruzione dei pacchetti per architetture ARM, che avviene in emulazione e richiede molte ore: sui rami ARM la disponibilità ha accumulato un giorno o due di ritardo rispetto a quella per architetture Intel.

Interrogare il changelog, non la versione

Su Debian e derivate la correzione è registrata nel changelog del pacchetto, con il numero della CVE scritto per esteso.

1. Verifica il changelog dei pacchetti installati

   $ zgrep -l 'CVE-2026-109618' /usr/share/doc/php*/changelog.Debian.gz
   /usr/share/doc/php7.4-cli/changelog.Debian.gz
   /usr/share/doc/php8.1-cli/changelog.Debian.gz

   Verifica: ogni ramo che amministri deve comparire nell'elenco. Un ramo assente non ha ricevuto la correzione.

2. Controlla la revisione esatta del pacchetto che serve il web

   $ apt-cache policy php8.1-fpm
   php8.1-fpm:
     Installed: 8.1.34-9+0~20261021.82+ubuntu24.04~1.gbp4e430a

   Verifica: la parte dopo il trattino è la revisione. Per i rami fuori supporto le prime revisioni corrette sono 5.6.40-104, 7.0.33-92, 7.1.33-80, 7.2.34-66, 7.3.33-35, 7.4.33-31, 8.0.30-25 e 8.1.34-9.

Su famiglia Red Hat vale rpm -q --changelog php-cli | head -40. Su Alpine la verifica si fa sulla release del pacchetto, dove le versioni corrette sono 8.2.35-r0, 8.3.36-r0, 8.4.27-r0 e 8.5.12-r0.

Se cerchi qualcuno che faccia questo tipo di verifica sulla tua infrastruttura invece di fidarsi di quello che dice il pannello di controllo, nel mio profilo professionale trovi come lavoro su hardening, aggiornamenti e modernizzazione di stack PHP in produzione, compresi quelli fermi da anni su rami fuori supporto.

Il pacchetto aggiornato non sostituisce i processi vivi

Questo passo viene dimenticato con una regolarità che non smette di sorprendermi, e produce lo stato peggiore possibile: binario nuovo sul disco, codice vecchio in memoria, e un controllo di versione che dice che è tutto a posto.

Quando il gestore di pacchetti sostituisce il binario, i processi già avviati continuano a eseguire il codice che hanno caricato all'avvio. Il pool continua a servire richieste con l'interprete vulnerabile finché non riavvii il servizio, e su Apache con modulo integrato vale lo stesso per i processi del web server.

C'è una categoria di processi che quasi nessuno considera e che ho trovato indietro su più di una macchina mentre aggiornavo il parco che amministro: i processi PHP long-running da riga di comando. Un consumatore di code avviato da un gestore di servizi, un demone applicativo, un processo di sincronizzazione che gira da settimane. Hanno caricato il binario vecchio e lo tengono finché non li riavvii, esattamente come i worker del web. Non ricevono richieste HTTP dirette, ma elaborano input che spesso arriva da fuori.

La verifica che il riavvio sia avvenuto si fa confrontando l'orario di avvio del servizio con quello di installazione del pacchetto, non leggendo il log del gestore di pacchetti.

$ systemctl show php8.4-fpm -p ActiveEnterTimestamp
ActiveEnterTimestamp=Thu 2026-10-22 09:14:03 CEST
$ zgrep -h 'php8.4-fpm' /var/log/dpkg.log* | grep ' installed ' | tail -1
2026-10-21 16:48:12 status installed php8.4-fpm:amd64 8.4.27-1+...

Nell'esempio l'ordine è giusto: pacchetto prima, riavvio dopo. Invertite, quelle due righe descrivono un server che risulta aggiornato a chiunque lo controlli da fuori e che non lo è.

Chiedere la versione al processo che serve le richieste

La terza trappola è che php -v risponde per l'interprete a riga di comando, che su quasi tutte le macchine che amministro è un binario diverso da quello che serve il web, spesso di un ramo diverso e quasi sempre con una configurazione diversa. Nemmeno interrogare il binario del pool con l'opzione di diagnostica risolve, perché quella legge la configurazione dal disco e non quella caricata dai worker vivi.

Il modo pulito è parlare al pool con un client FastCGI, senza passare dal web server e senza esporre nulla. Serve libfcgi-bin, che porta il comando cgi-fcgi.

1. Prepara uno script di diagnostica fuori dalla document root

   $ cat > /tmp/phpcheck.php <<'PHP'
   <?php
   echo PHP_VERSION, ' ', PHP_SAPI, "\n";
   foreach (['session.upload_progress.enabled', 'memory_limit', 'post_max_size'] as $k) {
       echo $k, ' = ', var_export(ini_get($k), true), "\n";
   }
   PHP

2. Interroga il socket del pool

   $ SCRIPT_FILENAME=/tmp/phpcheck.php SCRIPT_NAME=/phpcheck.php REQUEST_METHOD=GET \
       cgi-fcgi -bind -connect /run/php/php8.5-fpm.sock
   X-Powered-By: PHP/8.5.12
   Content-type: text/plain;charset=UTF-8
   
   8.5.12 fpm-fcgi
   session.upload_progress.enabled = '1'
   memory_limit = '128M'
   post_max_size = '8M'

   Verifica: la versione riportata qui è quella che serve davvero le richieste.

3. Cancella lo script di diagnostica

   $ rm /tmp/phpcheck.php

I valori che restituisce il pool sono anche quelli su cui ragionare per le contromisure, ed è il motivo per cui conviene guardarli invece di dedurli dai file. Nel parco che amministro, facendo questo giro, ho trovato pool con un limite di memoria alzato fino a due gigabyte da qualcuno che aveva fretta anni fa, direttive del pool scritte in una sezione che l'interprete ignora e che producono un errore a ogni avvio di worker da oltre un anno, file di configurazione per directory con un errore di sintassi mai notato, e pannelli di controllo che rigenerano la configurazione del pool sovrascrivendo quello che ci avevi messo. Nessuna di queste è una vulnerabilità, e ognuna rende falsa la risposta che daresti leggendo il file.

Le contromisure parziali, e la trappola che le rende dannose

Gli avvisi indicano alcune misure per chi non può aggiornare subito, e le qualificano tutte come incomplete. Vale la pena riportarle con la stessa qualificazione.

La prima riguarda il limite di memoria per richiesta e va in direzione contraria a come si configura di solito un server: rimuoverlo, in modo che l'applicazione non possa reimpostarlo, e contenere il consumo con un limite esterno di sistema. La seconda è tenere basso il limite sulla dimensione del corpo delle richieste e far rispettare lo stesso limite a monte, sul web server o sul proxy. La terza è disattivare il meccanismo di avanzamento degli upload nelle sessioni, che è attivo per impostazione predefinita, che quasi nessuna applicazione usa e che conviene lasciare spento anche dopo aver aggiornato. Sul ramo 8.5 se ne aggiunge una quarta, la disattivazione delle tracce di chiamata sugli errori fatali.

Qui c'è la trappola, e l'ho trovata sulla mia macchina mentre preparavo questi controlli.

La correzione è esplicitare OOMPolicy=continue nell'unità, così la terminazione di un worker resta un evento locale. Il valore attuale lo leggi con systemctl show php8.4-fpm -p OOMPolicy, e la cosa interessante è che eredita da un'impostazione globale: molte macchine hanno stop senza che nessuno l'abbia mai scelto. Resta valida l'avvertenza degli avvisi sui vecchi limiti di risorse del processo, sconsigliati esplicitamente perché producono proprio la condizione da evitare.

Dopo l'aggiornamento il comportamento in caso di memoria esaurita cambia, e conviene sapere cosa aspettarsi nei log prima di incontrarlo in produzione.

Hard memory limit of 268435456 bytes exhausted (tried to allocate 20480 bytes) in Unknown on line 0

Cosa non prova che sei a posto

Chiudo con tre conclusioni sbagliate che ho sentito formulare in questi giorni, tutte ragionevoli e tutte non sostenibili.

La prima è l'assenza di errori nei log. Un difetto di questa classe può lasciare tracce nei log del processo, ma la loro assenza non dimostra nulla: i log storici sono quasi sempre raccolti con le segnalazioni meno gravi disattivate, e una terminazione brusca può avvenire prima che il messaggio venga scritto. L'assenza di tracce rassicura solo se sai con certezza che quelle tracce sarebbero state registrate.

La seconda è la protezione di rete. Le regole pubblicate dai fornitori perimetrali nelle ore della divulgazione sono state utili, e uno di loro ha documentato onestamente un limite della propria copertura legato al nome di un parametro configurabile lato applicazione: chi ha cambiato quel nome non è coperto. Nessuno di quei fornitori presenta le proprie regole come un sostituto dell'aggiornamento.

La terza è la configurazione in uso. Far girare l'interprete in processo separato invece che come modulo integrato riduce la superficie dimostrata per una delle due vulnerabilità, non per l'altra, e ridurre non vuol dire eliminare.

Il resto della serie smonta la vicenda pezzo per pezzo, nell'ordine in cui è uscita: come funziona il difetto e perché nessuna contromisura di configurazione è dichiarata sufficiente, in quanto tempo le sonde automatiche arrivano a cercarlo, il metodo con cui collego una CVE al traffico che la cerca e infine cosa è arrivato davvero sul mio sensore nelle prime quarantotto ore.

Se la risposta alla domanda da cui parte questo articolo, cioè su quale codice gira il processo che serve le tue richieste, è stata "devo controllare", quella è l'informazione utile della settimana, più della vulnerabilità in sé. Scrivimi se vuoi che quella risposta esista scritta da qualche parte, e non soltanto per PHP: l'interprete è un pezzo di uno stack che comprende il web server, il database, il sistema operativo e l'applicazione, e mettere in sicurezza un pezzo solo serve a poco. Il lavoro che faccio copre tutto il perimetro esposto, dalla mitigazione urgente di una falla come questa fino alla manutenzione ordinaria che evita la corsa successiva.