In breve: dopo PHP2Shell sono probabili altre segnalazioni su PHP, perché già due giorni dopo la patch è arrivata una terza segnalazione, un advisory completo è ancora in sospeso e le distribuzioni consegnano i propri pacchetti in modo scaglionato. Chi imposta ora una procedura fissa di osservazione, valutazione, aggiornamento e riavvio reagisce alla prossima nuova vulnerabilità PHP in ore anziché in giorni.
La patch non è stata la fine della storia
Il 21 ottobre 2026 il progetto PHP ha chiuso le due vulnerabilità critiche CVE-2026-109618 e CVE-2026-109619 con le versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Molti responsabili vi hanno poi messo una spunta. Due giorni dopo, il 23 ottobre, è però seguita un'ulteriore segnalazione di php.net su CVE-2026-115560.
Questa terza segnalazione riguarda solo una configurazione di sessione insolita. Mostra però uno schema noto dai grandi casi di sicurezza: quando un componente finisce improvvisamente sotto i riflettori, molti esperti guardano contemporaneamente più da vicino. Se ne nasceranno altre vulnerabilità oggi non lo sa nessuno. È però probabile che il flusso di notizie non si interrompa.
Per Lei come gestore significa: metta in conto le segnalazioni successive, invece di farsi sorprendere da ciascuna. Lo svolgimento degli eventi finora lo riassume la nostra cronologia di PHP2Shell.
Perché altre segnalazioni sono probabili
La valutazione seguente si basa su fatti noti pubblicamente. Non è una previsione di vulnerabilità concrete.
- Un advisory è ancora in sospeso. php.net tratta CVE-2026-115560 nel ciclo di rilascio regolare e ha annunciato di pubblicare l'advisory completo con il prossimo rilascio. Fino ad allora vale
session.upload_progress.enabled=0come rimedio. - I dettagli erano pubblici presto. Secondo diversi rapporti, i particolari sono diventati noti prima della fine dell'embargo. Secondo i rapporti, watchTowr ha riprodotto CVE-2026-109618 per sua stessa dichiarazione. Simili lavori portano spesso a domande successive su punti di codice adiacenti.
- Le distribuzioni consegnano in modo scaglionato. Ubuntu ha servito il 21 ottobre con USN-8948-1 i rilasci attuali e con USN-8948-2 ha fornito successivamente correzioni per 14.04–20.04 tramite Ubuntu Pro. Red Hat ha scritto nel proprio bollettino che alcuni aggiornamenti sono disponibili, altri in lavorazione.
- La versione di sviluppo è interessata. Secondo php.net anche PHP 8.6.0 RC4 contiene le correzioni. Chi testa versioni preliminari deve aggiornare anche questi ambienti.
- Le versioni vecchie restano aperte. Per PHP 8.1 e precedenti esistono solo backport minimi del codice sorgente. Ogni fornitore che distribuisce tali versioni comunica il proprio stato in modo autonomo e nei propri tempi.
Come una nuova vulnerabilità PHP arriva a Lei
Le segnalazioni arrivano per vie diverse e con diversa affidabilità. L'ordine è quasi sempre lo stesso: prima il progetto PHP, poi distribuzioni e hoster, poi autorità e media.
| Fonte | Cosa vi apprende | Affidabilità |
|---|---|---|
| php.net | rami interessati, versioni corrette, misure transitorie | fonte primaria |
| Ubuntu, Debian, Red Hat | stato dei pacchetti per ogni rilascio, momento della consegna | fonte primaria per il Suo sistema |
| Hoster e fornitori di pannelli | stato dei propri build PHP | vincolante solo se per iscritto |
| BSI, CERT-Bund (il CERT del governo tedesco) | valutazione della situazione, livello di allerta, raccomandazioni | inquadramento delle autorità |
| Stampa specializzata e società di sicurezza | osservazioni sugli attacchi, numeri, retroscena | utili, da indicare come rapporto |
Importante è la differenza tra «esiste una patch» e «il mio sistema ha la patch». La prima affermazione è su php.net. La seconda deve documentarla Lei per ogni server.
Si iscriva alle segnalazioni di php.net e della Sua distribuzione via RSS o mailing list e le inoltri a una casella condivisa o a un canale letto da più di una persona. Ferie e malattia sono i motivi più frequenti di aggiornamenti in ritardo.
Cosa preparare prima della prossima segnalazione
L'esperienza di PHP2Shell mostra dove si perde tempo: nella ricerca dei server, nel chiarire le responsabilità e nel riavvio dimenticato. Tutto questo si può fare prima.
- Inventario: un elenco di tutti i server e siti con ramo PHP, modalità di esecuzione (PHP-FPM, mod_php, LiteSpeed) e origine dei pacchetti. Senza questo elenco ogni segnalazione inizia con la ricerca. Come riuscirci lo descrive l'articolo Inventario di tutti i siti web e server.
- Responsabilità: per ogni sistema è stabilito chi applica la patch, chi riavvia e chi autorizza. Con hoster e agenzie ciò va nel contratto.
- Griglia di valutazione: bastano tre domande per il primo inquadramento. Il nostro ramo è interessato? Usiamo la funzione o la modalità di esecuzione interessata? Esiste una patch o solo misure transitorie?
- Percorso di test: un ambiente di staging in cui un aggiornamento di PHP possa essere verificato in breve tempo.
- Prova: un formato fisso in cui annotare stato dei pacchetti, riscontri nel changelog e ora del riavvio.
Come una procedura simile funzioni come routine anziché come intervento d'emergenza è spiegato in Patch management come processo. Un retroscena sul modo in cui il progetto PHP tratta le vulnerabilità lo offre la pagina Come il progetto PHP tratta le vulnerabilità di sicurezza.
La propria configurazione come sistema di preallarme
Una parte delle segnalazioni successive riguarda solo determinate impostazioni. CVE-2026-115560 ne è un esempio: php.net indica come presupposto che un'applicazione cambi in fase di esecuzione il serializer di sessione mentre l'upload progress è attivo. Le applicazioni che non lo fanno mai non sono, secondo php.net, interessate.
Chi conosce la propria configurazione effettiva può inquadrare più rapidamente simili segnalazioni. Annoti quindi per ogni ramo quali valori sono impostati lato server e quali applicazioni possono sovrascriverli. Già un semplice confronto delle impostazioni attive aiuta:
# Valori effettivi della riga di comando (la configurazione web può differire)
php -i | grep -E "session.upload_progress.enabled|session.serialize_handler|memory_limit|post_max_size"
# Valori impostati nei pool FPM (percorso diverso a seconda della distribuzione)
grep -RhE "php_(admin_)?value" /etc/php/*/fpm/pool.d/ 2>/dev/null
La riga di comando non mostra necessariamente ciò che vale nel contesto web. Fanno chiarezza la configurazione del pool o del VirtualHost e, per breve tempo e in modo protetto, una pagina phpinfo.
Un ulteriore vantaggio: chi sa quali valori transitori della settimana di PHP2Shell sono ancora impostati può verificarli consapevolmente dopo il prossimo rilascio regolare. Alcune impostazioni, come l'upload progress disattivato, possono restare sensate in modo permanente. Altre, come limiti di upload molto ristretti, dovrebbe riadeguarle all'esigenza reale previo accordo con i reparti interessati.
Come aiuta concretamente PHP SOS?
- Seguiamo le segnalazioni di php.net, delle distribuzioni e del BSI e valutiamo le nuove indicazioni per i Suoi sistemi concreti.
- Realizziamo con Lei l'inventario di tutte le installazioni PHP e definiamo le responsabilità per ogni server.
- Nell'ambito di un contratto di manutenzione della sicurezza installiamo gli aggiornamenti, riavviamo tutti i processi e documentiamo lo stato.
- Per le segnalazioni senza patch applichiamo misure transitorie non sovrascrivibili e le verifichiamo.
Domande frequenti
Dopo PHP2Shell esiste già una nuova vulnerabilità PHP?
Il 23 ottobre 2026 php.net ha pubblicato una segnalazione su CVE-2026-115560. L'esecuzione di codice è possibile, secondo questa, solo con una configurazione di sessione insolita. Un advisory completo dovrebbe seguire con il prossimo rilascio regolare.
Devo agire subito dopo ogni nuova segnalazione?
Non ogni segnalazione richiede la stessa urgenza. Decisivi sono la gravità, il coinvolgimento della Sua configurazione e se sia disponibile una patch. Una procedura definita aiuta a valutarlo in minuti anziché in giorni.
Dove vengo a sapere per primo delle nuove vulnerabilità PHP?
Le fonti primarie sono le segnalazioni su php.net e gli avvisi di sicurezza della Sua distribuzione, ad esempio le Ubuntu Security Notices, il Debian Security Tracker o Red Hat. Il BSI informa tramite avvisi. Gli articoli dei media sono utili, ma spesso più tardivi e meno precisi.
Perché le distribuzioni a volte segnalano giorni dopo php.net?
Le distribuzioni devono recepire la correzione nei propri pacchetti, compilarli e testarli. Per i rilasci più vecchi può richiedere più tempo o avvenire solo tramite offerte aggiuntive. Per questo conviene seguire separatamente entrambe le fonti.