Cosa è successo
Il 21 ottobre Railway ha comunicato che un soggetto non autorizzato ha avuto accesso ai sistemi che conservano le variabili d'ambiente dei clienti e che, per alcune di esse, l'attaccante potrebbe averne ottenuto il contenuto decifrato. Railway ha sospeso tutti i deploy, ha avvisato i provider a monte perché revocassero le chiavi e ha chiesto a tutti gli utenti di rigenerare le variabili d'ambiente, comprese le credenziali dei registry privati.
Il rapporto preliminare aggiunge altri dettagli:
- La finestra dell'attacco va dal 20 ottobre alle prime ore del 22 ottobre (UTC). Tutto è iniziato con un tentativo di escalation dei privilegi nell'infrastruttura di build.
- Al massimo l'1,85% dei workspace, circa 100.000, ha avuto alcune variabili potenzialmente compromesse. Per come erano cifrate le chiavi, Railway non è ancora in grado di dire esattamente quali segreti di un progetto coinvolto siano stati esposti.
- L'attaccante cercava API key di provider AI e di piattaforme. Railway considera a rischio più alto i workspace con molte variabili d'ambiente o con molte chiavi AI.
- Railway dichiara di non poter rimborsare la spesa AI generata con chiavi compromesse. Devi rivolgerti direttamente al provider.
Secondo TechCrunch, Railway ritiene che l'attacco facesse parte di una campagna più ampia contro le piattaforme, con l'obiettivo di compromettere i provider di inferenza AI. Nella stessa settimana lo strumento di coding AI OpenCode ha reso noto che degli hacker avevano sottratto API key e altri segreti a più dell'1% dei suoi clienti.
Perché il bersaglio sono gli sviluppatori
Le chiavi AI rubate valgono soldi veri. Gli attaccanti rivendono l'accesso o consumano la tua quota per i propri carichi di lavoro, un fenomeno che i ricercatori chiamano LLMjacking. Una piattaforma di hosting è il posto ideale per raccoglierle, perché migliaia di app tengono in un unico luogo le chiavi di OpenAI, Anthropic, Stripe e del proprio database.
Nel rapporto di Railway c'è un dettaglio scomodo. Le variabili erano cifrate, ma la piattaforma deve poterle decifrare per iniettarle nelle build e nei servizi in esecuzione. Una volta ottenuto il giusto accesso interno, la cifratura a riposo non ha fermato l'attaccante. Non è un problema solo di Railway. Qualsiasi host che esegue il tuo codice può leggere i tuoi segreti.
Quindi la domanda non è "il mio host è sicuro?". È "se domani trapelassero i segreti del mio host, quanto sarebbe grave e quanto in fretta potrei rimediare?"
Come verificare la tua esposizione
Dedicaci 20 minuti, anche se hai già cliccato "ruota" su qualche voce.
1. Fai l'inventario di ogni segreto. Elenca i nomi delle variabili in ogni progetto e ambiente, compresi staging e ambienti di preview. Se tieni un file .env.example, è un buon punto di partenza:
grep -oE '^[A-Z0-9_]+' .env.examplePer ciascuna, annota cosa sblocca: un database, un provider di pagamento, un provider AI, l'email, un bucket di storage, un token GitHub.
2. Controlla utilizzo e fatturazione dei provider AI. Cerca picchi di utilizzo, modelli che non riconosci o richieste a orari strani dal 20 ottobre in poi. È il posto in cui è più probabile che gli abusi emergano per primi.
3. Controlla gli audit log che hai. Railway consiglia espressamente di rivedere gli audit log di GitHub e gli accessi delle app installate, oltre ai log dei registry come Docker Hub. Guarda anche i log delle API del tuo provider di pagamento e i log delle connessioni al database.
4. Verifica se il tuo database è raggiungibile da internet. Il rapporto di Railway raccomanda di rimuovere l'accesso di rete pubblico ai database. Se una connection string trapelata punta a un database a cui chiunque può connettersi, la fuga è sfruttabile all'istante:
nc -zv your-db-host.example 5432 # "succeeded" from your laptop = publicly reachable5. Controlla cosa rivela già il tuo frontend. Violazioni come questa ricordano di separare i veri segreti dai valori pubblici per natura. Una chiave inclusa nel bundle JavaScript non è mai stata segreta.
Come ruotare senza rompere la produzione
L'errore tipico sotto pressione è revocare prima la vecchia chiave e poi affannarsi a fare il deploy di quella nuova mentre l'app restituisce errori. Segui invece quest'ordine:
- Crea una nuova credenziale presso il provider (nuova API key, nuova password del database, nuovo segreto del webhook). Per ora lascia attiva quella vecchia.
- Aggiorna la variabile sul tuo host e rifai il deploy, così l'app in esecuzione la recepisce.
- Verifica che l'app funzioni con il nuovo valore. Chiama un endpoint che usa davvero quel servizio.
- Revoca la vecchia credenziale presso il provider.
- Conferma che la vecchia non funzioni più, ad esempio facendo una chiamata di prova con quella e verificando che fallisca.
Scorri la lista in ordine di raggio d'impatto: chiavi di pagamento, credenziali del database, chiavi cloud e di storage, chiavi dei provider AI, token di GitHub e dei registry, poi tutto il resto. Le indicazioni di Railway si concentrano sulle variabili impostate prima del 21 ottobre, e i consigli successivi aggiungono di ricollegare GitHub e ricreare le credenziali della CLI e della CI.
Alcuni segreti richiedono più attenzione:
- Segreti di firma delle sessioni o JWT. Cambiarli disconnette tutti gli utenti. Dopo una violazione di solito è accettabile, ma se puoi avvisa gli utenti.
- Segreti di firma dei webhook. Aggiorna insieme il lato che riceve e il provider che invia, altrimenti per un po' rifiuterai eventi legittimi.
- Password del database. Se la tua piattaforma lo permette, crea un nuovo utente del database con gli stessi permessi, sposta l'app su quello e poi elimina il vecchio utente. È più pulito che cambiare la password sul posto.
Rendi meno dolorosa la prossima violazione
Non puoi impedire che il tuo host venga violato. Puoi fare in modo che un segreto trapelato valga meno.
Limita al minimo i permessi delle chiavi. Usa chiavi con permessi ristretti dove i provider le offrono. Una restricted key di Stripe che può solo creare sessioni di checkout è molto meno utile a un attaccante di una secret key completa.
Metti un tetto alla spesa. Imposta budget mensili e avvisi di utilizzo su ogni provider AI. Così una sorpresa a cinque cifre diventa una semplice email.
Separa gli ambienti. Non riutilizzare le chiavi di produzione in staging o nei deploy di preview. Ogni ambiente deve avere le proprie credenziali, così una fuga in uno non consegna anche l'altro.
Tieni i database privati. Usa la rete privata della tua piattaforma e, se sei su Supabase, assicurati che la Row Level Security sia attiva, così una anon key trapelata non espone le tue tabelle.
Non tenere mai segreti in file raggiungibili. Un file .env finito nella web root trapela anche senza alcuna violazione.
Scrivi adesso il tuo runbook di rotazione. La lista del passo 1, l'ordine indicato sopra e dove viene gestita ogni chiave. La prossima volta la rotazione richiederà un'ora invece di un weekend.
Checklist rapida
Ripercorrila per ogni app che pubblichi:
- Ogni segreto di ogni ambiente è in elenco, con ciò che sblocca.
- Ognuno è stato ruotato nell'ordine crea, deploy, verifica, revoca.
- Utilizzo e fatturazione dei provider AI controllati dal 20 ottobre, con tetti di spesa impostati.
- Log di GitHub, registry, pagamenti e database controllati.
- I database non sono raggiungibili pubblicamente.
- Produzione e staging usano chiavi diverse.
- Nessun vero segreto finisce nel codice frontend o in file accessibili dal web.
Il succo
Railway ha fatto la cosa giusta comunicando in fretta e spingendo per la rotazione. Ma succede di continuo alle piattaforme di hosting e per sviluppatori, perché è lì che stanno le chiavi. Chi ne esce con calma è chi sa quali segreti ha e riesce a sostituirli in un pomeriggio.
Già che fai pulizia, vale la pena controllare anche cosa espone la tua app dall'esterno. AppSafe scansiona il tuo sito live alla ricerca di problemi comuni come API key nei bundle JavaScript, file .env e .git esposti e header di sicurezza mancanti, con correzioni in linguaggio semplice. La nostra checklist di lancio per le app create con l'AI copre le altre basi.
Quando avrai ruotato tutto, esegui una scansione gratuita con AppSafe per assicurarti che non trapeli nient'altro.