Due falle critiche in PHP, blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il linguaggio su cui gira buona parte del web, sono nel mirino degli attaccanti a un giorno dalle correzioni, e finora nessun exchange, wallet o custode di criptovalute risulta colpito. Il progetto PHP ha rilasciato le versioni corrette il 21 ottobre, nel primo pomeriggio UTC, per due bug battezzati PHP2Shell e catalogati come CVE-2026-109618 e CVE-2026-109619. Entrambi hanno un punteggio CVSS v4.0 di 9,2 su 10 e permettono l’esecuzione di codice da remoto, secondo l’avviso di sicurezza di PHP su GitHub.
Coinbase e BitGo dicono di non essere coinvolte. BNB Chain afferma di non usare PHP. Binance sostiene di aver adottato misure di protezione prima della patch e di aver concluso la bonifica. Changpeng Zhao, fondatore di Binance, ha invitato i suoi follower a fare «molta attenzione» su qualsiasi sito web per alcuni giorni. Matthew Prince, amministratore delegato di Cloudflare, ha scritto su X che i tentativi di sfruttare le falle sulla rete di Cloudflare sono passati da migliaia prima dell’annuncio a milioni nelle prime ore di giovedì.
In Italia la vulnerabilità PHP è già oggetto di un allarme dell’Agenzia per la cybersicurezza nazionale: il CSIRT Italia dell’ACN ha pubblicato l’avviso AL07/261021/CSIRT-ITA la sera del 21 ottobre. Per chi si occupa di criptovalute la questione riguarda meno i grandi exchange e più la lunga coda dei servizi minori: negozi WordPress che accettano pagamenti in crypto, dashboard self-hosted, block explorer e interfacce per nodi che hanno PHP da qualche parte nello stack, oltre al phishing che accompagna di solito ogni bug molto citato dai media.
Vulnerabilità PHP: cosa fanno CVE-2026-109618 e CVE-2026-109619
La prima falla, CVE-2026-109618 (avviso GitHub GHSA-w8hw-w9fx-j79w), è un errore di corruzione della memoria che può essere innescato quando PHP esaurisce la memoria mentre elabora una richiesta. La seconda, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp), nasce da uno stato globale che resta «sporco» da una richiesta alla successiva. In entrambi i casi un attaccante può far eseguire codice al server: è questo il significato di «esecuzione di codice da remoto» (RCE) e il motivo del 9,2.
La configurazione più a rischio è mod_php, il modulo che esegue PHP dentro il server web Apache. Qui, secondo l’avviso, una sola richiesta di una persona non autenticata può far partire l’attacco prima ancora che giri il codice del sito, e il team di PHP ha dimostrato l’esecuzione di codice via HTTP con i limiti di memoria predefiniti. PHP-FPM, il gestore di processi usato con Nginx da molti hosting, è considerato vulnerabile, ma al momento della pubblicazione non era stato dimostrato un exploit completo. FrankenPHP e LSAPI di LiteSpeed sono probabilmente vulnerabili, senza che la cosa sia stata verificata.
Per questo il consiglio abituale di «aggiornare i plugin» non basta. Il bug sta nel runtime PHP del server, sotto WordPress, WooCommerce o qualsiasi codice personalizzato. Cloudflare lo scrive nel suo post: va aggiornato PHP stesso, perché aggiornare le applicazioni che ci girano sopra non è sufficiente.
Versioni di PHP corrette e stato del supporto
Il 21 ottobre sono uscite quattro versioni corrette, una per ogni ramo supportato. Anche la release candidate 8.6.0 (RC4), pubblicata lo stesso giorno, contiene le correzioni, ma è una build di prova che PHP sconsiglia di usare in produzione.
| Ramo PHP | Versione corretta | Stato |
|---|---|---|
| 8.5 | 8.5.12 | Supportato |
| 8.4 | 8.4.27 | Supportato |
| 8.3 | 8.3.36 | Supportato |
| 8.2 | 8.2.35 | Correzioni di sicurezza fino al 31 dicembre 2026 |
| 8.1, 8.0, 7.4 | Nessuna release ufficiale | Fine vita; il team di sicurezza di PHP ha pubblicato backport minimi del codice sorgente |
Le distribuzioni Linux hanno ricevuto le patch in anticipo, quindi i pacchetti di Debian, Ubuntu o Red Hat possono già contenerle con numeri di versione propri. Nel giorno del rilascio il CERT-UE ha osservato che il repository di Remi, fonte diffusa di build recenti di PHP per i sistemi di tipo Red Hat, non aveva ancora aggiornamenti. Anche i software che includono una copia propria di PHP possono essere esposti: il CERT-UE rimanda gli amministratori a un repository GitHub curato dall’NCSC olandese, che elenca i prodotti interessati.
Il team di PHP ricorda che aggiornare è l’unica mitigazione completa. Per i server che non si possono aggiornare subito, PHP e CERT-UE elencano misure parziali che riducono il rischio senza eliminarlo: impostare memory_limit a -1 in modo che le applicazioni non possano modificarlo, tenere post_max_size a 8M o 32M, limitare la dimensione delle richieste sul proxy, disattivare session.upload_progress.enabled e, su PHP 8.5, impostare fatal_error_backtraces a 0. Sconsigliano invece i limiti di sistema RLIMIT_AS e RLIMIT_DATA.
Exploit già in corso dopo l’annuncio, ma nessuna vittima nominata
Cloudflare racconta di aver attivato le regole del suo web application firewall (WAF) contro le falle alle 03:02 UTC del 21 ottobre, circa nove ore prima della divulgazione pubblica, e di aver poi visto traffico d’attacco diretto ai propri clienti, con aggressori che modificavano i payload per aggirare le regole. Il post sul blog di Cloudflare non indica numeri. La protezione è attiva di default per i siti sul piano gratuito, tramite le regole «Generic Rules – Anomalous Execution» del Managed Free Ruleset; i clienti a pagamento devono usare il Cloudflare Managed Ruleset in modalità di blocco.
La cifra che compare in molti titoli viene da Prince. In un post su X all’1:25 UTC del 22 ottobre ha scritto che Cloudflare aveva visto migliaia di tentativi nelle dieci ore prima dell’annuncio, decine di migliaia nei 45 minuti successivi, centinaia di migliaia entro due ore e «milioni adesso». Sono tentativi, non intrusioni riuscite. Circa un sito web su cinque passa per Cloudflare, secondo l’azienda citata da Cointelegraph, quindi la sua visuale è ampia ma non completa.
Altri segnali vanno nella stessa direzione senza chiarire le dimensioni del fenomeno. Il direttore tecnico di Cloudflare, Dane Knecht, ha parlato di primi attacchi, come riportato da Fortune. Amazon ha individuato un tentativo di sfruttamento risalente al 17 ottobre, quattro giorni prima del rilascio, ha scritto Bitcoin.com News citando un post del blog di sicurezza di AWS. «I difensori non dovrebbero dare per scontato che la data della divulgazione pubblica sia la prima data di sfruttamento», ha detto il responsabile della sicurezza informatica di Amazon, CJ Moses, secondo la stessa fonte. Il CERT-UE ha segnalato che circolavano dettagli tecnici pubblici e prime dimostrazioni di exploit. L’agenzia americana per la cybersicurezza CISA, nel suo avviso del 21 ottobre, ha dichiarato di non aver osservato sfruttamenti al momento della pubblicazione.
Enti pubblici di Paesi Bassi e Finlandia hanno messo offline alcuni siti in via precauzionale, ha scritto Fortune citando Reuters; lo ha riportato anche Decrypt. L’FBI (divisione cyber) e la NSA hanno chiesto di aggiornare. Fortune ha definito le violazioni confermate «limitate e in evoluzione» senza fare il nome di alcuna vittima.
Due numeri vengono spesso confusi. PHP gira su circa il 69% dei siti web di cui si conosce il linguaggio lato server, secondo i dati W3Techs citati da Cointelegraph. È una misura di diffusione, non di esposizione, come ricorda Cointribune: un sito aggiornato o con una configurazione diversa da mod_php non è nella stessa posizione di un vecchio server Apache. Fortune riferisce che Palo Alto Networks ha contato 22,6 milioni di istanze potenzialmente vulnerabili, una cifra che arriva da un solo organo di stampa.
Come una fuga di notizie ha accelerato il rilascio
PHP aveva preannunciato la release di sicurezza il 20 ottobre, fissandola alle 14:00 UTC del giorno dopo. Secondo Decrypt, il rilascio coordinato era previsto in origine per il 22 ottobre ed è stato anticipato dopo che alcuni dettagli erano trapelati. Il CERT-UE colloca la pubblicazione delle correzioni alle 13:30 UTC del 21 ottobre.
OpenAI si è messa al centro della scoperta. Il suo presidente, Greg Brockman, ha detto che il bug era in PHP da 14 anni e che una versione limitata era emersa nel 2024 ma «non era stata considerata significativa», ha riportato Decrypt, il cui autore ha definito il messaggio una trovata di PR. Fortune offre un racconto più completo: la società di red team basata sull’IA Calif ha trovato il primo problema il 1° agosto con GPT-5.6 Sol di OpenAI, OpenAI ha poi indagato per conto proprio e ne ha trovati altri, mentre la società di sicurezza cloud Wiz ha individuato il primo problema in modo indipendente il 19 agosto usando diversi modelli, tra cui Gemini 4 Argon di Google. Secondo Fortune, OpenAI ha guidato una coalizione con Wiz, Calif, la PHP Foundation, Cloudflare e varie agenzie statunitensi. Il post di Cloudflare indica Calif, Wiz, OpenAI e Quarkslab come le quattro organizzazioni che hanno segnalato le falle, e l’avviso GitHub attribuisce la scoperta a quattro segnalatori, indicati con il solo nome utente.
Non va confuso con il bug di WordPress di luglio. Quello, noto come wp2shell (CVE-2026-63030 e CVE-2026-60137), è stato corretto in WordPress 6.9.5 e 7.0.2. PHP2Shell si trova un livello più in basso e richiede un aggiornamento di PHP, qualunque sia la versione di WordPress.
Cosa hanno detto Coinbase, BitGo, BNB Chain e Binance
Il responsabile della sicurezza di Coinbase, Jeff Lunglhofer, ha scritto sul suo account personale su X il 21 ottobre alle 20:32 UTC: «Coinbase ha completato una verifica del proprio ambiente e non ha trovato alcuna prova di istanze PHP esposte». Ha aggiunto che l’azienda sta lavorando anche con i fornitori terzi per avere ulteriori garanzie. Anche BitGo non è coinvolta, ha scritto Bitcoin.com News, senza citare direttamente la società.
BNB Chain ha dichiarato che il suo stack tecnologico «non usa PHP», secondo Coingape, che riferisce anche che un membro dello staff di Trust Wallet, Felix Fan, ha detto che lo stack del wallet non contiene PHP. La società di sicurezza blockchain SlowMist ha invitato exchange, wallet e piattaforme DeFi a controllare la propria infrastruttura, ha riportato EthNews, precisando che l’attività di attacco osservata finora non dice se una piattaforma crypto sia stata violata.
Changpeng Zhao ha scritto il 21 ottobre alle 22:06 UTC: «Chiamatemi paranoico, ma state molto attenti a visitare QUALSIASI sito web nei prossimi giorni». Nello stesso post ha citato le due CVE e ha detto che alcuni amministratori web sono lenti nell’applicare le patch di sicurezza.
L’account ufficiale di Binance è intervenuto il 22 ottobre alle 06:18 UTC. L’exchange ha detto che i suoi team di sicurezza hanno «adottato misure proattive prima del rilascio ufficiale della patch e completato gli interventi necessari» e che continua a monitorare la situazione. Non ha precisato se alcuni suoi sistemi usassero una versione vulnerabile di PHP: per «bonifica» si può intendere un aggiornamento, un filtraggio o una verifica senza esito.
Queste dichiarazioni riguardano i sistemi delle aziende stesse. Il riferimento di Lunglhofer ai fornitori indica dove può restare l’esposizione per una grande piattaforma: nei servizi e negli strumenti esterni che non gestisce direttamente. Alcuni siti hanno pubblicato articoli che chiedono se sia il caso di ritirare i fondi dagli exchange. Finora nulla di quanto pubblicato lo giustifica: nessun exchange ha segnalato un incidente e nessuno è stato nominato da ricercatori o agenzie.
Allerta ACN e CSIRT Italia: cosa dice l’avviso per chi lavora in Italia
Il CSIRT Italia, la squadra di risposta agli incidenti informatici dell’Agenzia per la cybersicurezza nazionale (ACN), ha pubblicato la sera del 21 ottobre, alle 19:35, l’avviso AL07/261021/CSIRT-ITA dal titolo «PHP2Shell: sanate vulnerabilità critiche in PHP». Per un’azienda italiana è il riferimento da conservare nel fascicolo dell’incidente e la pagina da seguire per eventuali aggiornamenti sullo sfruttamento in corso.
In Francia il CERT-FR, struttura dell’agenzia nazionale ANSSI, ha pubblicato l’allerta CERTFR-2026-ALE-014 il 20 ottobre e l’ha aggiornata il 21. Segnala che le due CVE possono consentire l’esecuzione arbitraria di codice da remoto e che le correzioni sono disponibili presso l’editore.
Né la Consob né l’OAM avevano pubblicato qualcosa sulle falle al momento in cui è stato scritto questo articolo, e non risulta alcun comunicato della Banca d’Italia sul tema. Per chi gestisce un sito o un servizio collegato alle criptovalute in Italia, gli avvisi di ACN e CSIRT Italia restano quindi la fonte ufficiale a cui riferirsi.
Come proteggersi se gestisci un sito crypto, un nodo o un plugin di pagamento
Gran parte del rischio ricade sugli operatori più piccoli: un commerciante che usa un gateway di pagamento in crypto su WooCommerce, un progetto che ospita il proprio explorer o la dashboard di staking, un validatore con una pagina di amministrazione in PHP. Gli avvisi ufficiali indicano un ordine di lavoro chiaro.
- Aggiorna PHP sul server o nell’immagine del container alla versione 8.5.12, 8.4.27, 8.3.36 o 8.2.35, oppure al pacchetto corretto della tua distribuzione. Un aggiornamento di WordPress o dei plugin da solo non risolve il problema.
- Se sei su hosting condiviso, chiedi al fornitore quale build di PHP usa il tuo account e quando è stata aggiornata.
- Cerca il PHP che non sapevi di avere: plugin di pagamento in crypto, dashboard di wallet o fatturazione, block explorer self-hosted, interfacce di nodi e staking, pannelli di amministrazione e immagini Docker costruite su basi PHP.
- Con PHP 8.1 o precedenti, passa a un ramo supportato, applica un backport del fornitore oppure scollega il sistema da internet, come raccomanda la CISA.
- Se oggi non puoi aggiornare, applica le impostazioni parziali elencate sopra, metti il sito dietro un WAF (il piano gratuito di Cloudflare include le regole) e controlla se compaiono processi PHP che avviano shell, un segnale di compromissione indicato dalla CISA.
Tratta come priorità qualsiasi server che abbia gestito chiavi private, chiavi API di account su exchange o credenziali di hot wallet. Un bug di PHP non raggiunge le chiavi custodite altrove, ma una pagina di pagamento compromessa può cambiare l’indirizzo di deposito mostrato ai clienti senza toccare il wallet. All’inizio della settimana il caso delle chiavi deboli di eMudhra aveva già spinto i team crypto ad aggiornare bot e server, e questa mattina la violazione di Railway ha chiesto a tutti gli utenti della piattaforma di hosting di cambiare i propri segreti.
Cosa fare ora se usi un wallet o un exchange
Le chiavi custodite su un hardware wallet non sono esposte da un bug di un server web. Il rischio viene dalle pagine che visiti. Un sito preso di mira tramite PHP può iniettare uno script «drainer» o sostituire un indirizzo di deposito, e all’attaccante non servono le tue chiavi se la transazione la firmi tu al posto suo.
Controlla ogni indirizzo di ricezione sullo schermo del dispositivo oltre che nel browser. Apri gli exchange da un segnalibro, non dai risultati di ricerca né da link ricevuti per email. Attiva la lista di indirizzi di prelievo autorizzati e, dove l’exchange la offre, un codice anti-phishing che compare nelle sue email autentiche. Aspettati messaggi su un presunto «aggiornamento di sicurezza PHP» che ti chiedono di accedere o di ricollegare il wallet: nessun exchange ha bisogno che tu lo faccia a causa di questo bug. La nostra guida su come riconoscere e segnalare le truffe crypto descrive le forme più comuni, e nessun messaggio genuino ti chiederà la frase di recupero: la guida alla sicurezza della seed phrase spiega come tenerla offline.
Sulla base dei fatti pubblicati finora non c’è motivo di spostare i fondi in fretta. Un prelievo affrettato verso un indirizzo sbagliato o sostituito è questa settimana un modo più probabile di perdere denaro rispetto a una violazione di un exchange che nessuno ha segnalato.
Cosa non si sa ancora e le prossime date
Non si sa quanti server siano stati realmente compromessi, e nessuna piattaforma crypto ha segnalato né risulta aver subito un’intrusione tramite PHP2Shell. I «milioni» di Prince contano tentativi, e Cloudflare non ha pubblicato alcuna ripartizione di quanti siano andati a buon fine. Binance non ha detto in che cosa sia consistita la sua bonifica e BitGo non è stata citata direttamente. Oltre ai quattro nomi utente su GitHub e alle aziende citate dalla stampa, le persone che hanno segnalato i bug non sono identificate.
La prossima data la detta il calendario di PHP: PHP 8.2 smette di ricevere correzioni di sicurezza il 31 dicembre 2026, quindi i siti ancora su quel ramo hanno circa dieci settimane per migrare. Conviene seguire le pagine di CERT-FR e ACN e il catalogo delle vulnerabilità sfruttate della CISA (Known Exploited Vulnerabilities) per un’eventuale conferma di sfruttamento reale, che trasformerebbe l’indicazione da urgente a valutazione della compromissione.