Quando è emerso PHP2Shell, un governo del G7 ha chiesto a Red Sift ogni host esposto del suo patrimonio nazionale e ha ricevuto l'elenco con ogni host associato al dipartimento che ne è responsabile.
Due falle critiche in PHP coinvolgono ogni versione a partire da PHP 5. I governi di tutto il mondo si ponevano la stessa domanda: dove usiamo PHP? La maggior parte ha scelto di spegnere i servizi. Uno si è rivolto a noi e ha avuto la risposta per l'intero patrimonio nazionale prima del rilascio delle patch.
Questi sono i dati migliori che abbiamo visto.
Il team di PHP annuncia con un giorno di anticipo una correzione d'emergenza. Gli identificativi CVE sono online la sera stessa e CERT-EU pubblica un avviso di sicurezza prima che esista una patch. Gli honeypot di Amazon avevano già registrato un'attività di ricognizione mirata alle falle tre giorni prima.
Per chi gestisce infrastrutture governative, il problema è immediato. Ogni versione a partire da PHP 5 può essere vulnerabile. Un filtro per versione è inutile. L'unico punto di partenza sicuro è un elenco completo di ogni host esposto su internet che esegue PHP, in qualsiasi versione, in qualsiasi punto del patrimonio.
Non un campione, non un solo dipartimento. Ogni dipartimento e agenzia di cui il governo è responsabile, ricondotti a host identificati per nome. Costruire quell'elenco a mano significa rincorrere registri degli asset, account cloud, fornitori e appliance che integrano PHP senza dichiararlo. Sono settimane di lavoro, e la finestra di patch si apre il pomeriggio successivo.
Red Sift Hardenize, la nostra soluzione di gestione della superficie di attacco (ASM), individua e monitora costantemente i server esposti su internet e registra il software eseguito da ciascuno. L'inventario di cui il governo aveva bisogno esisteva già. Lo abbiamo interrogato, abbiamo ricondotto ogni host PHP al dipartimento responsabile e consegnato l'elenco dell'intero patrimonio in un'unica vista, prima della pubblicazione delle versioni corrette alle 13:30 UTC del 21 ottobre.
La stessa scansione è stata eseguita per tutti i clienti ASM. Ogni cliente direttamente interessato ha ricevuto i propri hostname, l'orario di rilascio e gli avvisi ufficiali prima della patch.
Altri fornitori ci dicono che è impossibile ottenere il livello di dati che Red Sift è in grado di fornire.
La patch richiede pochi minuti. Trovare ogni host che ne ha bisogno può richiedere settimane. I governi che si sono mossi più rapidamente avevano già l'elenco.
Un governo ha chiesto. Ogni cliente Red Sift ASM interessato ha ricevuto la stessa cosa: un elenco nominativo dei propri host PHP, prima del rilascio della correzione il 21 ottobre. Poi abbiamo misurato cosa ne hanno fatto, ogni giorno per cinque giorni.
PHP CVE-2026-109618 / 109619 · 21–26 ott 2026
10.114
server vulnerabili noti dei clienti in meno in cinque giorni.
Un calo del 62%, da 16.203 a 6.089. Le organizzazioni clienti con almeno un server vulnerabile noto sono scese da 443 a 254.
Ogni cliente interessato aveva l'elenco nominativo dei propri host prima del rilascio della correzione.
redsift.comFonte: scansioni giornaliere di Red Sift dei server dei clienti esposti su internet; variazione netta tra il 21 e il 26 ott 2026.
Il 26 ottobre, 4.909 dei 6.089 server dei clienti ancora esposti eseguivano PHP 8.1 o precedente. Per queste versioni non esiste una release ufficiale di PHP da installare, quindi serve un backport del fornitore o un aggiornamento. È lì che si concentra ora il lavoro, e si parte dalla stessa domanda del primo giorno: quali sono i Suoi server?
Potrebbe produrre oggi questa vista per i Suoi server? Se la risposta non è chiara, Le invieremo un'istantanea esterna una tantum del Suo dominio.
Ambito: host esposti su internet in cui è stato rilevato PHP, nelle istanze dei clienti Red Sift ASM (Hardenize), confrontati ogni giorno dal 21 al 26 ottobre 2026. Sono escluse le istanze demo, sandbox e di ricerca. Le organizzazioni corrispondono alle istanze dei clienti.
Con patch significa che l'host riporta 8.5.12, 8.4.27, 8.3.36, 8.2.35 o una versione successiva dello stesso ramo; un host che riporta più versioni viene conteggiato solo se sono tutte corrette. Vulnerabile noto significa che riporta una versione non corretta su qualsiasi ramo. Gli host con 8.1 o precedente potrebbero già includere un backport non visibile dall'esterno.
Le variazioni sono nette: un server esce dal conteggio quando riceve la patch, viene aggiornato a una versione superiore, viene dismesso o smette di riportare una versione. Circa 9.185 host dei clienti non esponevano alcuna versione il 26 ottobre e non sono conteggiati in nessuno dei due sensi. Ogni versione a partire da PHP 5 è interessata, quindi vanno considerati potenzialmente esposti.
La nostra soluzione di gestione della superficie di attacco (ASM) individua e monitora costantemente i Suoi server esposti su internet e registra il software eseguito da ciascuno. Quando emerge una falla come questa, la prima domanda passa da «da dove cominciamo?» a «ecco l'elenco».
Prima che il team di PHP rilasciasse le correzioni, abbiamo analizzato ogni host che monitoriamo nell'intera base clienti ASM per individuare quelli che eseguono PHP.
Abbiamo ricondotto ogni host interessato al cliente, dipartimento o agenzia che ne è responsabile, così ogni notifica riguardava un solo patrimonio.
Ogni soggetto direttamente interessato ha ricevuto gli hostname potenzialmente esposti, l'orario di rilascio e i link agli avvisi ufficiali, prima della pubblicazione delle versioni corrette.
Notifica al cliente · 21 ottobre 2026 · prima della release di sicurezza di PHP
Orario di rilascio annunciato: 21 ott, 14:00 UTC. Versioni corrette: 8.5.12 · 8.4.27 · 8.3.36 · 8.2.35. Applichi prima la patch agli host esposti su internet e riavvii tutti i worker.
Gli hostname sono esempi. Le notifiche reali contengono gli host del cliente.
La scansione esterna vede ciò che un host rivela e copre gli asset del Suo account. I sistemi interni, gli host al di fuori dell'ambito monitorato e i prodotti che nascondono il proprio runtime PHP devono comunque essere verificati da Lei.
Se è cliente di Red Sift ASM e non ha ricevuto una notifica, non abbiamo trovato PHP sugli host che monitoriamo per Lei. Le consigliamo comunque alcune verifiche sommarie da parte Sua.
Il valore sta nella specificità: host identificati per nome, nel Suo patrimonio, prima che si apra la finestra di patch.
Qualunque sia il punto di partenza, la prima mossa è la stessa: conoscere ogni host esposto su internet di cui si è proprietari e ciò che esegue. Ecco come possiamo aiutarLa, in base alla Sua situazione.
Ha già ricevuto le nostre informazioni preliminari: gli host che monitoriamo per Lei su cui è in esecuzione PHP, con i tempi di rilascio e gli avvisi. Siamo disponibili ad andare oltre insieme a Lei sull'intero patrimonio, incluso l'ambito che non ha ancora aggiunto, e ad aiutarLa a stabilire le priorità per la lunga coda di host che non possono ricevere la patch in tempi brevi.
Se è un governo nazionale o un ente del settore pubblico e non usa ancora la nostra soluzione di gestione della superficie di attacco, ci contatti. Stiamo già producendo elenchi di esposizione dell'intero patrimonio su scala nazionale, ricondotti a host identificati per nome, e questi dati vengono confrontati con ciò che altri fornitori sono in grado di offrire.
PHP fa funzionare gran parte del web, è integrato in prodotti che non ha sviluppato Lei e l'attacco arriva prima che la Sua applicazione se ne accorga. Se oggi non è in grado di dire quanti host PHP esposti su internet possiede, questo è il primo problema da risolvere, e possiamo aiutarLa già questa settimana.
Tratte dall'avviso di sicurezza di PHP, dall'allerta dell'NCSC britannico e dal nostro articolo tecnico.
Inizi dagli host esposti su internet. Non filtri per versione. Includa container, immagini di base e tutto ciò che è compilato dai sorgenti.
8.5.12, 8.4.27, 8.3.36 o 8.2.35, oppure il pacchetto con patch della Sua distribuzione. Per 8.1 e precedenti, usi un backport del fornitore o passi a una versione superiore.
Un binario con patch non serve a nulla per i pool FPM o i processi figli di Apache che eseguono ancora il vecchio codice.
Imposti memory_limit=-1 a livello amministrativo, riduca post_max_size, imposti session.upload_progress.enabled=0 e, sulla 8.5, fatal_error_backtraces=0. Riavvii di nuovo i worker. Queste misure bloccano i vettori di attacco confermati e vanno considerate una soluzione ponte in attesa della patch.
CERT-EU e l'NCSC consigliano entrambi di mettere offline un'applicazione esposta su internet finché non viene corretta.
Cerchi segni di compromissione su tutto ciò che non ha potuto aggiornare rapidamente e consulti gli avvisi dei fornitori per i prodotti che integrano PHP.
PHP2Shell è il nome dato a CVE-2026-109618 e CVE-2026-109619, due falle di esecuzione di codice remoto senza autenticazione nel motore principale di PHP. Si trovano nel codice eseguito quando un worker esaurisce la memoria o incontra un errore fatale, quindi non dipendono dall'applicazione sovrastante. WordPress, Drupal, Laravel, applicazioni personalizzate e console di appliance sono tutti coinvolti.
Qualsiasi installazione PHP che serve richieste web può essere interessata, su PHP-FPM, Apache mod_php, php-cgi, FrankenPHP e LiteSpeed. mod_php presenta il rischio più elevato perché l'exploit dimostrato si attiva durante il parsing della richiesta, prima che una regola del web application firewall legata alle route dell'applicazione possa rilevarlo.
Esistono correzioni compilate per quattro rami. I rami più vecchi hanno ricevuto solo backport a livello di sorgente, oppure nulla. Un terzo problema correlato, CVE-2026-115560, è stato divulgato il 23 ottobre ed è coperto dalla mitigazione esistente.
| Ramo | Corretto in | Stato |
|---|---|---|
| 8.5 | 8.5.12 | Supportato |
| 8.4 | 8.4.27 | Supportato |
| 8.3 | 8.3.36 | Solo correzioni di sicurezza |
| 8.2 | 8.2.35 | Fine vita il 31 dic 2026 |
| 8.1 · 8.0 · 7.4 | Solo backport dei sorgenti | Nessuna release compilata. Backport del fornitore o aggiornamento. |
| 7.3 e precedenti | Nessuna | Include PHP 5. Aggiornare. |
Versioni corrette rilasciate il 21 ottobre 2026 alle 13:30 UTC. Fonte: php.net e avvisi di sicurezza GitHub.
Appliance e console lo integrano. Palo Alto Networks, Fortinet e Cisco stavano tutti valutando i propri prodotti nel giro di poche ore.
Ogni versione a partire da PHP 5 può essere vulnerabile. La prima azione indicata dall'NCSC: identificare tutti i sistemi che eseguono qualsiasi versione.
Circa il 42% degli host PHP esposti su internet esegue rami a fine vita senza correzione compilata (VulnCheck).
Un binario con patch non serve a nulla per i pool FPM o i processi figli di Apache finché ogni worker non viene riavviato.
Entro 48 ore, le agenzie nazionali di cybersicurezza di quattro continenti hanno chiesto alle organizzazioni di applicare subito la patch o di mettere offline i sistemi. Diversi governi hanno disattivato per primi i propri servizi pubblici, perché non erano ancora in grado di dire quali fossero esposti.
Allerta dell'NCSC e oltre 50.000 avvisi diretti. Identificare ogni sistema PHP, applicare la patch o valutare di metterlo offline. Il 22 ottobre il ministro ha riferito al Parlamento che 32 servizi governativi erano non disponibili e quattro lo erano parzialmente, per lo più a titolo precauzionale. Il monitoraggio di base dei domini del settore pubblico svolto dalla Government Cyber Unit utilizza Hardenize, lo strumento di gestione della superficie di attacco di Red Sift, che analizza .gov.uk ogni otto ore.
Servizi governativi messi offline su indicazione di NCSC-NL, tra cui DigiD e il sito web del parlamento. NCSC-NL gestisce l'inventario pubblico dei prodotti che integrano PHP.
Tutti i servizi web pubblici governativi disattivati da Valtori, l'agenzia IT dello Stato, durante l'applicazione delle patch.
Il Primo ministro ha esortato i gestori dei siti a prepararsi e a valutare di andare offline. Il Ministero delle Finanze, l'Agenzia meteorologica e l'Agenzia nazionale delle entrate hanno sospeso i servizi. JPCERT ha pubblicato indicatori di compromissione.
Avviso critico del BSI. Il centro IT federale, ITZBund, ha messo offline i siti web federali come misura puramente preventiva.
Allerta CERT-FR: isolare i sistemi interessati. Il Ministero dell'Interno ha messo offline i siti web delle prefetture.
CISA e NSA: applicare subito la patch o mettere offline il sistema. La NSA ha dichiarato che con ogni probabilità gli attori informatici trasformeranno le falle in armi e ha chiesto l'applicazione immediata delle patch in tutti i dipartimenti e le agenzie del governo statunitense.
Avviso CERT-EU 2026-018 prima delle patch, seguito da una dichiarazione congiunta di Commissione, ENISA, CERT-EU ed Europol.
Allerta del Cyber Centre AL26-026. Alcuni siti web del Governo del Canada sono stati temporaneamente non disponibili; l'allerta è stata aggiornata il 23 ottobre per il terzo CVE.
Allerta critica dell'ACSC: agire subito. Identificare i sistemi PHP, monitorare le attività dannose, applicare le patch man mano che arrivano gli aggiornamenti.
Mettere offline un servizio è la risposta di ultima istanza, e i governi di quattro continenti vi hanno fatto ricorso nel giro di poche ore. Questa è la portata del problema dell'inventario, anche per team con molte risorse.
La soluzione di gestione della superficie di attacco di Red Sift mappa ogni host esposto su internet del Suo patrimonio e ciò che esegue, così la prossima vulnerabilità critica La trova con la risposta già pronta.
Tutti i contenuti di questa pagina provengono da fonti pubbliche aggiornate al 23 ottobre 2026, ad eccezione dei risultati della sezione 02, basati sui dati dei clienti Red Sift ASM fino al 26 ottobre 2026. Lo stato dello sfruttamento e i conteggi dell'esposizione cambiano di ora in ora; consulti gli avvisi primari prima di agire sulla base di un dato.