In breve: PHP2Shell e Log4Shell hanno in comune di essere vulnerabilità critiche in un componente di base molto diffuso, attraverso le quali gli aggressori possono eseguire codice senza autenticazione. Si distinguono per visibilità, classificazione e situazione degli attacchi noti. La lezione più importante di Log4Shell vale oggi invariata: chi sa dove gira il componente interessato agisce in ore anziché in settimane.
Perché il confronto compare proprio ovunque
Nel dicembre 2021 Log4Shell tenne il mondo IT con il fiato sospeso per settimane. Il BSI (l'Ufficio federale tedesco per la sicurezza informatica) proclamò allora il livello di allerta più alto, il rosso. Quasi cinque anni dopo, con PHP2Shell lo stesso nome ricorre in molti articoli, spesso con la domanda: «Sarà di nuovo così grave?»
Il confronto è ovvio, ed è utile se lo si conduce correttamente. Mostra quali schemi si ripetono e quali esperienze le aziende possono usare direttamente oggi. Come il BSI classifichi la situazione attuale lo spiega l'articolo Allerta arancione del BSI.
PHP2Shell e Log4Shell a confronto diretto
| Caratteristica | Log4Shell (2021) | PHP2Shell (2026) |
|---|---|---|
| Software interessato | libreria Java Log4j | il runtime PHP stesso |
| Identificativo | CVE-2021-44228 | CVE-2026-109618, CVE-2026-109619 |
| Valutazione | CVSS 10.0 (v3) | CVSS v4.0 9,2 |
| Effetto | esecuzione di codice senza autenticazione | esecuzione di codice senza autenticazione |
| Livello di allerta BSI | 4 / rosso | 3 / arancione |
| Situazione all'allerta | secondo i rapporti di allora, compromissioni note | tentativi di attacco segnalati, secondo il BSI inizialmente nessun attacco riuscito su larga scala confermato |
| Visibilità | spesso nascosta in profondità nelle applicazioni | visibile sul server, ma stato della patch difficile da leggere a causa dei backport |
| Segnalazioni successive | diversi altri CVE in poche settimane | segnalazione su CVE-2026-115560 il 23/10 |
Cosa hanno in comune le due vulnerabilità
Un componente di base, innumerevoli applicazioni. Log4j era presente in software Java di ogni tipo, PHP sostiene WordPress, Shopware, TYPO3 e innumerevoli sviluppi su misura. In entrambi i casi non è interessato un prodotto, ma una fondazione.
Nessun login necessario. Entrambe le vulnerabilità consentono l'esecuzione di codice da remoto senza autenticazione. Ciò le rende attraenti per attacchi automatizzati.
La patch non è la fine. Con Log4Shell si vide che molti sistemi erano già stati attaccati prima dell'aggiornamento. Anche con PHP2Shell vale: una patch non rimuove il software dannoso introdotto. Secondo i rapporti dei media, un primo tentativo di attacco sarebbe stato osservato già il 17 ottobre.
Segnalazioni successive. Dopo Log4Shell uscirono nel giro di poche settimane altri CVE su Log4j. Con PHP, due giorni dopo le patch è arrivata la segnalazione su CVE-2026-115560. Perché altre segnalazioni siano probabili lo spiega Dopo PHP2Shell: perché altre segnalazioni sono probabili.
Dove il confronto zoppica
La differenza maggiore sta nella visibilità. Log4j era spesso integrato come parte di un'applicazione, a volte annidato più volte. Molti gestori semplicemente non sapevano di usarlo. PHP, invece, su un server web non è un segreto. In compenso con PHP2Shell nasce un'altra incertezza: distribuzioni e hoster installano le correzioni come backport, il numero di versione visualizzato resta lo stesso. Si vede PHP, ma non subito se è aggiornato.
Una seconda differenza è la situazione di partenza per l'aggiornamento. Con Log4Shell dovevano spesso essere i produttori di applicazioni specialistiche a fornire prima nuove versioni. Con PHP2Shell gli aggiornamenti sono pronti per tutti i rami supportati. Diventa difficile con PHP 8.1 e precedenti, per i quali il progetto PHP non pubblica più aggiornamenti ufficiali.
Una terza differenza riguarda il luogo dell'attacco. Con Log4Shell poteva essere pericoloso ogni punto in cui un'applicazione registrava input, quindi anche sistemi interni che ricevevano dati da Internet solo indirettamente. Con PHP2Shell al centro c'è il server web, che riceve direttamente le richieste. Ciò rende la ricerca dei sistemi interessati un po' più chiara: prima vengono tutti i servizi PHP raggiungibili pubblicamente, poi le applicazioni interne.
Infine differisce la situazione dello sfruttamento. Per Log4Shell circolarono presto semplici strumenti di attacco, e le compromissioni erano, secondo i rapporti di allora, già note al momento dell'allerta. Con PHP2Shell Cloudflare e Patchstack riferiscono di tentativi di attacco, watchTowr ha riprodotto una delle vulnerabilità secondo le proprie dichiarazioni, attacchi riusciti su larga scala confermati il BSI inizialmente non li ha segnalati. Questo può cambiare. È però un motivo per cui il confronto non serve come previsione.
Usi in casa le esperienze di Log4Shell: quali elenchi, procedure e contatti aiutarono allora? Molto di ciò si può riutilizzare direttamente per PHP2Shell.
Cinque lezioni di Log4Shell che aiutano oggi
- Inventario prima della patch: chi nel 2021 aveva un elenco aggiornato dei propri sistemi fu più rapido. Vale oggi allo stesso modo. Una guida la offre l'articolo Inventario di tutti i siti web e server.
- Conoscere le dipendenze: una distinta dei componenti software, in breve SBOM, risponde in minuti alla domanda «Dove lo usiamo?». Per le applicazioni PHP aiuta uno sguardo a Composer, come lo descrive Verificare le dipendenze Composer.
- Conservare i log: dopo Log4Shell molte aziende non poterono più chiarire se fossero state colpite, perché mancavano i log. La stampa specializzata consiglia, con PHP2Shell, di conservare i log dal 20 ottobre.
- Verificare a posteriori: una patch non risponde a ciò che è accaduto prima. Una verifica delle tracce ne fa parte.
- Essere preparati alle segnalazioni successive: il primo aggiornamento raramente è l'ultimo. Chi ha impostato una volta bene il percorso di aggiornamento lo ripete rapidamente.
Come aiuta concretamente PHP SOS?
- Inventario: accertiamo dove gira PHP nella Sua azienda, in quale versione e modalità di esecuzione.
- Patch e riavvio: installiamo gli aggiornamenti e documentiamo lo stato di ogni sistema.
- Verifica delle tracce: conserviamo i log e cerchiamo anomalie dal 17 ottobre.
- Osservazione continua: teniamo d'occhio i Suoi sistemi, perché le segnalazioni successive non ripartano da zero.
Come si presenta il monitoraggio continuo lo descrive Security monitoring per server web.
Conclusione
PHP2Shell non è Log4Shell, ma fanno rima. Entrambe colpiscono una fondazione, entrambe richiedono più di una patch. Le aziende che dal 2021 hanno portato con sé inventario, conservazione dei log e percorsi di aggiornamento sono oggi in vantaggio. Per tutte le altre è il momento di recuperare.
Domande frequenti
PHP2Shell è grave come Log4Shell?
Entrambe sono vulnerabilità critiche in software molto diffuso, attraverso le quali gli aggressori possono eseguire codice senza autenticazione. Il BSI classificò Log4Shell nel 2021 con il rosso, PHP2Shell con l'arancione. Una differenza importante: con Log4Shell, secondo i rapporti di allora, al momento dell'allerta erano già note compromissioni; con PHP2Shell, secondo il BSI, inizialmente non c'erano attacchi riusciti su larga scala confermati.
Che cos'era Log4Shell?
Log4Shell era una vulnerabilità critica nella libreria Java Log4j, resa nota nel dicembre 2021 e registrata come CVE-2021-44228. Log4j era presente come componente in moltissime applicazioni, spesso senza che i gestori lo sapessero.
Dopo PHP2Shell arriveranno altre vulnerabilità?
È possibile. Dopo Log4Shell, nel giro di poche settimane seguirono altri CVE su Log4j. Con PHP c'è già stata il 23 ottobre una segnalazione su CVE-2026-115560, che interviene solo con una configurazione insolita. Metta in conto segnalazioni successive.
Che cos'è una SBOM?
Una Software Bill of Materials è una distinta di tutti i componenti software di cui è composta un'applicazione. Con essa, in caso di nuova vulnerabilità, si può accertare rapidamente dove venga impiegato il componente interessato.