PHP ha rilasciato le versioni 8.5.12, 8.4.27, 8.3.36 e 8.2.35 il 21 ottobre per risolvere CVE-2026-109618 e CVE-2026-109619, due vulnerabilità con punteggio 9,2 su 10 che consentono l'esecuzione di codice remoto senza autenticazione.

Le vulnerabilità hanno spinto Finlandia, Paesi Bassi e Francia a portare offline i siti governativi per precauzione dopo che i dettagli erano emersi in anticipo. Cloudflare ha inoltre segnalato attacchi diverse ore prima del rilascio della patch. La National Security Agency statunitense ha raccomandato alle organizzazioni che utilizzano PHP di chiudere i propri siti, mentre agenzie in Australia, Giappone e Regno Unito hanno emesso indicazioni simili.

La maggior parte degli utenti internet non deve installare nulla. La responsabilità di applicare la correzione ricade sui gestori dei siti web, sulle società di hosting e sulle organizzazioni che mantengono server PHP. PHP 8.1 e versioni precedenti non ricevono rilasci ufficiali regolari, sebbene il team di sicurezza di PHP abbia pubblicato patch limitate al codice sorgente per alcune versioni precedenti a causa della gravità del problema.

PHP alimenta circa il 70% dei siti web il cui linguaggio lato server è noto, secondo W3Techs. Il linguaggio di programmazione opera sui server, dove contribuisce a memorizzare i siti web e a generare le pagine richieste dai visitatori. I siti WordPress, ad esempio, si affidano comunemente a server PHP, secondo la società di sicurezza WordPress Wordfence.

I due bug possono consentire a un attaccante di eseguire comandi su un server PHP senza effettuare l'accesso. Questo tipo di vulnerabilità è noto come remote code execution senza autenticazione. A seconda del server e dei dati che memorizza, un attacco riuscito potrebbe esporre informazioni sugli account, indirizzi, cronologie degli ordini o altro materiale sensibile.

Il provider di hosting GoDaddy ha avvertito che le vulnerabilità potrebbero permettere agli attaccanti di rubare dati, vandalizzare siti web o prendere il controllo completo dei server interessati.

"Una vulnerabilità di questo tipo potrebbe consentire a un attaccante di eseguire il proprio codice su un server interessato tramite internet, con conseguenti furti di dati, siti vandalizzati o una presa di controllo completa", ha dichiarato GoDaddy nel proprioaggiornamento di sicurezza]().

L'annuncio di sicurezza di PHP

La PHP Foundation, l'organizzazione no profit che finanzia lo sviluppo del linguaggio, ha emesso un avviso anticipato il 20 ottobre. In una dichiarazione condivisa su X, ha dichiarato:

"The PHP security team is giving advance notice: Upcoming security release Wed, Oct 21st 2026, 14:00UTC, two critical vulnerabilities, both rated CVSSv4 9.2. PHP users are encouraged to prepare to update. Earlier release if details become public or active exploit evidence."

The PHP security team is giving advance notice: Upcoming security release Wed, Oct 21st 2026, 14:00UTC, two critical vulnerabilities, both rated CVSSv4 9.2. PHP users are encouraged to prepare to update. Earlier release if details become public or active exploit evidence. — The PHP Foundation (@ThePHPF) October 20, 2026

Il Common Vulnerability Scoring System, o CVSS, valuta le vulnerabilità da 0 a 10 in base a fattori tra cui la facilità di sfruttamento tramite internet e l'impatto potenziale. Punteggi di 9,0 o superiori sono classificati come critici.

PHP ha rilasciato la correzione alle 13:35 UTC circa del 21 ottobre, circa 25 minuti prima dell'orario annunciato. L'avviso di sicurezza recita: "All PHP users are strongly encouraged to update immediately." Il rilascio è stato anticipato di un giorno dopo che le informazioni sulle vulnerabilità avevano iniziato a circolare pubblicamente ed erano emerse prove di attacchi.

Come funzionano le vulnerabilità

CVE-2026-109618 si verifica quando PHP esaurisce la memoria durante l'elaborazione di una richiesta e successivamente tratta i dati parzialmente costruiti come completi. CVE-2026-109619 consente ai residui della richiesta di un visitatore di rimanere in memoria anche dopo che avrebbero dovuto essere eliminati, permettendo a una richiesta successiva di interagire con tali residui.

Il rischio è massimo sui server che utilizzano mod_php, una configurazione Apache comune. PHP ha dichiarato che un exploit dimostrato funziona "prima che venga eseguito qualsiasi codice applicativo", il che significa che le difese implementate dal sito web stesso—come le schermate di accesso e i plugin di sicurezza WordPress—potrebbero non avere modo di intervenire.

I ricercatori della PHP Foundation hanno identificato la funzione upload-progress di PHP come uno dei percorsi confermati verso la vulnerabilità. La funzione traccia l'avanzamento del caricamento di un file, è attivata per impostazione predefinita da oltre un decennio e non è utilizzata da molti siti web.

Ulteriori informazioni tecniche sono disponibili nell'archivio di sicurezza PHP, nell'analisi di watchTowr e nella voce NVD per CVE-2026-109619. La documentazione di PHP descrive anche la pertinente configurazione delle sessioni.

Dettagli trapelati prima della patch

Inizialmente non era previsto che la divulgazione avvenisse prima del rilascio programmato. Martedì, un utente ha pubblicato sul forum Hacker News che due vulnerabilità PHP sarebbero state divulgate giovedì, riconoscendo che l'affermazione non aveva "no evidence beyond 'source: trust me, bro.'" Il post è disponibile qui.

La società di sicurezza watchTowr ha successivamente confermato che le vulnerabilità erano reali e coperte da un embargo, un accordo volto a mantenere riservati i dettagli tecnici fino a quando la correzione non fosse stata pronta. PHP ha quindi accelerato il rilascio.

Il CTO di Cloudflare Dane Knecht ha dichiarato su X mercoledì mattina presto che gli attacchi erano già iniziati, quasi sei ore prima del rilascio della patch.flare ha distribuito regole firewall per applicazioni web di emergenza ai propri clienti, inclusi quelli con piani gratuiti, ma Knecht ha descritto le regole come una misura solo temporanea.

"PHP sites behind Cloudflare already have an initial set of WAF rules deployed for the known exploit vectors in these vulnerabilities. The rules are available to all customers, including free. We are seeing early attacks emerging and are updating mitigations as new vectors show… — Dane Knecht 🦭 (@dok2001) October 21, 2026"

Il post originale è disponibile anche dall'account X di Dane Knecht.

I governi portano offline i siti web

Il centro IT statale finlandese, Valtori, ha iniziato a portare offline i servizi web pubblici per precauzione, secondo l'emittente pubblica Yle. Anche l'agenzia nazionale per la sicurezza informatica dei Paesi Bassi ha chiuso il proprio sito web.

Il Ministero dell'Interno francese ha dichiarato che i siti delle prefetture erano stati "temporaneamente portati offline in attesa del rilascio di una patch di sicurezza da parte del produttore del framework".

Il team di emergenza per la cibersicurezza dell'Unione Europea, CERT-EU, ha detto alle organizzazioni che non potevano applicare la patch di "considerare l'isolamento delle applicazioni esposte a internet dalle reti pubbliche finché non è disponibile una correzione".

Reuters ha riferito che agenzie in Australia, Giappone e Regno Unito hanno emesso indicazioni simili. Il rapporto di Reuters ha anche dichiarato che i siti web avrebbero potuto dover essere portati offline mentre i gestori si preparavano a installare le correzioni.

Affermazioni sulle versioni PHP interessate

Post in circolazione su X affermavano che versioni PHP risalenti fino al 2004 fossero vulnerabili. Quell'affermazione derivava da stime iniziali secondo cui tutte le versioni da PHP 5 in poi fossero interessate, una valutazione che, come ammesso da CERT-EU, si basava su post sui social media.

La società di sicurezza per l'e-commerce Sansec ha stimato che fossero interessate PHP 5.4 e versioni successive, il che estenderebbe l'intervallo al 2012 anziché al 2004. PHP fornisce ufficialmente rilasci attuali solo per le versioni 8.2 e successive. Tuttavia, a causa della gravità di queste vulnerabilità, il team di sicurezza ha pubblicato anche patch basilari al codice sorgente per PHP 7.4, 8.0 e 8.1, mentre le distribuzioni Linux hanno iniziato a effettuare il backport delle correzioni in autonomia.

La società di sicurezza Mallory ha conteggiato circa 884.000 host esposti a internet che dichiaravano PHP 8.1 o versioni precedenti il 20 ottobre. Ciò rappresentava il 59% dei circa 1,5 milioni di host visibili pubblicamente che identificavano la propria versione PHP. Il numero di siti web interessati è più alto, perché un singolo server di hosting condiviso può ospitare molti siti. La ricerca di Mallory è disponibile qui, mentre l'analisi di Sansec è disponibile qui.

Alcuni post online includevano anche Node.js nella discussione. Node.js è una tecnologia web separata che per caso aveva programmato per lo stesso giorno un proprio aggiornamento di sicurezza non correlato.

La PHP Foundation ha avvertito che le versioni patchate non sarebbero diventate disponibili ovunque allo stesso tempo. Ha dichiarato: "If you rely on the volunteer maintained we urge you to move to distro packages or building from source now, so you can immediately apply updates. The repo will not have updates today", riferendosi a una fonte di pacchetti PHP gestita da volontari per server Linux in stile Red Hat. Il repository di pacetti è disponibile su

Potenziale impatto su siti web e asset digitali

Un sito web compromesso non ha bisogno di interagire direttamente con una blockchain per mettere a rischio gli asset digitali degli utenti. Nel 2024, gli attaccanti hanno reindirizzato le interfacce front-end dei protocolli DeFi Compound e Celer verso pagine progettate per svuotare i wallet collegati. Curve Finance ha subito un attacco simile nel 2025. Quegli incidenti riguardavano DNS hijacking anziché vulnerabilità PHP, ma il risultato può apparire simile a un visitatore: il sito web e l'URL sembrano legittimi mentre un'azione di approvazione invia i token altrove.

Un server PHP compromesso potrebbe essere utilizzato per servire una pagina fraudolenta di quel tipo. Il rapporto tra infrastruttura web vulnerabile e furto di criptovalute è stato discusso anche dall'imprenditore @levelsio, che ha dichiarato su X di aver disconnesso i propri siti e server privati virtuali in attesa della patch.

"I pre-emptively disconnected ALL my sites / VPS servers from the web I'll wait for the patch to hit at 2 PM UTC If you have a PHP website, probably good to take them down until you patch PHP 69.3% of the web runs on PHP so this is going to be intense! Good time maybe to buy… — @levelsio (@levelsio) October 21, 2026"

Il post è disponibile anche su X. I precedenti report di Decrypt sull'incidente Compound e Celer e sull'attacco a Curve sono disponibili qui e qui.

Le vulnerabilità arrivano inoltre mentre i modelli di intelligenza artificiale di frontiera vengono sempre più utilizzati per identificare difetti del software. Esperti hanno detto a Decrypt in giugno che la diffusione di tali strumenti potrebbe portare alla scoperta di molte altre vulnerabilità. Il report di Decrypt è disponibile qui.

Cosa dovrebbero fare i gestori dei siti web

Una volta che una patch diventa pubblica, gli attaccanti possono confrontare il codice vulnerabile e quello corretto per determinare cosa è cambiato. Il team forense di Sansec ha dichiarato di aspettarsi che "mass attacks to start within 15 minutes of the release." Quando un'altra vulnerabilità PHP è stata divulgata a giugno 2024, Akamai ha registrato tentativi di exploit contro i propri server esca entro 24 ore. L'analisi di Akamai è disponibile qui.

Telefoni, browser e laptop personali non necessitano di un aggiornamento PHP. Il lavoro ricade sulle organizzazioni che gestiscono siti web e server. I proprietari dei siti dovrebbero chiedere ai propri provider di hosting se PHP è stato aggiornato e identificare chi è responsabile della manutenzione del server.

Wordfence ha avvertito che gli aggiornamenti automatici di WordPress non avrebbero applicato questa correzione. I proprietari dei siti devono quindi verificare che PHP stesso sia stato patchato, anziché presumere che l'aggiornamento di WordPress risolva il problema.

Lo sviluppatore core di PHP Gina Peter Banyard ha dichiarato su Mastodon: "The only thing I can say is that the only mitigation is patching / upgrading PHP", aggiungendo: "I sadly know too much." Il post è disponibile qui.

Le organizzazioni che utilizzano PHP 8.1 o versioni precedenti devono pianificare un aggiornamento, perché tali versioni non ricevono rilasci ufficiali regolari. Anche gli utenti di PHP 8.2 affrontano una scadenza imminente: PHP 8.2 raggiunge la fine del ciclo di vita il 31 dicembre 2026, dopodiché non riceverà più patch di sicurezza.