PHP2Shell (CVE-2026-109618 e CVE-2026-109619): cosa devono fare adesso le aziende che usano PHP

Un tecnico con un portatile al lavoro su un armadio rack di server

Il 21 ottobre 2026 il progetto PHP ha rilasciato PHP 8.5.12, 8.4.27, 8.3.36 e 8.2.35 per correggere due vulnerabilità che «possono consentire l'esecuzione di codice da remoto senza autenticazione». Detto in parole semplici: chiunque possa inviare una richiesta HTTP al vostro sito potrebbe riuscire a eseguire il proprio codice sul vostro server. Non gli serve alcuna password e, con alcune configurazioni, l'attacco funziona prima che la vostra applicazione abbia eseguito una sola riga. La coppia di falle è stata battezzata PHP2Shell, e PHP le valuta entrambe 9,2 (CVSS 4.0, su una scala da 10).

Questa guida è per chi deve intervenire: titolari di siti web e negozi online in PHP, responsabili IT e chiunque abbia un fornitore che gestisce PHP per suo conto. È stata scritta il 22 ottobre 2026, il giorno dopo il rilascio, sulla base degli avvisi del progetto PHP, delle indicazioni delle agenzie nazionali di sicurezza informatica e dei dati pubblicati dai vendor. Dove le fonti non concordano, lo diciamo.

In breve

Aggiornate PHP stesso, poi riavviatelo. Aggiornare WordPress, Drupal, Laravel o un plugin non risolve il problema. La falla è in PHP, sotto la vostra applicazione.
È coinvolta ogni installazione PHP che serve richieste web, secondo PHP: PHP-FPM, Apache con mod_php, php-cgi, FrankenPHP e LiteSpeed. PHP indica Apache con mod_php come la configurazione a rischio più alto.
Quasi la metà dei siti PHP gira su un ramo per cui il progetto PHP non pubblica più release (nostra lettura dei dati W3Techs, più sotto). Per questi non esiste un pacchetto ufficiale da installare.
Impostazioni e firewall fanno guadagnare tempo, non sicurezza. PHP elenca misure temporanee e dice che «non rendono sicura un'installazione».
Se oggi non potete applicare la patch, le agenzie di Stati Uniti, Regno Unito e UE danno lo stesso consiglio: togliete il sistema da internet finché non potrete farlo.

Cosa è successo, in ordine

19 agosto 2026. I ricercatori di Wiz trovano la prima delle falle, secondo la loro divulgazione, e le segnalano al team di sicurezza di PHP il 24 agosto. Gli avvisi di PHP citano anche ricercatori di diverse altre società.
20 ottobre. I numeri CVE trapelano online due giorni prima della divulgazione prevista. PHP anticipa il rilascio di un giorno, al 21 ottobre alle 14:00 UTC, e invita tutti a prepararsi.
21 ottobre, 03:02 UTC. Cloudflare attiva regole firewall per ogni cliente che usa il suo WAF, piano gratuito compreso. In seguito riferisce di aver «osservato traffico di attacco diretto contro i nostri clienti» e di aver visto gli attaccanti «modificare il payload dell'attacco per cercare di aggirare le nostre protezioni».
21 ottobre, intorno alle 14:00 UTC. PHP pubblica le correzioni e il suo avviso. Lo stesso giorno la CISA negli Stati Uniti, l'NCSC britannico, il CERT-EU e una dichiarazione congiunta della Commissione europea, dell'ENISA, del CERT-EU, di Europol e dei CSIRT nazionali dell'UE chiedono tutti alle organizzazioni di applicare le patch immediatamente.

Quanto è grave?

Tre elementi distinguono questo caso dalla solita patch mensile.

All'attaccante basta una richiesta. Nessun login, e nessuno deve cliccare su un link. L'avviso di PHP descrive un exploit dimostrato contro Apache con mod_php «in cui una richiesta non autenticata può avviare l'attacco prima che venga eseguito qualsiasi codice applicativo». Wiz ha dimostrato attacchi contro le versioni attuali di WordPress, Drupal e Joomla, e osserva che «anche una semplice applicazione “Hello World” in esecuzione su una versione di PHP interessata può essere vulnerabile». Il codice eseguito in questo modo ha i permessi dell'account del server web, che sulla maggior parte dei siti può leggere la configurazione dell'applicazione: la password del database, le chiavi API, le credenziali della posta e dei pagamenti. Per la seconda falla, CVE-2026-109619, PHP conferma anche una divulgazione di memoria: dati della memoria del server che finiscono all'esterno, anche senza un'esecuzione di codice completa.

La base installata è enorme. Secondo W3Techs, PHP è usato dal 69,3% dei siti web di cui è noto il linguaggio lato server (dati del 22 ottobre 2026). Unit 42 di Palo Alto Networks conta oltre 22,6 milioni di istanze esposte potenzialmente vulnerabili, sulla base delle proprie scansioni di internet, e riferisce che almeno un governo europeo ha messo offline il proprio sito web per precauzione.

Lo sviluppo degli exploit procede in fretta. Il CERT-EU riferisce che le prime proof of concept «hanno cominciato a circolare». La società di sicurezza watchTowr dice che i suoi honeypot registrano attività di sfruttamento dal 21 ottobre. Cloudflare riferisce traffico di attacco. E Wiz dice che i suoi ricercatori hanno usato modelli di IA in ogni fase, tanto che un solo ricercatore ha fatto in una settimana ciò che «avrebbe richiesto mesi a un team di livello mondiale». Gli attaccanti che adattano un exploit alla vostra versione di PHP hanno gli stessi strumenti.

Per onestà, sentiamo anche l'altra campana: quando la CISA ha pubblicato il suo avviso il 21 ottobre, non aveva osservato sfruttamenti, e nessuna delle due falle era ancora nel suo catalogo Known Exploited Vulnerabilities (le vulnerabilità sfruttate note). Red Hat classifica il problema «Important» (importante) anziché critico, perché un server Red Hat Enterprise Linux standard usa PHP-FPM, dove lo sfruttamento è più difficile. Più difficile non vuol dire impossibile: PHP conferma che una delle vie di attacco della seconda falla funziona anche su PHP-FPM. Niente di tutto questo cambia ciò che dovete fare. Cambia solo quanto preavviso avrete.

Che versione usate? I numeri

W3Techs pubblica anche quali versioni di PHP usano i siti web, contando i siti che rendono visibile la propria versione. Mettendo insieme le sue due tabelle del 22 ottobre 2026:

Ramo PHP	Quota dei siti PHP	Correzione dal progetto PHP
8.3, 8.4, 8.5	circa 34%	Sì: 8.3.36, 8.4.27, 8.5.12
8.2	circa 18%	Sì: 8.2.35. Ma il ramo 8.2 arriva a fine vita il 31 dicembre 2026
8.0, 8.1	circa 14%	Nessuna release. 8.0 e 8.1: solo backport del codice sorgente
7.x	26,9%	Nessuna release. 7.4: solo backport del codice sorgente; 7.3 e precedenti: niente
5.x e precedenti	7,8%	Niente

Quindi circa il 48% dei siti PHP gira su un ramo per cui il progetto PHP non pubblica alcuna release corretta, e un altro 18% riceve la correzione adesso e perde il supporto tra dieci settimane.

Due avvertenze. W3Techs vede solo i siti che mostrano la propria versione. E una distribuzione Linux può aver corretto da sé un ramo vecchio: Ubuntu l'ha fatto, come vedrete più sotto. Il numero di versione da solo non vi dice se siete protetti. La versione del pacchetto del vostro vendor sì.

Passo 1: censite ogni installazione PHP

Non potete correggere ciò che non avete censito, e PHP si nasconde bene. L'NCSC britannico chiede alle organizzazioni di trovare ogni sistema PHP, a partire da quelli esposti su internet, e aggiunge: «non limitate la ricerca alle versioni di PHP obsolete». La dichiarazione congiunta dell'UE avverte che alcuni prodotti «potrebbero essere interessati da queste vulnerabilità anche se non sembrano usare PHP direttamente».

Dove cercare:

Siti web e negozi online: WordPress e WooCommerce, Drupal, Joomla, Magento e Adobe Commerce, Shopware, PrestaShop, TYPO3, e qualsiasi cosa costruita su Laravel o Symfony.
Quelli dimenticati: microsite di campagne, una vecchia versione in un'altra lingua, server di staging e di test raggiungibili da internet, la webmail o l'helpdesk che qualcuno ha installato anni fa.
Container: ogni immagine costruita da un'immagine di base php contiene il proprio PHP. Aggiornare l'host non fa nulla per quell'immagine.
Pannelli di controllo dell'hosting: cPanel, Plesk e pannelli simili forniscono build di PHP proprie accanto a quella di sistema. Ogni versione abilitata nel pannello è una cosa a sé da aggiornare.
Prodotti con PHP all'interno: appliance, strumenti di monitoraggio, CRM, helpdesk e interfacce di amministrazione dei vendor. L'NCSC olandese tiene un elenco pubblico di questi prodotti con il loro stato, fornitore per fornitore.
Fornitori: il vostro provider di hosting, la vostra agenzia, qualsiasi servizio che sapete basato su PHP. Chiedete loro per iscritto quali versioni di PHP girano sui vostri sistemi e quando applicheranno le patch.

Per ciascuno annotate la versione di PHP, come gira PHP (mod_php, PHP-FPM, LiteSpeed, FrankenPHP, un container), se è raggiungibile da internet e chi è in grado di applicare la patch.

Passo 2: applicate le patch nell'ordine giusto

Iniziate da ciò che è raggiungibile da internet e, al suo interno, dalle configurazioni Apache con mod_php.

Su un ramo supportato (da 8.2 a 8.5). Aggiornate a 8.5.12, 8.4.27, 8.3.36 o 8.2.35, oppure al pacchetto della vostra distribuzione che contiene la correzione. PHP dice che le distribuzioni Linux hanno ricevuto le patch in anticipo. Confermati finora:

Ubuntu: pacchetti corretti per ogni release dalla 14.04 alla 26.10. Dalla 22.04 in poi arrivano con i normali aggiornamenti; sulla 20.04 e precedenti richiedono un abbonamento Ubuntu Pro, gratuito fino a cinque macchine (avviso di Canonical).
Debian: php8.4 8.4.27 per Debian 13 (DSA-6574-1) e php8.2 8.2.35 per Debian 12 (DLA-4848-1).
Red Hat Enterprise Linux: il bollettino di sicurezza di Red Hat RHSB-2026-013 elenca i pacchetti per ogni release.
Il repository Remi, molto usato per avere versioni più recenti di PHP sui sistemi della famiglia Red Hat: il 21 ottobre il CERT-EU ha rilevato che non aveva pacchetti pronti il giorno del rilascio e ha consigliato di passare ai pacchetti della distribuzione o di compilare dai sorgenti. Verificate se si è messo in pari prima di farci affidamento.

Su PHP 7.4, 8.0 o 8.1. Il progetto PHP non pubblica alcuna release per questi rami. Il suo team di sicurezza ha preparato backport minimi del codice sorgente per i tre rami, utili se compilate PHP da soli. Altrimenti la correzione deve arrivare dal vostro vendor (Ubuntu Pro copre PHP 7.4 su Ubuntu 20.04, per esempio) oppure dal passaggio a una versione più recente di PHP. Il consiglio della CISA per chi è su 8.1 o precedenti e non può aggiornare è netto: mettete offline il sistema finché non ha ricevuto la patch o non è stato portato a una versione più recente.

Su PHP 7.3 o precedenti. Dal progetto PHP non arriva nulla. A meno che un vendor non corregga ancora la vostra build, la scelta è tra il passaggio a una versione più recente e mettere offline il sistema.

Riavviate dopo l'aggiornamento. Installare un pacchetto non sostituisce il PHP già in esecuzione. L'avviso di Ubuntu lo dice chiaramente: l'applicazione «con ogni probabilità andrebbe riavviata». Riavviate PHP-FPM, Apache, LiteSpeed o il container su ogni server. Poi controllate la versione che il server web esegue davvero, non solo php -v da riga di comando, che può essere una build diversa.

Container: ricostruite le immagini da un'immagine di base aggiornata e rifatene il deploy. Un host aggiornato che esegue un'immagine vecchia resta esposto.

Hosting gestito: chiedete al vostro provider la data e la versione, poi verificate voi stessi.

Passo 3: se oggi non potete applicare la patch

L'avviso di PHP elenca misure temporanee e le introduce con un avvertimento: «riducono l'esposizione a specifici percorsi di attacco ma non rendono sicura un'installazione». In breve, per chi gestisce i vostri server:

Per CVE-2026-109618: impostate memory_limit=-1 in modo che l'applicazione non possa sovrascriverlo (per esempio con php_admin_value nel pool di PHP-FPM o nella configurazione di Apache); impostate un post_max_size basso (PHP suggerisce 8M senza upload di file, 32M con gli upload); limitate la dimensione delle richieste, il numero di campi e le parti multipart a livello di server web o di proxy; e usate un limite di memoria del container o del cgroup, mai RLIMIT_AS o RLIMIT_DATA.
Per CVE-2026-109619: impostate session.upload_progress.enabled=0 in php.ini o nella configurazione del server (non con ini_set() né con un file .user.ini) e riavviate ogni worker. Su PHP 8.5 impostate anche fatal_error_backtraces=0.

Due avvertenze. L'impostazione della sessione che si è diffusa ampiamente il 20 ottobre chiude soltanto percorsi della seconda falla, come ha fatto notare un membro del team di sicurezza di PHP; contro la prima non fa nulla. E memory_limit=-1 elimina il limite di memoria proprio di PHP, quindi ora una sola richiesta pesante può esaurire la memoria del server. Abbinatelo al limite del container o del cgroup.

Un web application firewall aiuta, ma poco. Le regole di Cloudflare sono attive per impostazione predefinita su ogni piano con il suo WAF, compreso quello gratuito, e Palo Alto Networks e altri vendor hanno pubblicato protezioni proprie. Cloudflare continua comunque a dire ai clienti di applicare le patch a PHP «anche con le protezioni WAF», e ha visto gli attaccanti modificare i payload per sfuggire alle sue regole. Un WAF inoltre protegge solo il traffico che passa da lì. Se il vostro server risponde sul proprio indirizzo IP, un attaccante può aggirarlo.

Se niente di tutto questo si può fare in fretta, la CISA, il CERT-EU, l'NCSC e la dichiarazione congiunta dell'UE vanno tutti nella stessa direzione: togliete il sistema dalla rete internet pubblica finché non è stato corretto. Una pagina di manutenzione per un giorno costa meno di un server da ricostruire.

Passo 4: verificate se siete già stati colpiti

La finestra si è aperta il 20 ottobre, quando è iniziata la fuga di notizie, e il traffico di attacco è stato segnalato la mattina dopo. Se un sistema era raggiungibile e senza patch in quella finestra, la patch chiude la porta ma non vi dice se qualcuno è entrato prima. L'NCSC chiede a chi non ha potuto applicare subito le patch di cercare segni di compromissione e backdoor.

Cosa cercare, in base alle indicazioni pubblicate e alla normale pratica di gestione degli incidenti:

Processi PHP che fanno cose che PHP non fa mai, come avviare una shell o scaricare strumenti (CISA).
Richieste multipart insolite seguite da errori sul limite di memoria o da risposte HTTP 500 ripetute, worker PHP che si riavviano senza un motivo chiaro, e cookie PHPSESSID insolitamente grandi o malformati nelle risposte (Wiz).
File PHP nuovi o modificati nelle cartelle di upload, nelle cartelle di cache o nella web root, nuovi account amministratore nel vostro CMS e attività pianificate che nessuno ha creato.

Log puliti non sono una prova. L'avviso di PHP sulla seconda falla mette in guardia proprio da questo, e Wiz osserva che i log applicativi potrebbero contenere poco contesto.

Se trovate qualcosa, trattatelo come un incidente, non come un lavoro di patching. Isolate il server, conservate le prove, coinvolgete una società di incident response e cambiate ogni segreto che il server web poteva leggere: password dei database, chiavi API, credenziali di pagamento e di posta, chiavi di firma. Poiché la seconda falla può divulgare il contenuto della memoria, valutate di ruotare i più sensibili di questi segreti su qualsiasi server rimasto esposto e senza patch per giorni, anche senza segni di intrusione.

Passo 5: cosa potreste dover segnalare

Una vulnerabilità in sé non è un incidente da segnalare. Una vulnerabilità sfruttata potrebbe esserlo.

NIS2: se la vostra organizzazione rientra nell'ambito e una compromissione costituisce un incidente significativo, il preallarme al vostro CSIRT nazionale va inviato entro 24 ore. Consultate la nostra guida alla NIS2.
GDPR: se c'è stato accesso a dati personali, la violazione va notificata all'autorità di controllo entro 72 ore dal momento in cui ne siete venuti a conoscenza, a meno che sia improbabile che presenti un rischio per le persone. Consultate la nostra guida al GDPR.
Cyber Resilience Act: se vendete software o un dispositivo con PHP all'interno, ne siete il fabbricante ai sensi del CRA. Dall'11 settembre 2026 i fabbricanti sono tenuti a segnalare le vulnerabilità attivamente sfruttate nei loro prodotti tramite la Piattaforma unica di segnalazione del CRA, come ricorda la dichiarazione congiunta dell'UE. Consultate la nostra guida al CRA.
I vostri clienti: se ospitate o gestite PHP per conto di clienti, ve lo chiederanno. Una breve nota scritta (cosa usate, quando avete applicato la patch, cosa avete controllato) risponde alla maggior parte di loro, ed è la stessa nota che vorranno vedere un auditor o una compagnia di assicurazione cyber.

Dopo l'emergenza: cosa cambiare

Sulla maggior parte dei server ben gestiti PHP2Shell verrà corretto nel giro di qualche giorno. Ciò che ha rivelato sulla vostra infrastruttura resterà vero anche dopo.

Sappiate quanto tempo vi serve per una patch. Dall'avviso a ogni server riavviato: ore, giorni o settimane? Se la risposta onesta è «dovremmo chiedere all'agenzia», sistemate la cosa prima della prossima falla. Quando i ricercatori dicono che l'IA ha ridotto il loro lavoro sugli exploit da mesi a una settimana, partite dal presupposto che anche gli attaccanti possano muoversi a quel ritmo.
Conservate l'inventario che avete appena costruito. È stata la parte più difficile della risposta, e diventa obsoleto nel momento in cui nessuno ne è responsabile.
Abbandonate le versioni di PHP a fine vita. Un sito su PHP 7.4 o 8.1 questa volta ha avuto bisogno di un vendor o di un backport del codice sorgente; la prossima volta potrebbe non esserci né l'uno né l'altro. PHP 8.2 arriva a fine vita il 31 dicembre 2026, quindi un sito che abbandona PHP 8.1 dovrebbe passare direttamente a PHP 8.3 o successivo. Cambiare versione di PHP spesso significa aggiornare anche l'applicazione: il nostro articolo sulla fine vita di Drupal, Umbraco e Kentico mostra cosa comporta per un CMS.
Preferite PHP-FPM a mod_php dove potete. Questa volta era la configurazione a rischio più basso.
Lasciate disattivato il tracciamento dell'avanzamento degli upload se non lo usate. L'avviso di PHP suggerisce di tenere session.upload_progress.enabled disattivato anche dopo la patch, quando l'applicazione non ne ha bisogno.
Mettete nei contratti i tempi delle patch. Chiedete al vostro provider di hosting e alla vostra agenzia in quanto tempo applicano le correzioni critiche di PHP, e fatevi dare la risposta per iscritto.

Una checklist per questa settimana

Censite ogni installazione PHP, compresi container, pannelli di controllo, prodotti dei vendor e server di staging.
Applicate le patch prima ai sistemi esposti su internet, a partire da Apache con mod_php.
Riavviate ogni processo PHP e controllate la versione indicata dal server web.
Ricostruite le immagini dei container e rifatene il deploy.
Dove oggi non potete applicare la patch, applicate le impostazioni temporanee indicate da PHP, fate passare il traffico da un WAF o mettete offline il sistema.
Chiedete per iscritto a fornitori e provider di hosting la loro versione di PHP e la data della patch.
Esaminate i log e le modifiche ai file su tutto ciò che è rimasto esposto e senza patch dal 20 ottobre.
Decidete se si applica un obbligo di segnalazione (NIS2, GDPR, CRA).
Pianificate l'abbandono di PHP 8.1 e precedenti, e di PHP 8.2 prima del 31 dicembre.

Dove possiamo aiutarvi

Alla maggior parte delle aziende non manca la volontà di applicare le patch. Manca un quadro chiaro di ciò che hanno in esercizio, o le persone per fare il lavoro questa settimana. È la parte di cui ci occupiamo noi:

Inventario e patch, nel giro di qualche giorno. Troviamo le vostre installazioni PHP su server, container, pannelli di hosting e fornitori, applichiamo le patch, riavviamo e verifichiamo, e vi lasciamo un resoconto scritto di cosa è stato fatto e quando. Quel resoconto è anche la vostra risposta a clienti e auditor.
Uscire dalle vecchie versioni di PHP. Applicazioni ferme su PHP 7.x, 8.0 o 8.1 perché il codice non gira su nulla di più recente: le portiamo a una versione supportata con il nostro servizio di manutenzione dei sistemi legacy.
Hardening e una routine di patch, così il prossimo avviso diventa un lavoro pianificato anziché un'emergenza.

Se trovate segni di un'intrusione, chiamate prima una società di incident response. Noi possiamo occuparci della ricostruzione e dell'aggiornamento al loro fianco.

Scrivete a office@c9group.dev indicando cosa usate, e vi risponderemo con ciò che faremmo per primo.

Fonti

Verificate il 22 ottobre 2026. La situazione è ancora in evoluzione: in particolare lo stato degli sfruttamenti e i pacchetti dei vendor potrebbero essere cambiati nel frattempo.

Progetto PHP

Agenzie

Ricercatori, vendor e dati