Apa yang terjadi
Pada 21 Oktober, Railway mengungkapkan bahwa pihak tidak berwenang telah mengakses sistem yang menyimpan environment variable pelanggan, dan untuk sebagian di antaranya penyerang mungkin telah memperoleh isinya dalam bentuk terdekripsi. Railway menghentikan sementara semua deployment, memberi tahu penyedia upstream untuk mencabut key, dan meminta semua pengguna mengganti environment variable mereka, termasuk kredensial private registry.
Laporan awalnya memberi detail tambahan:
- Jendela serangan berlangsung dari 20 Oktober hingga awal 22 Oktober (UTC). Semuanya dimulai dari upaya eskalasi hak akses di infrastruktur build.
- Paling banyak 1,85% workspace, sekitar 100.000, memiliki sebagian variabel yang berpotensi terkompromi. Karena cara key tersebut dienkripsi, Railway belum bisa memastikan rahasia mana persisnya di proyek terdampak yang terekspos.
- Penyerang memburu API key penyedia AI dan API key platform. Railway menandai workspace dengan banyak environment variable, atau banyak key AI, sebagai berisiko lebih tinggi.
- Railway menyatakan tidak bisa mengembalikan biaya AI yang dipakai dengan key yang terkompromi. Kamu harus mengurusnya langsung dengan penyedianya.
TechCrunch melaporkan bahwa Railway meyakini serangan ini bagian dari kampanye lebih luas terhadap berbagai platform, yang bertujuan membobol penyedia inferensi AI. Di minggu yang sama, tool coding AI OpenCode mengungkapkan bahwa peretas telah mengambil API key dan rahasia lain dari lebih dari 1% pelanggannya.
Kenapa builder jadi sasaran
Key AI curian bernilai uang sungguhan. Penyerang menjual kembali aksesnya atau menghabiskan kuotamu untuk workload mereka sendiri, pola yang oleh para peneliti disebut LLMjacking. Platform hosting adalah tempat yang efisien untuk memanennya, karena ribuan aplikasi menyimpan key untuk OpenAI, Anthropic, Stripe, dan database mereka di satu tempat.
Ada detail yang tidak nyaman dalam laporan Railway. Variabelnya memang terenkripsi, tetapi platform harus bisa mendekripsinya untuk menyuntikkannya ke build dan layanan yang berjalan. Begitu penyerang mendapat akses internal yang tepat, enkripsi at rest tidak menghentikan mereka. Ini bukan masalah khas Railway. Host mana pun yang menjalankan kodemu bisa membaca rahasiamu.
Jadi pertanyaannya bukan "apakah host-ku aman?" Melainkan "kalau rahasia di host-ku bocor besok, seberapa parah dampaknya, dan seberapa cepat aku bisa pulih?"
Cara mengecek keterpaparanmu
Luangkan 20 menit untuk ini, meskipun kamu sudah mengklik "rotate" untuk beberapa hal.
1. Inventarisasi setiap rahasia. Daftar nama variabel di setiap proyek dan environment, termasuk staging dan environment preview. Kalau kamu punya .env.example, itu titik awal yang bagus:
grep -oE '^[A-Z0-9_]+' .env.exampleUntuk masing-masing, catat apa yang bisa dibukanya: database, penyedia pembayaran, penyedia AI, email, storage bucket, token GitHub.
2. Cek penggunaan dan tagihan penyedia AI-mu. Cari lonjakan penggunaan, model yang tidak kamu kenal, atau request di jam-jam aneh sejak 20 Oktober. Di sinilah penyalahgunaan paling mungkin muncul pertama kali.
3. Cek audit log yang kamu punya. Railway secara khusus menyarankan meninjau audit log GitHub dan akses aplikasi yang terpasang, serta log registry seperti Docker Hub. Lihat juga log API penyedia pembayaranmu dan log koneksi database-mu.
4. Cek apakah database-mu bisa dijangkau dari internet. Laporan Railway merekomendasikan menghapus akses jaringan publik ke database. Kalau connection string yang bocor mengarah ke database yang bisa disambungkan siapa saja, kebocoran itu langsung bisa dimanfaatkan:
nc -zv your-db-host.example 5432 # "succeeded" from your laptop = publicly reachable5. Cek apa yang sudah dibocorkan frontend-mu. Pembobolan seperti ini mengingatkan kita untuk memisahkan rahasia sungguhan dari nilai yang memang publik. Key yang ikut terkirim di bundle JavaScript-mu sejak awal memang tidak pernah rahasia.
Cara merotasi tanpa merusak production
Kesalahan yang sering terjadi saat panik adalah mencabut key lama lebih dulu, lalu buru-buru men-deploy key baru sementara aplikasi mengembalikan error. Lakukan dengan urutan ini:
- Buat kredensial baru di penyedia (API key baru, password database baru, webhook secret baru). Biarkan yang lama tetap aktif untuk sementara.
- Perbarui variabel di host-mu, lalu deploy ulang agar aplikasi yang berjalan memakainya.
- Pastikan aplikasi berjalan dengan nilai baru. Panggil endpoint yang benar-benar memakai layanan itu.
- Cabut kredensial lama di penyedia.
- Pastikan yang lama sudah mati, misalnya dengan melakukan panggilan uji memakai key itu dan memastikan hasilnya gagal.
Kerjakan daftarmu berdasarkan besar dampaknya: key pembayaran, kredensial database, key cloud dan storage, key penyedia AI, token GitHub dan registry, lalu sisanya. Panduan Railway sendiri berfokus pada variabel yang diset sebelum 21 Oktober, dan saran lanjutannya menambahkan menghubungkan ulang GitHub serta membuat ulang kredensial CLI dan CI.
Beberapa rahasia butuh perhatian ekstra:
- Secret untuk menandatangani sesi atau JWT. Mengubahnya akan membuat semua pengguna logout. Setelah pembobolan biasanya itu bisa diterima, tetapi beri tahu pengguna kalau memungkinkan.
- Secret penandatanganan webhook. Perbarui sisi penerima dan penyedia pengirim bersamaan, atau kamu akan menolak event yang sah untuk sementara.
- Password database. Kalau platformmu mendukung, buat user database baru dengan izin yang sama, pindahkan aplikasi ke user itu, lalu hapus user lama. Itu lebih rapi daripada mengganti password di tempat.
Buat pembobolan berikutnya tidak terlalu menyakitkan
Kamu tidak bisa mencegah host-mu dibobol. Tapi kamu bisa membuat rahasia yang bocor jadi kurang berharga.
Batasi cakupan key seketat mungkin. Gunakan restricted key jika penyedia menyediakannya. Restricted key Stripe yang hanya bisa membuat sesi checkout jauh kurang berguna bagi penyerang dibanding secret key penuh.
Batasi pengeluaran. Atur anggaran bulanan dan peringatan penggunaan di setiap penyedia AI. Ini mengubah kejutan tagihan puluhan ribu dolar menjadi sekadar email.
Pisahkan environment. Jangan pakai ulang key production di staging atau deploy preview. Setiap environment harus punya kredensialnya sendiri agar kebocoran di satu tempat tidak sekaligus menyerahkan yang lain.
Jaga database tetap privat. Gunakan private networking dari platformmu, dan kalau kamu memakai Supabase, pastikan Row Level Security aktif agar anon key yang bocor tidak membuka tabel-tabelmu.
Jangan pernah menyimpan rahasia di file yang bisa dijangkau. File .env yang ikut ter-deploy ke web root akan bocor tanpa perlu pembobolan apa pun.
Tulis runbook rotasimu sekarang. Daftar dari langkah 1, urutan di atas, dan di mana setiap key dikelola. Lain kali, rotasi cukup satu jam, bukan satu akhir pekan.
Checklist singkat
Jalankan ini untuk setiap aplikasi yang kamu deploy:
- Setiap rahasia di setiap environment sudah terdaftar, beserta apa yang bisa dibukanya.
- Masing-masing sudah dirotasi dengan urutan buat, deploy, verifikasi, cabut.
- Penggunaan dan tagihan penyedia AI sudah ditinjau sejak 20 Oktober, dan batas pengeluaran sudah diatur.
- Log GitHub, registry, pembayaran, dan database sudah dicek.
- Database tidak bisa dijangkau publik.
- Production dan staging memakai key yang berbeda.
- Tidak ada rahasia sungguhan yang terkirim di kode frontend atau tersimpan di file yang bisa diakses lewat web.
Pelajaran utamanya
Railway melakukan hal yang benar dengan cepat mengungkapkan insiden ini dan mendorong rotasi. Tapi hal seperti ini terus terjadi pada platform hosting dan developer, karena di sanalah key-key disimpan. Builder yang bisa melewatinya dengan tenang adalah mereka yang tahu rahasia apa saja yang dimiliki dan bisa menggantinya dalam satu sore.
Sambil bersih-bersih, ada baiknya juga mengecek apa yang diekspos aplikasimu dari luar. AppSafe memindai situs live-mu untuk masalah umum seperti API key di bundle JavaScript, file .env dan .git yang terekspos, serta security header yang hilang, lengkap dengan perbaikan dalam bahasa sederhana. Checklist peluncuran kami untuk aplikasi buatan AI membahas dasar-dasar lainnya.
Setelah semuanya dirotasi, jalankan scan AppSafe gratis untuk memastikan tidak ada lagi yang bocor.