In breve: una settimana dopo il primo tentativo di attacco osservato, PHP2Shell è oggi soprattutto una questione di attuazione: le patch per PHP da 8.2 a 8.5 sono disponibili dal 21 ottobre, le grandi distribuzioni si sono adeguate, il BSI (l'Ufficio federale tedesco per la sicurezza informatica) avvisa con il livello arancione. Sono stati osservati tentativi di attacco, attacchi riusciti su larga scala confermati il BSI inizialmente non li ha segnalati. Restano aperte le versioni vecchie, i server non riavviati e la domanda su cosa sia successo prima della patch.
La situazione in tre frasi
PHP2Shell sono due vulnerabilità critiche nell'interprete PHP stesso, CVE-2026-109618 e CVE-2026-109619, valutate ciascuna con CVSS v4.0 9,2. Consentono l'esecuzione di codice da remoto senza autenticazione, cioè il caso che gli addetti alla sicurezza temono di più. Sono interessati PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed; il rischio più alto il team PHP lo vede con mod_php.
Questa panoramica ordina lo stato al 25 ottobre 2026 per attori. Lo svolgimento giorno per giorno si trova nella cronologia di PHP2Shell, qui si tratta del quadro d'insieme.
Cosa è accertato dopo una settimana
Sono sicure le indicazioni del progetto PHP: i rilasci 8.5.12, 8.4.27, 8.3.36 e 8.2.35 del 21 ottobre chiudono entrambe le vulnerabilità. Per PHP 7.4, 8.0 e 8.1 esistono solo backport minimi del codice sorgente, nessun rilascio ufficiale. php.net sottolinea che non esistono misure transitorie complete e che l'aggiornamento è l'unica via sicura.
Il 23 ottobre si è aggiunta una segnalazione su CVE-2026-115560. Riguarda solo una configurazione di sessione insolita; come rimedio php.net indica session.upload_progress.enabled=0 fino al prossimo rilascio regolare di correzioni.
Anche le grandi distribuzioni hanno preso posizione. Abbiamo verificato le segnalazioni ufficiali:
| Fornitore | Stato secondo la segnalazione ufficiale |
|---|---|
| Ubuntu | USN-8948-1 per 22.04, 24.04, 26.04 e 26.10; USN-8948-2 per 14.04–20.04 tramite Ubuntu Pro |
| Debian | pacchetti corretti per bookworm (php8.2, DLA-4848-1) e trixie (php8.4, DSA-6574-1) |
| Red Hat | bollettino RHSB-2026-013 per RHEL da 7 a 10; alcuni aggiornamenti disponibili, altri in lavorazione |
Red Hat classifica CVE-2026-109618 con una valutazione propria come «Important» e lo motiva con una maggiore complessità dell'attacco. È un metodo di valutazione diverso da quello del progetto PHP e non è un motivo per rimandare l'aggiornamento.
Come le autorità valutano la situazione
Il BSI ha proclamato il livello di allerta 3 / arancione. Raccomanda l'aggiornamento immediato e, se non è subito possibile, di scollegare temporaneamente dalla rete i server web interessati. Il BSI contava su uno sfruttamento rapido e su vasta scala. Cosa significhi la classificazione lo spiega la pagina Cosa raccomanda il BSI su PHP2Shell.
Secondo i rapporti, CERT-EU ritiene possibile che siano interessate le versioni a partire da PHP 5 e consiglia di isolare le applicazioni raggiungibili pubblicamente se non possono essere aggiornate in tempi brevi. Hanno avvisato anche CERT-Bund (il CERT del governo tedesco) e la società di sicurezza Huntress.
La raccomandazione di spegnere in caso di necessità è stata attuata in modo visibile. Secondo i rapporti dei media, la città di Magonza ha portato offline in via precauzionale il proprio portale web centrale; gli uffici sono rimasti raggiungibili per telefono e e-mail. In Assia erano temporaneamente offline, secondo hessenschau, pagine del governo regionale, del BKA (la polizia criminale federale tedesca) e delle città di Kassel e Wiesbaden. La cancelleria di Stato non ha segnalato alcun attacco, le pagine erano di nuovo raggiungibili la sera. Altri comuni, università e cliniche hanno agito in modo simile, secondo i rapporti.
Cosa si sa degli attacchi
Qui la separazione tra osservazione e conferma è particolarmente importante.
- Osservato: secondo i rapporti dei media, il 17 ottobre c'è stato un primo tentativo di attacco, osservato da Amazon. Cloudflare e Patchstack hanno riferito di tentativi di attacco; Cloudflare ha inoltre visto schemi di attacco modificati.
- Riprodotto: watchTowr ha riprodotto CVE-2026-109618, secondo i rapporti e per sua stessa dichiarazione.
- Non confermato: il BSI inizialmente non ha segnalato sfruttamenti riusciti su larga scala confermati. Huntress, al momento della sua segnalazione, non vedeva attacchi negli ambienti dei partner.
- Sconosciuto: non esistono Indicators of Compromise pubblicati e confermati. Chi vuole verificare se un server è interessato deve badare agli schemi di comportamento.
Sull'entità circolano due numeri. I ricercatori di Unit 42 di Palo Alto Networks sono arrivati a oltre 22,6 milioni di istanze potenzialmente vulnerabili raggiungibili dalla rete. CybelAngel parla di circa 2,24 milioni di host PHP raggiungibili, di cui, secondo la propria analisi, il 59 percento su versioni senza una futura correzione ufficiale. Entrambi misurano cose diverse e non sono direttamente confrontabili. Un inquadramento lo offre l'articolo Come leggere i numeri.
Cosa resta aperto
Tre domande determinano le prossime settimane:
- Versioni vecchie: una grande parte delle installazioni PHP raggiungibili gira, secondo le analisi citate, su rami senza correzione ufficiale. Se le offerte commerciali di supporto a lungo termine coprano PHP2Shell va confermato per iscritto, di volta in volta, dal fornitore.
- Aggiornamenti incompleti: i nuovi pacchetti hanno effetto solo quando tutti i processi PHP sono stati riavviati. Red Hat sottolinea espressamente che un semplice ricaricamento non basta.
- Il periodo prima della patch: tra il 17 e il 21 ottobre i server erano vulnerabili mentre erano già in corso tentativi di attacco. Una patch non dimostra che in questo periodo non sia successo nulla.
Conservi i log del server web e di PHP dal 20 ottobre, come raccomanda la stampa specializzata. Senza log la domanda aperta più importante per il Suo server non potrà più essere chiarita in seguito.
Cosa dovrebbero verificare ora i gestori
Per la propria valutazione della situazione bastano quattro punti di controllo per ogni server: PHP è a uno stato corretto o a un backport confermato? Tutti i processi girano dall'aggiornamento? session.upload_progress.enabled è disattivato lato server finché l'advisory su CVE-2026-115560 è in sospeso? Ci sono anomalie dal 17 ottobre?
Per l'ultimo punto aiuta la pagina Sono già compromesso?. Un processo del server web che avvia una shell, nuovi file PHP nelle cartelle di upload, cronjob o chiavi SSH sconosciuti sono segnali d'allarme che giustificano un esame più accurato.
Come aiuta concretamente PHP SOS?
- Valutiamo lo stato della patch di ogni server in base a stato dei pacchetti, changelog e orari di avvio dei processi.
- Dove non è disponibile alcuna patch, applichiamo le misure transitorie di php.net e chiariamo il percorso verso la versione supportata.
- Conserviamo i log dal 20 ottobre e cerchiamo tracce del periodo precedente alla patch.
- Con il pronto intervento PHP2Shell riuniamo questi passaggi per le aziende che hanno bisogno di fare chiarezza in fretta.
Domande frequenti
PHP2Shell viene già sfruttata attivamente?
Cloudflare e Patchstack hanno riferito di tentativi di attacco. Il BSI inizialmente non ha segnalato attacchi riusciti su larga scala confermati. Huntress, al momento della sua segnalazione, non vedeva attacchi negli ambienti dei partner.
Dopo le patch il pericolo è passato?
No. Le patch proteggono solo i server che le hanno installate e hanno riavviato tutti i processi PHP. I sistemi con PHP 8.1 e precedenti restano vulnerabili senza backport confermato, e una patch non rimuove il software dannoso introdotto in precedenza.
Perché i siti delle autorità erano offline?
Secondo i rapporti dei media, tra gli altri la città di Magonza e diversi enti in Assia hanno spento i propri siti in via precauzionale. Ciò corrisponde alla raccomandazione del BSI per i server che non possono essere aggiornati subito. Uno spegnimento non significa che sia avvenuto un attacco.
Esistono indicatori per riconoscere un attacco PHP2Shell?
Finora non esistono Indicators of Compromise pubblicati e confermati. Il riconoscimento si basa sull'analisi del comportamento, ad esempio su processi PHP che avviano una shell o su nuovi file PHP nelle cartelle di upload.