Il 25 ottobre 2026 un pentester residente nel Regno Unito ha sfruttato la falla PHP chiamata PHP2Shell su un server che il ricercatore James Pavur aveva volutamente lasciato senza correttivo, con la chiave di un portafoglio bitcoin come esca. La sfida «Steal My Bitcoin» è caduta poco più di 19 ore dopo il suo lancio, quattro giorni dopo la pubblicazione dei correttivi. Per la sicurezza dei server delle PMI svizzere che ospitano un sito PHP, l'esperimento mostra con quale rapidità una falla nota diventa sfruttabile.

Come è stata vinta la sfida «Steal My Bitcoin»?

James Pavur, ricercatore in sicurezza informatica, ha messo online il sito stealmybitcoin.com sabato 24 ottobre 2026. Secondo Cybernews, il suo server girava apposta con PHP 8.4.26, una versione precedente ai correttivi del 21 ottobre. Il primo partecipante in grado di eseguirvi codice da remoto poteva recuperare la chiave di un portafoglio bitcoin.

La regola stava in una frase, riferisce BankInfoSecurity: un attacco completo, riprodotto in un unico file Python scritto con la libreria standard. La ricompensa, di circa 500 dollari all'inizio, è stata quadruplicata dalle donazioni della comunità. Ha raggiunto 0,02511679 bitcoin, ossia circa 2'000 dollari.

Il vincitore si chiama Jaydip Modhwadia, pentester di 26 anni noto con lo pseudonimo KillaBoi su GitHub. Ha ottenuto l'esecuzione di codice domenica 25 ottobre 2026 alle 15:47 UTC. Il contatore del sito indicava allora 19,28 ore.

Questa cifra sovrastima il tempo di attacco effettivo. Al lancio, l'indirizzo della sfida portava a una pagina statica. Pavur lo ha fatto puntare verso una pagina PHP dinamica solo verso le 13:00 UTC di domenica, secondo BankInfoSecurity. Modhwadia dice di aver lavorato circa tre ore in tutto, secondo Journal du Coin.

Il portafoglio, peraltro, non è stato svuotato dall'attaccante. Pavur ha ammesso di aver collocato sul server la chiave del portafoglio principale, e non quella del sottoportafoglio che conteneva i fondi. Ha verificato l'intrusione nei suoi registri, poi ha versato lui stesso il premio.

Che cosa fa l'exploit, in parole semplici?

L'attacco si basa sulle due falle PHP2Shell, CVE-2026-109618 e CVE-2026-109619. Modhwadia ne ha pubblicato i dettagli su GitHub, con uno script che richiede al massimo 20 richieste HTTP. Il principio, descritto nel suo resoconto citato da BankInfoSecurity, si riassume in tre fasi:

  • un invio di 32 KB spinge PHP a consumare molta più memoria, fino al suo limite di 128 MiB;
  • a corto di memoria, PHP lascia uno stato obsoleto in un processo riutilizzato, e le richieste successive ne fanno trapelare due indirizzi di memoria attraverso i cookie di sessione;
  • un'ultima richiesta colloca una falsa struttura interna che PHP esegue poi come un comando di sistema.

I due indirizzi servono ad aggirare l'ASLR (Address Space Layout Randomization), la protezione che colloca il codice e i dati di un programma in punti casuali della memoria. Alon Gal, direttore tecnico della società di intelligence sulle minacce Hudson Rock, ha giudicato l'exploit «impressionante», in particolare perché rispetta il limite di 1 MB per richiesta del server web Nginx.

Che cosa dimostra l'esperimento, e che cosa non dimostra

Il fatto accertato sta in una cronologia. I correttivi sono usciti il 21 ottobre 2026. Un exploit funzionante e pubblico esisteva il 25 ottobre. Nello stesso fine settimana, Adel Ka, responsabile del rilevamento e della risposta agli incidenti presso Perplexity, ha rilevato su sei honeypot 35 sfruttamenti riusciti provenienti da due indirizzi IP. L'accesso amministratore (root) seguiva 1,6 millisecondi dopo.

L'agenzia statunitense per la cibersicurezza CISA ha inserito le due falle nel suo catalogo delle vulnerabilità attivamente sfruttate il 26 ottobre 2026, secondo Journal du Coin. Ha concesso alle agenzie federali statunitensi tempo fino al 29 ottobre per correggerle.

Gli esperti traggono conclusioni diverse. Il ricercatore Matthew Hickey ritiene che l'exploit, facile da adattare, renda urgente l'aggiornamento. Il ricercatore britannico Daniel Card sfuma: ogni server è costruito, configurato e protetto in modo diverso, il che rende molti altri bersagli più difficili da attaccare rispetto a questo server dimostrativo.

La nostra analisi: la sfida non dimostra che tutti i server non aggiornati cadano in tre ore. Dimostra che un server esposto con una versione standard, senza correttivo, può cadere quattro giorni dopo la pubblicazione del correttivo, con uno strumento ormai pubblico. Il server di Pavur aveva una sola versione di ritardo: 8.4.26 invece di 8.4.27.

Che cosa 2clics ha già pubblicato su PHP2Shell

Le versioni corrette (8.5.12, 8.4.27, 8.3.36 e 8.2.35) e le impostazioni temporanee sono illustrate nel nostro articolo sulla falla PHP PHP2Shell. Il 22 ottobre 2026, più di 23'000 server legati alla Svizzera restavano vulnerabili, secondo il rilevamento di Risikomonitor presentato nel nostro articolo sulla cibersicurezza delle PMI di fronte a PHP2Shell.

Da allora si è aggiunto un elemento. Venerdì 23 ottobre 2026, il progetto PHP ha segnalato una terza falla di esecuzione di codice, CVE-2026-115560, secondo BankInfoSecurity. Ritiene poco probabile il suo sfruttamento nella pratica e la correggerà nella sua prossima versione regolare, senza correttivo d'urgenza. Nel frattempo, consiglia di impostare session.upload_progress.enabled=0. Un server che ha già applicato questa impostazione contro PHP2Shell non deve fare nient'altro per questa terza falla.

Che cosa raccomanda l'UFCS a una PMI che ospita un sito PHP?

L'Ufficio federale della cibersicurezza (UFCS) ha pubblicato il 21 ottobre 2026 un avviso su queste falle. Non limita il controllo al sito pubblico: PHP può girare anche in un'interfaccia di amministrazione, in un'applicazione aziendale interna, in un container o in un dispositivo. Le sue raccomandazioni, in ordine:

  • Censire le installazioni PHP, le loro versioni, la loro accessibilità e i loro responsabili, anche presso i fornitori di servizi; trattare prima ciò che è accessibile da internet o riguarda dati sensibili.
  • Aggiornare senza indugio, e ottenere dal provider di hosting o dal produttore la conferma che il correttivo è stato applicato.
  • Riavviare i servizi PHP dopo l'aggiornamento; i container potrebbero dover essere ricostruiti.
  • Verificare la versione effettivamente attiva: una distribuzione Linux può integrare il correttivo senza cambiare il numero di versione, fa fede il pacchetto indicato dal fornitore.
  • Controllare i registri: richieste insolite, arresti anomali, file modificati, processi inattesi. Un aggiornamento non ripara un'intrusione già avvenuta.

Se l'aggiornamento è impossibile subito, l'UFCS chiede di limitare l'accesso alle sole persone e ai soli sistemi che ne hanno bisogno. Per un'applicazione critica, occorre valutare una disconnessione temporanea da internet. Le misure transitorie, come disattivare la barra di avanzamento degli invii o bloccare le richieste multipart, riducono solo alcuni percorsi di attacco. L'ufficio precisa che un firewall per applicazioni web, da solo, non basta.

Che cosa cambia per una PMI: dal 25 ottobre, il controllo dei registri non è più una precauzione teorica. Un sito corretto dopo questa data è stato esposto a un exploit pubblico e merita questa verifica. Al di là dell'urgenza, lo standard minimo TIC della Confederazione offre un quadro per tenere aggiornato l'inventario.

Che cosa non si sa ancora

  • La quota dei tentativi osservati sugli honeypot che vanno a segno su server reali, meglio protetti, non è stata misurata.
  • James Pavur ha lasciato intendere che potrebbe lanciare una nuova sfida, senza indicarne la forma né la data.

Fonti