Il 21 ottobre 2026 la PHP Foundation ha pubblicato due aggiornamenti straordinari per risolvere le vulnerabilità identificate con i codici CVE-2026-109618 e CVE-2026-109619. Entrambe hanno ricevuto un punteggio CVSS v4.0 di 9,2 su 10, collocandole nella categoria critica. In condizioni particolari, le falle consentono l’esecuzione di codice da remoto senza alcuna autenticazione, rendendo necessario l’intervento immediato consigliato dal CERT-EU.
Patch rilasciate il 21 ottobre 2026 per le versioni più diffuse
Il team di sicurezza di PHP ha corretto le falle in tutte le versioni attivamente supportate: 8.5, 8.4, 8.3, 8.2 e 8.1. Le tabelle di aggiornamento mostrano le versioni precedenti e quelle corrette, ad esempio PHP 8.5 è stato aggiornato alla versione 8.5.12, PHP 8.4 alla 8.4.27, e così via. Per le versioni 7.4, 8.0 e 8.1 sono disponibili solo interventi minori sul codice sorgente, poiché non è previsto un nuovo rilascio regolare.
Versioni interessate e percorso di migrazione
Le vulnerabilità riguardano anche PHP 5.4 e successive, ma le modalità di sfruttamento cambiano a seconda del ramo. Le organizzazioni dovrebbero verificare la versione effettiva in esecuzione, poiché può differire da quella mostrata dai tool di linea di comando. Se si utilizza una distribuzione Linux con supporto a lungo termine, è consigliabile controllare i repository del fornitore per eventuali pacchetti corretti.
Intelligenza artificiale al centro della scoperta
Nel 2024, Quarkslab aveva segnalato anomalie nella gestione della memoria di PHP, ma non era riuscito a dimostrare un vettore di attacco praticabile. Solo nel 2026, grazie a modelli come GPT-5.6 Sol, Gemini 4 Argon e Wiz Atlas, è stato possibile ricostruire exploit funzionanti. Calif ha avviato il proprio audit il 30 luglio, identificando una potenziale esecuzione remota il 11 agosto; la stessa giornata ha visto un’analisi indipendente di OpenAI, seguita da contributi di Wiz Research il 24 agosto e da OpenAI il 18 settembre.
Gli strumenti AI hanno accelerato il processo di testing, permettendo la generazione di prove di concetto in poche ore anziché settimane. Questo abbassa la soglia economica e tecnica per gli attaccanti, ma al contempo fornisce ai difensori un’opportunità di individuare vulnerabilità “difficili” prima che vengano sfruttate.
Impatto reale su siti e sistemi
Secondo W3Techs, al 21 ottobre 2026 il 69,3 % dei siti di cui è noto il linguaggio lato server utilizza PHP. La percentuale non indica quante installazioni siano vulnerabili, ma evidenzia l’ampiezza della superficie d’attacco. I ricercatori hanno dimostrato che, su configurazioni Apache con mod_php, una singola richiesta non autenticata può attivare l’exploit prima ancora che l’applicazione inizi a processare il codice.
Le conseguenze di un attacco riuscito includono l’esecuzione di comandi con i privilegi del processo PHP, il furto di token e credenziali residenti nella memoria, la modifica non autorizzata di contenuti e l’interruzione del servizio. Amazon Threat Intelligence ha rilevato un tentativo di sfruttamento il 17 ottobre 2026, quattro giorni prima della divulgazione pubblica, e i sensori MadPot hanno registrato ulteriori tentativi il 21 ottobre. Cloudflare segnala traffico anomalo mirato a bypassare le difese.
Azioni consigliate alle organizzazioni
Il primo passo è stilare un inventario preciso di tutti i punti in cui PHP è impiegato: siti web pubblici, portali intranet, micro-servizi, container Docker e ambienti gestiti da provider terzi. Una volta identificati, occorre installare le versioni corrette o i pacchetti di patch forniti dal distributore, riavviare i processi interessati e verificare che il runtime riporti la versione aggiornata.
Per le infrastrutture cloud, è fondamentale distinguere tra servizi che ricevono aggiornamenti automatici e quelli che richiedono interventi manuali, come le immagini personalizzate. Qualora l’aggiornamento non fosse immediatamente possibile, si consiglia di isolare temporaneamente i sistemi dalla rete pubblica, limitare la dimensione delle richieste e applicare regole WAF specifiche – tenendo presente che i WAF non possono ispezionare richieste estremamente grandi.
Infine, è opportuno analizzare i log degli ultimi giorni alla ricerca di segnali di compromissione: errori di memoria, risposte HTTP 500 ricorrenti, arresti improvvisi dei processi PHP. Eventuali indizi di intrusione richiedono una risposta forense completa, con rotazione di credenziali e verifica dell’integrità dei file.
