Un sito web può essere aggiornato, utilizzare password robuste e avere un’applicazione progettata con attenzione. Eppure può restare vulnerabile a causa di un componente meno visibile: il software che ne esegue il codice. È quanto accade con PHP2Shell, il nome dato a due gravi vulnerabilità di PHP, tecnologia utilizzata da molti portali, negozi online, servizi digitali e applicazioni aziendali.
Il 21 ottobre 2026 il progetto PHP ha pubblicato aggiornamenti straordinari per correggere CVE-2026-109618 e CVE-2026-109619, entrambe classificate come critiche, con punteggio CVSS v4.0 di 9,2 su 10. In particolari condizioni, le falle permettono di eseguire codice su un server a distanza, senza conoscere username o password. Il CERT-EU ha quindi invitato le organizzazioni ad aggiornare immediatamente i sistemi esposti.
Il caso porta però alla luce una novità che supera l’emergenza informatica: l’intelligenza artificiale ha aiutato i ricercatori a trasformare difetti del codice conosciuti da anni in attacchi concretamente dimostrabili. La stessa accelerazione può essere usata da chi cerca nuove falle nei server non aggiornati. La questione riguarda perciò anche le risorse dell’open source, l’organizzazione delle correzioni e la capacità dei fornitori di distribuire tempestivamente le patch.
Il punto da comprendere è che la vulnerabilità non nasce necessariamente dal sito o da un suo plugin. Si trova nel motore PHP, che elabora le richieste e fa funzionare l’applicazione. Di conseguenza, controllare soltanto gli aggiornamenti di WordPress, Drupal, Joomla o di un gestionale può non essere sufficiente.
Indice degli argomenti
Che cosa succede, in parole semplici
Quando un utente visita una pagina o invia un modulo, il server utilizza memoria per elaborare la richiesta. Al termine, quella memoria deve essere gestita e liberata correttamente. Le due vulnerabilità riguardano proprio situazioni in cui questo meccanismo si interrompe o conserva informazioni che non dovrebbero più essere utilizzate.
La CVE-2026-109618 riguarda la gestione degli errori di memoria. Se PHP esaurisce il limite assegnato mentre sta preparando alcuni dati, può interrompersi prima che le strutture interne siano pronte. Durante la successiva fase di pulizia, il programma può trattare informazioni non valide come se fossero corrette. In determinate circostanze, un attaccante riesce a sfruttare questa condizione per eseguire codice malevolo.
La CVE-2026-109619 nasce invece dalla permanenza di riferimenti a memoria già liberata. Una richiesta successiva, elaborata dallo stesso processo, può riutilizzare quei riferimenti non più validi. Anche questo errore può provocare una compromissione, attraverso specifiche sequenze di operazioni.
Non è necessario conoscere tutti i dettagli della gestione della memoria per capirne la portata: un errore interno al linguaggio può trasformare una normale richiesta web in un possibile punto d’ingresso per un attacco. Le due falle hanno caratteristiche diverse e non devono necessariamente essere sfruttate insieme.
PHP2Shell e intelligenza artificiale: che cosa ha cambiato l’AI
PHP2Shell racconta anche come stia cambiando la ricerca sulla sicurezza informatica. La PHP Foundation spiega che i primi segnali del problema di gestione della memoria erano stati individuati nel 2024, durante le attività successive a un controllo del codice svolto da Quarkslab. Allora non era stata dimostrata una modalità concreta di attacco con lo stesso impatto emerso in seguito.
Nel 2024 gli sviluppatori avevano intuito un possibile percorso di sfruttamento, ma mancavano dimostrazioni pratiche. I manutentori avevano valutato diverse correzioni, ciascuna con costi potenziali in termini di compatibilità, prestazioni o interventi sulle estensioni. La PHP Foundation riconosce che la scarsità di specialisti e un processo decisionale troppo lento avevano bloccato più volte il lavoro, lasciando aperto un problema destinato a rivelarsi molto più grave.
Da GPT-5.6 Sol a Gemini 4 Argon: chi ha trovato cosa
Nel 2026 le segnalazioni di Calif, OpenAI e Wiz Research hanno contribuito a chiarire la gravità delle vulnerabilità e a verificare possibili modalità di sfruttamento. In questo lavoro sono stati utilizzati anche strumenti di intelligenza artificiale: Google Cloud, per esempio, ha descritto il contributo di Gemini 4 Argon all’analisi delle falle, alla ricerca degli attacchi e alla verifica delle correzioni.
La ricostruzione di OpenAI indica che Calif ha individuato una falla critica con l’aiuto di GPT-5.6 Sol nell’ambito di Patch the Planet. Secondo la PHP Foundation, l’audit di Calif era iniziato il 30 luglio e l’11 agosto Ryan A aveva segnalato un attacco capace di eseguire codice da remoto; lo stesso giorno era arrivata un’analisi indipendente da OpenAI, seguita da ulteriori contributi di Wiz il 24 agosto e di OpenAI il 18 settembre.
Il gruppo Wiz Research ha utilizzato Wiz Atlas, Gemini 4 Argon e GPT-5.6 Sol nell’analisi, nello sviluppo e nell’adattamento degli exploit, nella ricerca di varianti e nella verifica delle patch. I modelli hanno affiancato il lavoro di test e debugging: seguire la gestione della memoria, provare ipotesi diverse, confrontare configurazioni e verificare se gli errori fossero riproducibili in applicazioni reali.
La complessità tecnica offre meno protezione agli attaccanti
Il passaggio decisivo riguarda la praticabilità dell’attacco. Manipolare errori di memoria richiede normalmente competenze elevate e adattamenti laboriosi alle versioni del software e alla configurazione del server. Wiz riferisce che gli strumenti AI hanno reso possibile sviluppare e adattare dimostrazioni funzionanti su applicazioni diverse nell’arco di ore. Per i difensori significa individuare prima falle difficili; per gli aggressori significa poter ridurre costi e tempi di ricerca, una volta disponibili le stesse capacità.
La ricerca resta un’attività di équipe: gli esperti impostano i test, verificano gli effetti e prendono le decisioni sulle correzioni. Tuttavia cambia la soglia economica e tecnica dello sfruttamento: errori considerati improbabili da trasformare in un attacco possono diventare rilevanti per sistemi che ospitano migliaia di servizi distinti.
Chi è esposto e quali possono essere le conseguenze
Il problema può interessare le installazioni PHP che rispondono a richieste web, comprese quelle basate su Apache con mod_php, PHP-FPM e altre modalità di esecuzione. Il rischio concreto varia però in base alla versione installata, alla configurazione del server e alle condizioni necessarie per sfruttare ciascuna vulnerabilità.
La diffusione di PHP spiega perché la vicenda supera il singolo sito. Secondo W3Techs, al 21 ottobre 2026 PHP è impiegato dal 69,3% dei siti di cui si conosce il linguaggio lato server. La quota misura l’utilizzo della tecnologia e non indica quanti siti siano vulnerabili o compromessi; la percentuale varia anche in base alla popolarità dei siti osservati.
Il PHP Security Team segnala come particolarmente critica la configurazione Apache con mod_php: i ricercatori hanno dimostrato che, in uno degli scenari, una sola richiesta non autenticata può attivare l’attacco prima ancora che venga eseguito il codice dell’applicazione. Sono state documentate anche dimostrazioni su installazioni di WordPress, Drupal e Joomla. Questo non significa che tutti i siti realizzati con queste piattaforme siano compromessi: la presenza della falla e la sua sfruttabilità vanno verificate caso per caso.
Un attacco riuscito può permettere di eseguire istruzioni con i privilegi del processo PHP e, a seconda dell’ambiente, esporre dati, alterare contenuti o interrompere i servizi. Alcune delle tecniche descritte dai ricercatori permettono anche di accedere a porzioni della memoria del processo, dove potrebbero trovarsi informazioni riservate come token e credenziali. Le conseguenze non sono identiche per tutti: dipendono dai controlli presenti sul server e dall’accesso ai dati consentito al processo compromesso.
Ci sono già attacchi in corso?
Secondo Amazon Threat Intelligence, un tentativo di sfruttamento di PHP2Shell risale al 17 ottobre 2026, quattro giorni prima della divulgazione pubblica. I sensori MadPot hanno poi registrato nuovi tentativi il 21 ottobre, mentre Cloudflare ha osservato traffico ostile e modifiche delle richieste per aggirare le contromisure. Le rilevazioni dimostrano attività di attacco e circolazione di strumenti di sfruttamento; da sole non permettono di quantificare i server realmente compromessi.
Le versioni PHP da aggiornare
Secondo le analisi pubblicate da Google Cloud e Wiz, almeno una delle vulnerabilità interessa versioni risalenti fino a PHP 5.4. Non tutti i rami presentano necessariamente gli stessi percorsi di attacco. Per le versioni supportate, il progetto PHP ha rilasciato le seguenti correzioni il 21 ottobre 2026:
Versioni PHP corrette il 21 ottobre 2026
| Versione utilizzata | Prima versione corretta |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
Fonte: PHP Security Team, 21 ottobre 2026.
Per PHP 8.1 e versioni precedenti non sono previsti nuovi rilasci ordinari da parte del progetto PHP. Alcuni fornitori di distribuzioni Linux e servizi di supporto a lungo termine possono tuttavia fornire pacchetti corretti anche per versioni meno recenti. Il PHP Security Team ha inoltre messo a disposizione interventi minimi sul codice sorgente per PHP 7.4, 8.0 e 8.1: non si tratta, però, del ripristino del supporto regolare.
È quindi importante verificare gli aggiornamenti del proprio fornitore o pianificare la migrazione a una versione supportata. Va ricordato che PHP 8.2 terminerà il supporto alla sicurezza il 31 dicembre 2026.
Che cosa devono fare le organizzazioni
Partire da un inventario affidabile. La prima domanda è semplice: dove utilizziamo PHP? Non soltanto nel sito pubblico, ma anche in portali interni, applicazioni sviluppate su misura, servizi di hosting, sistemi forniti da terzi e immagini software utilizzate nei container. Conta la versione effettivamente eseguita dal servizio web, che può essere diversa da quella mostrata dagli strumenti a riga di comando.
Installare le correzioni e verificare il risultato. Occorre applicare le versioni aggiornate oppure i pacchetti corretti del fornitore, riavviare o sostituire i processi interessati e accertarsi che il servizio in funzione utilizzi davvero PHP corretto. Nel caso di un ambiente complesso bisogna verificare più elementi: il server che ospita il sito, le eventuali copie dell’applicazione e le immagini utilizzate per distribuire gli aggiornamenti. Quando la gestione è affidata a un fornitore esterno, è opportuno chiedere una conferma esplicita dell’intervento sulle due CVE. La sola disponibilità di un aggiornamento non prova che sia stato installato.
Non dare per scontato che il cloud aggiorni tutto. L’approfondimento di Google Cloud chiarisce che alcuni servizi gestiti ricevono automaticamente le nuove immagini di base, mentre altre configurazioni richiedono un intervento del cliente. Chi usa container personalizzati, per esempio, può dover ricostruire le immagini con PHP aggiornato e distribuire nuovamente l’applicazione. Essere nel cloud non equivale a essere automaticamente protetti: occorre sapere chi aggiorna ciascun componente e con quali modalità.
Ridurre l’esposizione se non si può aggiornare subito. CERT-EU consiglia di valutare l’isolamento dalla rete pubblica dei servizi vulnerabili fino alla correzione. Dove questo non è possibile, possono aiutare limiti sulle dimensioni delle richieste e degli upload, filtri sul traffico e alcune impostazioni temporanee documentate dal PHP Security Team. Configurazioni come memory_limit=-1 o la disattivazione di determinate funzioni PHP richiedono però una valutazione tecnica: possono ridurre specifici percorsi di attacco, ma introdurre altri problemi operativi o lasciare aperte ulteriori varianti. Solo l’aggiornamento rappresenta la soluzione completa.
Usare il firewall web senza considerarlo infallibile. Un Web Application Firewall (WAF) analizza le richieste dirette a un’applicazione e può bloccare comportamenti sospetti. Cloudflare e Google Cloud hanno annunciato protezioni specifiche per PHP2Shell. Google sottolinea tuttavia un limite importante: richieste molto grandi possono superare la quantità di dati che un WAF è configurato a ispezionare. Le regole vanno quindi accompagnate da controlli sulle dimensioni delle richieste e provate, quando possibile, in modalità di osservazione prima di attivare blocchi che potrebbero coinvolgere utenti legittimi.
Controllare se qualcuno abbia già tentato un attacco. Dopo l’aggiornamento è opportuno esaminare i segnali raccolti nel periodo di esposizione: richieste insolite, errori ripetuti di memoria, numerose risposte HTTP 500, arresti inattesi dei processi e attività non giustificate. Questi indizi non dimostrano da soli una compromissione, ma aiutano gli specialisti a capire dove indagare. Google Cloud ha riferito anche l’introduzione di 23 nuove regole di rilevamento nel pacchetto Mandiant Frontline Threats: un esempio di come la difesa richieda sia aggiornamenti sia monitoraggio. Se emergono segnali concreti di intrusione, servono verifiche sui sistemi e, quando necessario, la sostituzione di credenziali e chiavi potenzialmente esposte. L’aggiornamento elimina le falle note, ma non cancella automaticamente le conseguenze di un attacco già riuscito: in quel caso occorre conservare le evidenze, verificare eventuali modifiche non autorizzate e ripristinare l’ambiente in condizioni di sicurezza.
Anche i fornitori fanno parte della risposta
Per molte organizzazioni il problema non si risolve semplicemente chiedendo al reparto informatico di aggiornare il sito. I servizi digitali dipendono spesso da società di hosting, sviluppatori esterni, gestori di piattaforme e fornitori cloud. A ciascuno possono spettare attività differenti: aggiornare il sistema operativo, sostituire il motore PHP, pubblicare una nuova versione dell’applicazione o verificare che il servizio sia tornato operativo.
Per questo è importante sapere chi è responsabile di ogni componente e come viene comunicata l’avvenuta correzione. Un’azienda, uno studio professionale o un ente pubblico non devono necessariamente svolgere direttamente tutti gli interventi, ma devono essere in grado di sapere se i servizi utilizzati sono ancora esposti. È uno dei motivi per cui l’inventario dei software e la gestione delle dipendenze non sono soltanto questioni tecniche: incidono sulla continuità delle attività e sulla protezione dei dati.
La lezione sistemica: il software condiviso è un’infrastruttura critica
L’open source ha bisogno di risorse, oltre che di segnalazioni
La PHP Foundation ammette apertamente un problema di governance: mentre le segnalazioni si accumulavano, pochi sviluppatori con conoscenza profonda del motore PHP dovevano valutare correzioni complesse, con il rischio di introdurre nuove incompatibilità o disservizi. Nel maggio 2026 è stato creato un Ecosystem Security Team per triage, coordinamento e rafforzamento del codice, affiancato dal lavoro di volontari e specialisti finanziati.
La capacità dell’AI di scoprire nuove falle aumenta anche il carico di verifica. In un bilancio pubblicato il 14 ottobre la squadra di sicurezza di PHP riferiva di aver pubblicato 15 CVE dal 1° luglio e chiuso 106 segnalazioni giudicate non riproducibili, duplicate o estranee alla categoria delle vulnerabilità. Ogni dossier richiede comunque un controllo umano: la quantità di segnalazioni cresce più velocemente delle risorse che possono valutarle e trasformarle in patch affidabili.
L’audit esterno del 2024 era stato finanziato dalla tedesca Sovereign Tech Agency e realizzato attraverso OSTIF e Quarkslab. Il denaro pubblico ha contribuito a scoprire un rischio in una componente su cui si reggono anche servizi pubblici. La PHP Foundation chiede ora a imprese, gestori di hosting e istituzioni contributi stabili alla manutenzione, perché una tecnologia gratuita per gli utilizzatori può avere costi elevati per chi deve metterla in sicurezza.
La divulgazione coordinata sotto pressione
La gestione del segreto sulle vulnerabilità è diventata un’altra questione di sistema. La ricostruzione della PHP Foundation racconta che una fuga di informazioni del 20 ottobre spinse ad anticipare l’avviso e le patch dal 22 al 21 ottobre. Una dimostrazione video pubblicata per errore e la diffusione anticipata di immagini software già corrette resero più difficile controllare ciò che gli aggressori potevano apprendere prima della divulgazione ufficiale.
L’obiettivo resta dare ai difensori il tempo di correggere senza offrire agli attaccanti informazioni utilizzabili. Ma quando modelli avanzati possono analizzare rapidamente una patch e adattare codice d’attacco, il margine di sicurezza si restringe. In questo contesto diventano decisivi avvisi mirati ai gestori delle infrastrutture essenziali, pacchetti corretti pronti alla pubblicazione e interventi coordinati tra manutentori, cloud provider, distribuzioni Linux e organismi pubblici.
Chi governa le capacità di ricerca cyber dell’AI
OpenAI propone con Patch the Planet un modello di risposta che combina ricerca assistita dall’AI, verifica degli exploit, avvisi anticipati ai fornitori e collaborazione con le autorità. La società lo presenta come una Defender’s Window, un vantaggio temporaneo per preparare le difese. Le osservazioni di Amazon su tentativi di attacco anteriori alla divulgazione rendono però evidente quanto sia difficile stabilire chi abbia scoperto per primo una vulnerabilità e quanto a lungo duri il vantaggio difensivo. Le evidenze pubbliche non attribuiscono quei tentativi all’uso di modelli AI.
Si apre anche un dilemma di accesso e responsabilità: limitare le funzioni più offensive dei modelli può ridurre gli abusi, ma può ostacolare la ricerca di chi difende software ampiamente diffuso. Per progetti open source e autorità pubbliche il problema diventa disporre di strumenti adeguati, processi di divulgazione affidabili e risorse per trasformare le scoperte in aggiornamenti effettivamente installati.
La lezione di PHP2Shell
Per la sicurezza dei servizi pubblici questa esperienza aggiunge un compito preciso: conoscere non soltanto gli asset esposti, ma anche chi può correggere ciascuna dipendenza critica e in quanto tempo. Le verifiche su contratti, inventari software, componenti open source e servizi gestiti diventano parte della continuità operativa, insieme alle procedure di risposta agli incidenti.
Per aziende, Pubbliche Amministrazioni, strutture sanitarie e studi professionali, il messaggio è chiaro: non basta mantenere aggiornato ciò che si vede sullo schermo. Bisogna conoscere anche i componenti che fanno funzionare un servizio digitale, sapere chi li gestisce e verificare che le correzioni arrivino davvero sui sistemi in uso.
PHP2Shell dimostra quanto una falla in una tecnologia di base possa avere effetti ben oltre il singolo sito. Inventario, aggiornamenti tempestivi, verifica delle patch e monitoraggio non sono attività separate: insieme permettono di ridurre il rischio e proteggere la continuità dei servizi.
Fonti e riferimenti
Fonti primarie e pubblicazioni tecniche consultate al 22 ottobre 2026.
1. CERT-EU — Security Advisory 2026-018 (21 ottobre 2026)
2. PHP Security Team — Avviso e misure correttive (21 ottobre 2026)
3. PHP Security Team — CVE-2026-109618, advisory tecnico
4. PHP Security Team — CVE-2026-109619, advisory tecnico
5. PHP Foundation — Ricostruzione delle scoperte e delle correzioni
6. Google Cloud — Indicazioni su cloud, WAF e monitoraggio (21 ottobre 2026)
7. Wiz Research — Analisi tecnica PHP2Shell (21 ottobre 2026)
8. Cloudflare — Traffico osservato e protezioni WAF (21 ottobre 2026)
9. NCSC-NL — Repository informativo PHP2Shell
10. PHP Project — Calendario del supporto delle versioni
11. Amazon Threat Intelligence — osservazioni sull’attività di sfruttamento del 17 ottobre (21 ottobre 2026)
12. OpenAI — Patch the Planet, divulgazione coordinata e strumenti AI (21 ottobre 2026)
13. PHP Foundation — Come vengono gestite le segnalazioni di sicurezza (14 ottobre 2026)
14. W3Techs — utilizzo di PHP per fascia di popolarità (21 ottobre 2026)
Partecipa alla community