Railway, una piattaforma cloud che gli sviluppatori usano per far girare app, database e processi in background, mercoledì 21 ottobre ha chiesto a tutti i suoi utenti di cambiare ogni segreto custodito sulla piattaforma. Nel suo avviso di sicurezza firmato da Jacob Cooper l’azienda scrive di aver rilevato in mattinata un’attività anomala nei sistemi che conservano le variabili d’ambiente dei clienti, e che una terza parte potrebbe aver letto le variabili cifrate e, per alcuni clienti, averne ottenuto 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 contenuto in chiaro. Quelle variabili possono contenere chiavi API e credenziali di database e di registry.
La violazione di Railway ha presto avuto un risvolto crypto. The Defiant riferisce che uno sviluppatore collega al caso un furto da circa 370.000 dollari. È la tesi di un singolo sviluppatore: Railway non ha confermato alcun furto, e l’unica segnalazione on-chain che abbiamo trovato dice che il legame con Railway non è provato.
I team crypto hanno un interesse diretto. Bot di trading, keeper di liquidazione, relayer, indexer e piccoli backend di exchange girano spesso su piattaforme ospitate come Railway, e molti leggono la chiave di firma di un wallet da una variabile d’ambiente all’avvio. Se è la piattaforma a lasciar trapelare la variabile, il wallet resta esposto senza che ci sia alcun bug in uno smart contract.
Cosa ha ammesso Railway sull’accesso alle variabili d’ambiente
Il testo di Railway è breve e prudente. Non dice come l’attaccante sia entrato, quanti clienti siano coinvolti né da quando fosse attivo l’accesso. Spiega che le prime analisi indicano un impatto forse limitato a una parte degli utenti, ma consiglia a tutti di intervenire, e che scriverà via email ai clienti di cui confermerà il coinvolgimento.
Sul movente, Railway sostiene che l’episodio faccia parte di una serie di attacchi recenti contro aziende di piattaforme, il cui obiettivo è compromettere i fornitori di inferenza per l’intelligenza artificiale. In parole semplici: l’attaccante cercava con ogni probabilità chiavi per servizi di IA a pagamento, che si rivendono o si usano per far girare modelli a spese di altri. Railway dice di aver chiesto a quei fornitori a monte di revocare le chiavi in via preventiva.
Il post non nomina mai crypto, wallet o chiavi private. L’avviso riguarda ogni tipo di segreto archiviato da un cliente, e una chiave di wallet in una variabile d’ambiente è solo un’altra stringa per chi la legge, ma nulla di quanto pubblicato da Railway collega l’incidente a una perdita di fondi.
Le tre richieste di Railway ai clienti sono: ruotare tutte le variabili d’ambiente conservate sulla piattaforma, comprese le chiavi API; ruotare le eventuali credenziali di registry privati; controllare nei log dei propri servizi se ci siano attività insolite. Alle 01:22 UTC del 22 ottobre l’azienda ha collegato dalla pagina di stato 13 brevi guide. Riguardano utilizzi inattesi sugli account OpenAI, Anthropic, OpenRouter e Grok e su Stripe, accessi anomali su GitHub, AWS e Google Cloud, nuove credenziali per i database PostgreSQL, MySQL, MongoDB e Redis, e il redeploy dei bucket di archiviazione dopo il reset delle credenziali, come riassume anche il sito di cybersicurezza SecurityOnline. Nessuna delle 13 guide tratta wallet o chiavi di exchange.
Deploy sospesi e token API revocati: la cronologia dell’incidente Railway
L’avviso è arrivato insieme a un blocco. Railway ha sospeso tutti i deploy durante l’indagine, e ne è nato un problema paradossale: ai clienti a cui si chiedeva di sostituire le credenziali mancava il modo di pubblicare nuove versioni delle app che le usassero. La pagina di stato di Railway mostra come si è svolta la giornata, in orario UTC.
| Ora (UTC) | Aggiornamento della pagina di stato |
|---|---|
| 21 ott, 07:24 | Railway avvia l’indagine su un problema |
| 21 ott, 09:28 | Problema individuato; dashboard, API e strumento a riga di comando non disponibili, nuove build sospese in tutte le regioni |
| 21 ott, 11:33 | API di nuovo attive con alcune funzioni mancanti; build ancora sospese |
| 21 ott, 19:15 | Railway annuncia il ritorno delle build a scaglioni: prima Enterprise, poi Pro, Hobby, Free e Trial |
| 21 ott, 20:19 | Sessioni OAuth invalidate come misura di mitigazione, alcuni utenti disconnessi |
| 21 ott, 21:59 | Pubblicato l’avviso di sicurezza: revocare le variabili d’ambiente, controllare i log; deploy sospesi, Enterprise compresa |
| 21 ott, 22:10 | Rotazione di tutte le credenziali dei bucket di archiviazione; compaiono le nuove, ma serve un redeploy |
| 22 ott, 01:22 | Pubblicate le guide per ruotare le credenziali e verificare utilizzi anomali |
| 22 ott, 03:32 | Build disponibili per i workspace Enterprise; Pro, Hobby e Free/Trial a seguire per fasi |
| 22 ott, 04:17 | Tutti i token API di Railway invalidati; gli utenti devono crearne di nuovi |
| 22 ott, 04:39 | Servizi con comandi di pre-deploy bloccati; Railway lavora a una correzione |
Con l’aggiornamento delle 04:39 UTC solo i clienti Enterprise potevano tornare a fare build, e anche loro dovevano usare «Deploy Latest Commit», perché il pulsante Redeploy era ancora disattivato (aggiornamento delle 04:00 UTC). Railway ha inoltre precisato che alcuni passaggi della rotazione, come l’adozione delle nuove credenziali dei bucket, hanno effetto solo dopo un redeploy. Per un team con piano Pro o Hobby significa che un segreto può essere cambiato presso il fornitore prima che l’app ospitata su Railway sia in grado di usare quello nuovo. Un bot la cui chiave è stata revocata, nel frattempo, si ferma e basta.
Il furto da 370.000 dollari e cosa ha trovato Onchain Lens
La perdita in crypto poggia su due segnalazioni distinte. La prima è un articolo di The Defiant il cui titolo parla di uno sviluppatore che collega un furto da 370.000 dollari all’esposizione dei segreti di Railway. Non siamo riusciti a leggere il corpo dell’articolo, quindi il nome dello sviluppatore, la blockchain, il tipo di wallet e le prove addotte ci sono ignoti. Il titolo riporta l’affermazione di un solo sviluppatore, ripresa da una sola testata.
La seconda è on-chain. L’account di analisi Onchain Lens ha segnalato un «suspected attacker wallet» (wallet sospetto dell’attaccante) che ha inviato almeno 369.300 dollari all’exchange HitBTC e ad altri indirizzi, secondo TechFlow, che ha pubblicato la notizia alle 04:03 UTC del 22 ottobre, e secondo PANews. Le stesse fonti aggiungono che il wallet aveva ricevuto in precedenza fondi da un indirizzo legato al CryptoBillis Ledger Drainer, che TechFlow descrive come uno strumento «wallet drainer». Lo stesso Onchain Lens ha detto che il collegamento del wallet con l’incidente di Railway non è stato confermato.
Le due cifre sono vicine, 369.300 dollari contro circa 370.000, ma nessuna delle due fonti dice che si riferiscano alla stessa perdita, e nessuno ha dimostrato che sia così. In nessuna fonte che abbiamo potuto aprire compaiono un indirizzo di wallet o l’hash di una transazione, quindi i movimenti non si sono potuti verificare su un block explorer. Nemmeno il legame con il drainer risolve il dubbio: un wallet finanziato da indirizzi collegati a un drainer può appartenere a un ladro che riusa gli stessi strumenti, oppure a un furto che con Railway non c’entra nulla.
Cosa non si sa ancora della violazione di Railway
- Come l’attaccante sia arrivato ai sistemi che conservano le variabili d’ambiente, e da quando.
- Quanti clienti abbiano avuto variabili decifrate, e se le email ai clienti coinvolti siano già partite.
- Se una chiave privata o una seed phrase di wallet fosse custodita in una variabile Railway colpita.
- Chi sia lo sviluppatore citato da The Defiant e quale prova colleghi a Railway la perdita da 370.000 dollari.
- Se il wallet segnalato da Onchain Lens sia quello legato a quello sviluppatore.
- Se Railway commenterà mai eventuali perdite in crypto.
Chiave privata del wallet in una variabile d’ambiente: cosa rischiano bot e wallet
Una variabile d’ambiente è un valore con un nome che un programma legge all’avvio, come DATABASE_URL o OPENAI_API_KEY. Le piattaforme ospitate conservano questi valori per conto tuo e li iniettano nell’app: comodo, e tiene i segreti fuori dal repository del codice. Ma significa anche che la piattaforma custodisce una copia di ogni segreto. Se viene violata, tutti i segreti sono esposti in un colpo solo.
Per la maggior parte delle app, una chiave API trapelata è un problema di fatturazione o di dati. Le chiavi si revocano, e il danno è limitato a ciò che la chiave consentiva. Una chiave privata è un’altra cosa. Chi la legge controlla il wallet, e su una blockchain non esiste un pulsante di revoca. I fondi che si muovono sono persi, a meno che un exchange non li congeli all’arrivo.
È il punto debole di molte piccole operazioni crypto. Un market maker automatico, uno script di arbitraggio o un keeper per un protocollo di prestito devono firmare transazioni senza che qualcuno clicchi «conferma», e così la chiave sta spesso in una variabile chiamata più o meno PRIVATE_KEY, sullo stesso host che esegue il codice. Il wallet diventa un hot wallet la cui sicurezza vale quanto l’account di hosting.
Cosa ruotare subito se hai usato Railway
I passaggi che seguono sono buone pratiche generali di sicurezza, non istruzioni di Railway, fatta eccezione per la rotazione di variabili e credenziali di registry che Railway stessa chiede.
- Se una chiave privata o una seed phrase di wallet è mai stata salvata in una variabile Railway, consideralo compromesso: crea un nuovo wallet, sposta i fondi e poi aggiorna il bot perché usi la nuova chiave.
- Revoca le approvazioni di token (allowance) concesse a contratti dal vecchio wallet, perché chi ha la chiave potrebbe sfruttare anche quelle.
- Ruota le chiavi API degli exchange conservate su Railway; quando ne crei di nuove, disattiva i permessi di prelievo e, se l’exchange lo consente, limitale all’indirizzo IP del tuo server.
- Cambia le chiavi dei provider RPC, le password dei database, i segreti dei webhook e i token dei bot Telegram o Discord usati per gli avvisi.
- Crea nuovi token API di Railway, dato che i vecchi sono stati invalidati alle 04:17 UTC del 22 ottobre, e aggiorna gli script di deploy che li usano.
- Controlla nei log dei tuoi account di IA, pagamenti e cloud se ci sono attività che non hai avviato tu, come suggeriscono le guide di Railway.
Come tenere le chiavi degli hot wallet fuori dalle variabili d’ambiente
La soluzione di lungo periodo è smettere di mettere una chiave di firma in chiaro dove la piattaforma può leggerla. Le strade sono un servizio cloud di gestione delle chiavi o un modulo di sicurezza hardware che firma senza esporre la chiave, un servizio di firma separato con limiti propri, oppure un wallet a smart contract la cui chiave del bot possa fare solo piccole transazioni verso indirizzi autorizzati. In ogni caso, l’hot wallet usato da un bot dovrebbe contenere solo il saldo necessario per le ore successive, con il resto in custodia a freddo, come spiega la nostra guida a wallet e custodia crypto.
Per chi gestisce app con dati personali di persone nell’Unione europea c’è anche un termine di legge. Secondo il GDPR, il titolare del trattamento (nella maggior parte dei casi chi gestisce l’app) deve notificare una violazione dei dati personali all’autorità di protezione dei dati senza ingiustificato ritardo e, ove possibile, entro 72 ore da quando ne è venuto a conoscenza, a meno che sia improbabile che la violazione presenti un rischio per le persone. Un fornitore di hosting che agisce come responsabile del trattamento deve informare il cliente senza ingiustificato ritardo. In Italia l’autorità è il Garante per la protezione dei dati personali, in Francia la CNIL.
Railway è il terzo allarme sulle chiavi per gli utenti crypto in una settimana
L’incidente di Railway arriva in una settimana difficile per la sicurezza delle chiavi. La fondazione Polkadot ha invitato gli utenti di un’estensione per browser a spostare i fondi dopo che l’estensione Fearless Wallet ha fatto trapelare chiavi private, e un falso avviso diffuso dall’app stessa di Ngrave ha svuotato almeno 2,56 milioni di dollari da circa 70 wallet. Non è stato segnalato alcun legame tra i tre casi, e funzionano in modo diverso. In ciascuno, le perdite o presunte perdite risalgono a dove sono custodite chiavi o segreti, non a un difetto di un protocollo.
Lo schema è coerente con i numeri più ampi. Gli hacker hanno sottratto 1,18 miliardi di dollari nel terzo trimestre del 2026, il peggior trimestre dopo l’attacco a Bybit, secondo il rapporto Hacken sul terzo trimestre.
Cosa guardare nelle prossime ore
Railway ha promesso di scrivere via email ai clienti di cui confermerà il coinvolgimento e di pubblicare aggiornamenti sulla pagina di stato man mano che circoscrive l’incidente. Dopo l’aggiornamento delle 04:39 UTC del 22 ottobre, le build per i piani Pro, Hobby e Free/Trial dovevano ancora essere ripristinate a scaglioni. Per chi legge di crypto la domanda aperta è se lo sviluppatore all’origine dei 370.000 dollari, oppure Onchain Lens, renderà pubblici gli indirizzi coinvolti: solo così chiunque potrà verificare se i fondi rubati risalgono davvero a una variabile di Railway.