Railway Dibobol, Pengguna Diminta Rotasi Semua Env Var

Kalau aplikasimu pernah di-deploy di Railway sebelum 21 Oktober 2026, anggap semua environment variable (env var) yang tersimpan di sana sudah tidak aman dan rotasi sekarang. Railway mengonfirmasi penyerang berhasil masuk ke sebagian sistem internalnya, mengambil env var terenkripsi milik pelanggan, lalu mendekripsi sebagian di antaranya.

Kenapa ini serius? Env var biasanya berisi hal paling sensitif dari sebuah aplikasi: API key penyedia AI, password database, token pembayaran, kredensial registry container. Satu kunci yang bocor bisa berujung pada tagihan API yang membengkak atau data pelanggan yang diakses orang lain.

Apa yang sebenarnya terjadi?

Railway pertama kali mengumumkan insiden ini pada 21 Oktober 2026, lalu merilis laporan awal (preliminary report) keesokan harinya. Menurut laporan itu, serangan berlangsung sekitar 20 Oktober pukul 13.58 UTC sampai 22 Oktober pukul 03.32 UTC.

Ringkasan kronologinya dari laporan resmi Railway:

Selama investigasi, semua deployment sempat dijeda. Railway juga mencabut semua access token Railway sebagai langkah pencegahan. Layanan untuk pengguna lama dinyatakan pulih penuh pada pembaruan 26 Oktober.

Berapa banyak yang terdampak?

Laporan awal Railway memperkirakan paling banyak 1,85% workspace, atau sekitar 100.000 workspace, yang env var-nya mungkin terekspos. Angka ini masih perkiraan awal dan bisa berubah setelah forensik selesai.

Karena Railway tidak bisa memastikan kunci mana saja yang terbaca, mereka memberi tahu penyedia layanan upstream tentang semua kunci yang tersimpan. Railway juga menghubungi langsung pelanggan yang dianggap berisiko tinggi, dan jumlahnya lebih banyak dari 1,85% tadi.

Menurut Railway, akun pengguna tidak diakses dalam insiden ini. Kemungkinan akses ke source code belum bisa dipastikan.

Apa yang diincar penyerang?

API key penyedia AI. Railway menyebut log menunjukkan penyerang mencari kunci API AI dan platform tertentu, diduga untuk serangan distilasi model (memakai model AI orang lain secara masif untuk melatih model tiruan). Dua kelompok yang dianggap paling berisiko adalah workspace dengan banyak env var dan environment yang menyimpan banyak API key AI.

Polanya mirip dengan insiden lain bulan yang sama. Zeabur, platform PaaS lain, juga melaporkan kebocoran env var dan kemudian mengumumkan penutupan layanan, seperti dibahas di Zeabur tutup akhir Desember.

Apa saja yang harus kamu lakukan sekarang?

Rekomendasi resmi Railway, disusun sebagai daftar kerja:

• Rotasi semua kunci dan variabel sensitif yang tersimpan di Railway bila akunmu dibuat sebelum 21 Oktober. Prioritaskan bila Railway menghubungimu langsung.
• Mulai dari API key AI, karena itu target utama. Buat kunci baru di dasbor penyedia, pasang di aplikasi, lalu cabut kunci lama.
• Ganti password database dan matikan akses jaringan publik ke database bila tidak benar-benar perlu.
• Rotasi kredensial registry privat dan periksa log audit registry seperti Docker Hub.
• Periksa log audit GitHub dan tinjau aplikasi yang punya akses ke repositorimu.
• Cek pemakaian dan tagihan AI. Untuk tagihan yang mencurigakan, Railway menyarankan menghubungi penyedia token terkait lalu mengajukan permintaan lewat station.railway.com.
• Baca log layananmu untuk aktivitas yang tidak biasa sejak 20 Oktober.

Rotasi yang benar itu seperti apa?

Rotasi bukan sekadar mengganti nilai di dasbor. Urutan yang aman: buat kredensial baru, pasang di semua tempat yang memakainya, pastikan aplikasi berjalan, baru cabut yang lama. Jangan lupa salinan kunci yang mungkin ada di file .env lokal, CI, atau backup.

Untuk jangka panjang, kurangi jumlah secret yang disimpan di satu tempat dan beri setiap kunci izin sekecil mungkin. Panduan lengkapnya ada di mencegah bocornya file .env dan API key.

Perlukah pindah dari Railway?

Itu keputusan masing-masing tim. Railway menyebut sudah merotasi semua kunci internal, membangun ulang tooling dari sumber tervalidasi, melibatkan perusahaan forensik eksternal, dan meluncurkan infrastruktur builder single-tenant generasi baru. Laporan forensik final masih ditunggu.

Insiden ini mengingatkan bahwa menyimpan secret di platform pihak ketiga berarti ikut menanggung risiko keamanan platform itu. Bila kamu ingin kontrol penuh, opsi menjalankan PaaS sendiri di server bisa dipertimbangkan, misalnya lewat Coolify, Dokploy, atau CapRover, dengan konsekuensi kamu sendiri yang bertanggung jawab atas keamanannya.