PHP espone una vulnerabilità ad alto rischio a livello 'internet': come affrontare il 'punto debole off-chain' di Web3?

Titolo originale: «PHP espone una vulnerabilità critica a livello 'internet': come correggere il 'punto debole off-chain' di Web3?». Autore originale: SlowMist Security Team

Cosa è accaduto

Il 21 ottobre il progetto PHP ha rilasciato un aggiornamento di sicurezza d'emergenza per correggere due vulnerabilità critiche, CVE-2026-109618 e CVE-2026-109619, che possono causare l'esecuzione remota di codice non autenticata (RCE); entrambe sono state valutate CVSS v4.0 con punteggio 9,2. PHP ha dichiarato ufficialmente che, prima della correzione, tutte le installazioni PHP che forniscono servizi web esterni potevano essere interessate.

Il 20 ottobre i dettagli della vulnerabilità sono trapelati prima della divulgazione ufficiale e la patch non era ancora stata rilasciata. Il team di sicurezza PHP ha dovuto anticipare il rilascio d'emergenza, spostandolo dall'originario 22 ottobre alle ore 14:00 (UTC) del 21 ottobre.

Ancora più allarmante è che gli attacchi potrebbero aver preceduto la divulgazione. Il team di intelligence sulle minacce di Amazon ha riportato che il 17 ottobre ha osservato tentativi di sfruttamento mirati a php2shell nella propria rete honeypot MadPot, quattro giorni prima della divulgazione pubblica.

SlowMist ha emesso immediatamente avvisi e raccomandazioni sulla sicurezza dopo l'avviso preliminare ufficiale di PHP.

Quali sono le due vulnerabilità?

CVE-2026-109618 (Corruzione memoria per esaurimento memoria - OOM): quando PHP esaurisce la memoria, il flusso di elaborazione viene interrotto e i dati in elaborazione sono solo parzialmente preparati. Durante la fase di pulizia, PHP tratta questi dati incompleti come se fossero completi, causando corruzione della memoria.

CVE-2026-109619 (Stato globale obsoleto): dopo l'elaborazione di una richiesta, la memoria viene liberata, ma lo stato correlato 'rimane inalterato'. Quando lo stesso processo worker gestisce la richiesta successiva, potrebbe utilizzare questo stato scaduto prima dell'inizializzazione normale. Le autorità hanno confermato che ciò può essere sfruttato per attaccare PHP-FPM ed eseguire codice in remoto.

Dal punto di vista del percorso di attacco, il pericolo di questo tipo di vulnerabilità risiede nel fatto che gli attaccanti non devono prima ottenere un account sul sito né superare verifiche a livello applicativo, come login, permessi o chiavi API. L'invio di una richiesta appositamente costruita a un'applicazione PHP esposta su internet potrebbe consentire l'esecuzione arbitraria di codice con i privilegi del processo del servizio web.

Portata dell'impatto: sono interessate le versioni PHP da 5.4 a 8.5.11. Le versioni corrette sono 8.5.12, 8.4.27, 8.3.36 e 8.2.35. Le versioni PHP 8.1 e precedenti non ricevono più supporto regolare, quindi non si possono attendere patch tramite canali standard; si raccomanda la migrazione a versioni ancora supportate.

Perché il mondo intero è preoccupato?

Perché PHP è semplicemente troppo diffuso. Secondo i dati di W3Techs, tra i siti web il cui linguaggio lato server è identificabile, il 69,3% utilizza PHP. Sistemi noti come WordPress, WooCommerce e Magento vi si basano internamente.

Anche le reazioni dei vari paesi illustrano il problema: il Centro nazionale olandese per la sicurezza informatica ha chiuso precauzionalmente alcuni siti web; l'Ufficio presidenziale sudcoreano ha convocato un'urgente riunione sulla sicurezza informatica e il governo ha innalzato il livello di allerta.

Inoltre, secondo alcune segnalazioni, quasi tutti i siti web ufficiali della Corea del Nord — compresi quelli dei media statali e dei portali governativi — sono stati offline per oltre 24 ore; non è ancora chiaro se ciò sia collegato all'incidente di vulnerabilità.

Impatto su Web3

Questo non è un problema che riguarda esclusivamente la gestione e manutenzione tradizionale dei siti web. Per Web3, anche se gli smart contract on-chain non presentano vulnerabilità, il gran numero di «componenti off-chain» che circondano le operazioni contrattuali — tra cui pagine front-end, API, wallet custodiali, servizi di firma, pagine per il claim di airdrop, backend operativi e servizi dati — è spesso realizzato in PHP (WordPress, WooCommerce, Magento, ecc.). L’assenza di vulnerabilità negli smart contract non implica che tali componenti siano sicuri.

Secondo dati statistici del sistema di intelligence sulle minacce MistEye, sviluppato da SlowMist, su 1.488 domini correlati al settore crypto analizzati, 793 mostravano impronte dirette di PHP, pari a circa il 53,3%. Va sottolineato che questo indica semplicemente l’uso di PHP, non che i siti abbiano vulnerabilità o siano stati compromessi.

1. Lato piattaforma: Percorsi di rischio tipici

Manomissione del frontend per indurre gli utenti a firmare.

Se i server di siti DeFi, wallet o pagine di airdrop vengono compromessi, gli attaccanti possono sostituire gli indirizzi RPC, le destinazioni di autorizzazione, gli indirizzi degli smart contract o i messaggi di firma visualizzati nella pagina, trasformando una transazione legittima in un’autorizzazione dannosa, un’interazione malevola con un contratto o un processo di deposito fasullo. Gli attaccanti non devono violare lo smart contract: basta indurre l’utente a firmare autonomamente un’autorizzazione dannosa.

Fuga di chiavi e credenziali.

Dopo la compromissione di un server, gli attaccanti potrebbero leggere file di configurazione, password di database, token API, variabili d’ambiente e altro ancora. Se il backend utilizza PHP per connettersi a servizi RPC o a wallet caldi, la fuga di chiavi API o di token di sessione potrebbe portare al trasferimento di asset dai wallet caldi o all’abuso dei permessi di firma.

Riconquista del backend e delle API.

Piattaforme di trading, marketplaces NFT, bridge cross-chain, gateway di pagamento e provider di servizi nodo dispongono solitamente di backend operativi, nonché interfacce KYC/controllo del rischio, allocazione di indirizzi di deposito, revisione di prelievi, sistemi di ticketing ecc. Ottenuti i permessi, gli attaccanti potrebbero modificare configurazioni, rubare dati utente, creare account ad alto privilegio o aggirare processi aziendali.

Movimento laterale tramite supply chain.

I privilegi di un processo PHP di solito non corrispondono ai privilegi massimi sul server; tuttavia, se riesce ad accedere a chiavi CI/CD, socket del runtime dei container, credenziali di database o token di accesso al cloud, l’ambito dell’attacco potrebbe espandersi da un singolo nodo web a database, sistemi di build o addirittura all’intero account di produzione.

Plugin di pagamento e servizi terzi.

È noto che soluzioni crypto di pagamento come Binance Pay, Crypto.com Pay, BitPay, CoinGate e CoinPayments offrono tutte integrazioni con WooCommerce; server non aggiornati comportano gravi rischi di esposizione. Anche servizi terzi come RPC, block explorer e piattaforme di analisi dati potrebbero diventare punti d’ingresso qualora i loro backend o sistemi operativi fossero basati su ambienti PHP vulnerabili. Naturalmente, nodi RPC, smart contract, block explorer e wallet non dipendono intrinsecamente da PHP: tutto dipende dalla stack tecnologica specifica del prodotto.

Tuttavia, va ricordato che un server compromesso non implica necessariamente il furto di asset on-chain. Dal compromesso di un servizio web alla perdita finanziaria effettiva, tutto dipende dal fatto che gli attaccanti riescano ad accedere a credenziali sensibili, processi di firma, privilegi amministrativi o punti di interazione con l’utente. Il fatto che i wallet caldi siano isolati dal livello web, che le chiavi siano archiviate in HSM/KMS e che i privilegi siano minimizzati determina direttamente il limite massimo di potenziale perdita.

2. Utenti comuni: Dovreste ritirare le vostre criptovalute?

No, non è necessario.

Il motivo è semplice:

Questa vulnerabilità interessa ambienti server che soddisfano condizioni specifiche; non significa che tutti i wallet degli utenti siano a rischio.

Navigare un sito web e connettere un wallet non equivale a esporre la chiave privata. La vulnerabilità stessa non può decifrare direttamente i wallet o le firme degli utenti.

Il fatto che un progetto utilizzi PHP non implica che sia già stato compromesso. Non vi è alcun motivo per ritenere che ogni piattaforma di trading sia stata violata, tantomeno per ritirare tutti gli asset a causa di questa notizia. Ciò di cui gli utenti devono veramente preoccuparsi è se i siti che visitano sono stati compromessi. Poiché gli utenti non possono sapere se un sito è stato aggiornato, questo incidente ricorda l’importanza di non fidarsi ciecamente delle interfacce web: gli attaccanti potrebbero infatti sfruttare l’attenzione pubblica per diffondere pagine di login false, portali fasulli di risarcimento o richieste malevole di connessione wallet.

Se un progetto conferma ufficialmente che il proprio sito web o backend è stato compromesso, gli utenti devono seguire l’impatto reale divulgato per decidere se sospendere le interazioni, verificare transazioni anomale e revocare autorizzazioni sospette. Se è confermata la fuoriuscita di chiavi private per firme o frasi seed, ciò va gestito come un incidente di compromissione delle chiavi: cambiare semplicemente le password o disconnettersi dal sito non è sufficiente. Gli utenti di bot per trading, strumenti di esecuzione automatizzata o servizi cloud devono inoltre verificare se i relativi servizi hanno rilasciato avvisi su versioni interessate o rotazione delle credenziali.

Come rispondere

1. Piattaforme e team di progetto:

Passo uno: fare inventario delle proprie risorse e aggiornare immediatamente

Inventariare tutte le risorse PHP pubbliche e interne: host, immagini container, workload Kubernetes, CMS legacy, backend amministrativi, ambienti ospitati da partner, plugin di terze parti e servizi gestiti. Le impronte tecniche possono solo fungere da indizi e non costituiscono una prova definitiva di «vulnerabilità confermata».

Aggiornare a 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 oppure applicare le patch equivalenti fornite da distributori, provider cloud o fornitori di servizi gestiti. Per chi usa versioni 8.1 o precedenti, richiedere un backport al fornitore o migrare quanto prima. Nessuna giustificazione — né «l’ambiente legacy è stabile» né «l’applicazione è raramente aggiornata» — riduce il rischio di questa vulnerabilità.

Dopo l’aggiornamento, ricostruire le immagini container, eseguire riavvii progressivi o sostituire tutti i processi worker PHP e verificare la versione effettiva in esecuzione in produzione — non solo quella presente sulla macchina di build o nella riga di comando.

Passo due: cosa fare se non si può aggiornare subito

Innanzitutto, ridurre la superficie di esposizione per guadagnare tempo, ma questo non sostituisce la correzione:

Isolare le applicazioni PHP esposte a Internet pubblico o aggiungere autenticazione di rete e controllo degli accessi al livello ingress.

Disabilitare caricamenti file non necessari e rifiutare richieste multipart/form-data superflue a livello WAF o server web.

Alcuni consigli di sicurezza includono anche: impostare memory_limit=-1, disabilitare session.upload_progress.enabled e, su PHP 8.5, disabilitare anche fatal_error_backtraces. Queste configurazioni hanno effetti collaterali sul business e sulla disponibilità; testarle prima e riavviare tutti i worker PHP dopo ogni modifica.

Passo tre: verificare eventuali compromissioni e ruotare le credenziali

Per i servizi interessati precedentemente esposti a Internet pubblico, condurre indagini tramite log, monitoraggio endpoint e connessioni di rete anomale — ad esempio, processi PHP che avviano improvvisamente comandi di sistema. In caso di sospetta compromissione, preservare innanzitutto le prove, quindi agire secondo il processo di risposta agli incidenti.

Presupporre il peggio: per i server non corretti in tempo, ruotare chiavi API, chiavi di sessione, certificati TLS, password database, token di accesso cloud, credenziali CI/CD, chiavi RPC/API, segreti webhook e token di terze parti, verificando poi eventuali utilizzi anomali.

Se una versione software compromessa è stata installata o eseguita nell’ambiente, l’aggiornamento o la reinstallazione da soli non dimostrano l’eliminazione del rischio; occorre invece indagare su eventuali fughe di credenziali e backdoor persistenti, e, se necessario, ricostruire un ambiente pulito.

Passo quattro: proteggere il piano di controllo delle risorse

Correggere PHP non deve essere l’unica azione. È fondamentale garantire che «un server web compromesso non trascini con sé il sistema finanziario»:

Isolare completamente le chiavi private dei wallet hot, dei wallet di raccolta e dei servizi critici di firma dai nodi web. Usare HSM, MPC, reti dedicate per firme o politiche KMS a privilegi minimi.

Posizionare servizi web, servizi di firma, nodi on-chain, database e sistemi di build in segmenti di rete e confini di identità distinti.

Durante gli incidenti, rafforzare temporaneamente operazioni ad alto rischio come prelievi, modifiche alle whitelist degli indirizzi, elevazione dei privilegi amministrativi, creazione di chiavi API e modifiche alle regole di controllo del rischio, abilitando revisione manuale o attivazione differita quando necessario.

Per i servizi che eseguono automaticamente transazioni sulla blockchain, adottare firme indipendenti, approvazioni multi-firma, limiti agli importi delle transazioni e meccanismi di arresto d'emergenza in base alle esigenze aziendali.

Verificare risorse statiche del sito, pacchetti JavaScript, configurazioni di reverse proxy, regole DNS/CDN e servizi di costruzione transazioni per assicurarsi che non siano stati inseriti o sostituiti script dannosi.

2. Utenti comuni:

Usare punti di accesso ufficiali: ultimamente accedere alle piattaforme tramite segnalibri o canali ufficiali, diffidando di qualsiasi link inviato sotto la falsa scusa di un «incidente di sicurezza».

Non fidarsi solo del dominio e dell'interfaccia: anche per domini dApp noti, gli script della pagina, i parametri della transazione e le configurazioni RPC potrebbero essere stati sostituiti dagli aggressori lato server.

Verificare ogni elemento prima della firma: indirizzo destinatario, blockchain, importo approvato, contratto chiamato e risultati della simulazione della transazione. Prestare particolare attenzione a approve e setApprovalForAll, ed essere ancora più cauti con approvazioni illimitate.

Diffidare di «risarcimenti», «migrazioni» e «reverifiche»: durante gli incidenti possono apparire messaggi quali «re-accesso», «re-verifica del wallet», «migrazione di asset» e «richiesta di risarcimento». Non agire esclusivamente in base a popup interni al sito, ma verificare tramite più canali ufficiali del progetto.

Separare gli asset su più livelli: usare portafogli hardware per i grandi depositi, portafogli con capacità limitata per le interazioni quotidiane e pulire regolarmente le autorizzazioni. Così, anche se il frontend o la piattaforma fossero compromessi, ogni singola perdita sarebbe comunque contenuta.

Fermarsi immediatamente se qualcosa sembra anomalo: in presenza di richieste insolite di firma, promp di approvazione inattesi o comportamenti sospetti del sito, sospendere l’operazione e verificare tramite canali ufficiali.

Considerazioni finali

Le vulnerabilità di esecuzione remota senza login, come PHP2Shell, una volta superato il livello Web, possono trasformare intrusioni server tradizionali in avvelenamento del frontend, impersonificazione di identità, abuso di permessi di firma, rischi per i portafogli caldi e persino movimenti laterali a livello di supply chain.

Per le piattaforme, tre azioni sono prioritarie: aggiornare alle versioni corrette, isolare temporaneamente gli ambienti legacy non aggiornabili e verificare chiavi e piani di controllo asset. Dopo l’aggiornamento, ricercare segni di intrusione deve far parte della risposta all’incidente. Per gli utenti, in questo periodo, fare maggiore affidamento sull’interfaccia web è meno sicuro: controllare attentamente ogni transazione prima della firma. Ma non allarmarsi eccessivamente: l’esistenza di una vulnerabilità non implica necessariamente un rischio per gli asset; un compromesso del server non porta automaticamente a perdite di fondi on-chain. Il vero fattore determinante della portata del rischio è quali credenziali riescono a ottenere gli aggressori, quale livello di privilegio esse conferiscono e quanto velocemente il progetto riesce a isolarle e revocarle. Per i progetti Web3, la sicurezza non riguarda solo prevenire gli attacchi, ma anche valutare: se un componente viene effettivamente compromesso, l’impatto può essere contenuto localmente, impedendo che il rischio si estenda alle operazioni core e agli asset.

Link originale