Insiden keamanan Zeabur Agustus 2026

Semua tanggal dan waktu kejadian dalam artikel ini menggunakan Waktu Universal Terkoordinasi (UTC).

Pada 27 Agustus 2026, seorang penyerang memperoleh akses tidak sah ke sistem Zeabur. Serangan bermula dari kerentanan pada layanan milik pengguna yang dapat diakses publik, lalu meningkat melewati empat batas sistem hingga mencapai jaringan internal klaster bersama, akun platform, akun AWS, dan lingkungan produksi. Kami mengonfirmasi bahwa sebagian database produksi telah dibaca, termasuk informasi akun dan variabel lingkungan proyek yang berisi API key pihak ketiga, kata sandi database, dan kredensial layanan lainnya.

Kami meminta maaf kepada semua pengguna yang terdampak insiden ini. Insiden ini memperlihatkan kekurangan dalam cara kami menyimpan kredensial internal dan membatasi hak aksesnya, cara kami mengisolasi jaringan klaster bersama, serta cara kami memantau dan memberi peringatan atas akses tidak wajar. Sejak itu, penanganan perbaikan dan peningkatan platform telah dijalankan.

Cakupan dampak yang dikonfirmasi

Kami menyandingkan catatan permintaan platform, catatan kueri database produksi, serta catatan access key, penggunaan, dan penagihan AI Hub untuk mengidentifikasi akun, proyek, dan layanan mana saja yang dikueri atau dibaca. Inilah cakupan dampak yang kami konfirmasi sampai saat ini.

Variabel lingkungan proyek

Investigasi kami mengonfirmasi adanya akses tidak sah terhadap nama dan nilai variabel lingkungan proyek. Variabel tersebut berisi API key untuk layanan AI dan layanan pihak ketiga lainnya, kredensial akses cloud, detail koneksi dan kata sandi database, kunci penandatanganan aplikasi, serta pengaturan proyek lainnya. Kami membandingkan proyek dan layanan yang terdampak dengan catatan kueri database produksi untuk menentukan cakupan dampak ini.

Kami telah menyelesaikan penanganan kredensial internal platform. Kami juga mengirim pemberitahuan pertama pada 28 Agustus pukul 08:53 dan pemberitahuan kedua pukul 17:03 di hari yang sama, yang meminta pengguna terdampak untuk mengganti semua kredensial pihak ketiga yang terlibat.

Akun dan AI Hub

Catatan permintaan platform menunjukkan bahwa penyerang mengeksploitasi Zeabur Legacy API Key yang mereka peroleh untuk mengueri akun dan informasi AI Hub, serta untuk membuat access key AI Hub. Setelah pemeriksaan lanjutan pada catatan penggunaan dan penagihan AI Hub, tidak ditemukan penggunaan AI Hub dari kunci-kunci tersebut dan tidak ada biaya AI Hub yang timbul. Kami telah meninjau dan mencabut semua kunci yang dibuat oleh penyerang.

Apa yang terjadi

Jalur insiden yang kami konfirmasi melintasi empat batas sistem. Penyerang pertama-tama mengeksploitasi kerentanan remote code execution (RCE) pada layanan yang terbuka ke publik untuk masuk ke jaringan internal klaster bersama, lalu memperoleh Zeabur Legacy API Key berhak akses tinggi dari cache, dan dengan kunci itu membaca variabel lingkungan sebuah layanan pengelolaan internal. Kunci root AWS di antara variabel tersebut memungkinkan penyerang mengakses infrastruktur cloud kami pada tingkat hak akses tertinggi. Dengan memanfaatkan koneksi jaringan privat dan kredensial database yang sudah ada di klaster bersama, penyerang kemudian mencapai database produksi.

Jalur ini melibatkan dua mekanisme produk lama yang sedang menjalani proses penghentian sebelum insiden terjadi: klaster bersama dan Zeabur Legacy API Key. Kami mengumumkan rencana penghentian klaster bersama pada Februari 2026, menonaktifkan pembuatan proyek baru pada Maret, dan menonaktifkan pembuatan layanan baru di dalam proyek yang sudah ada pada April. Layanan yang terlibat dalam insiden ini telah di-deploy sebelum pengumuman penghentian tersebut dan masih berjalan pada saat kejadian.

Tahap satu: masuk ke jaringan internal klaster bersama melalui layanan publik

Investigasi kami mengonfirmasi bahwa penyerang bermula dari layanan NextChat v2.16.1 yang di-deploy seorang pengguna ke klaster bersama. Catatan runtime layanan tersebut memuat bukti jelas adanya eksploitasi, yang mengarah ke CVE-2026-7644, terkait pemeriksaan otorisasi pada fungsi MCP-nya. Setelah eksekusi kode diperoleh pada layanan itu, aktivitas terkait juga dapat terhubung melalui jaringan internal klaster bersama ke endpoint internal yang dapat dijangkau layanan tersebut.

Cache tersebut awalnya dirancang untuk menyimpan pemetaan antara domain dan layanan, dan juga menyimpan Zeabur Legacy API Key. Begitu penyerang membaca cache itu, akses mereka tidak lagi terbatas pada NextChat.

Kami membandingkan akun dan daftar sumber daya yang terkait dengan penyerang dengan catatan permintaan platform, dan mengonfirmasi bahwa Zeabur Legacy API Key ini berasal dari file cache yang sama. Penyerang kemudian menguji kunci-kunci itu secara batch untuk menemukan yang masih valid dan berhak akses lebih tinggi; salah satunya milik seorang admin tim.

Legacy API Key adalah metode autentikasi awal yang Zeabur sediakan untuk CLI dan skrip otomasi. Rancangan awalnya tidak mendukung scope, sehingga hak akses tidak dibatasi baik menurut operasi dan sumber daya maupun menurut masa berlaku. Inilah salah satu sebab dampak insiden ini meluas.

Semua Zeabur Legacy API Key telah dinonaktifkan. Access Token yang berlaku sekarang mendukung scope, sehingga hak akses dapat dibatasi menurut tujuannya, disertai masa berlaku dan catatan audit yang tersimpan. Sejak insiden ini kami juga telah memperkuat pemeriksaan otorisasi pada API kami.

Tahap dua: dari akses administratif Zeabur ke akun AWS

Penyerang menyalahgunakan Zeabur Legacy API Key milik admin tersebut untuk mendaftar proyek internal dan membaca variabel lingkungan sebuah layanan pengelolaan internal. Variabel tersebut memuat beberapa access key AWS, termasuk kunci pengguna root AWS yang telah lama disimpan. Catatan audit cloud menunjukkan bahwa begitu pengaturan itu dibaca, sumber yang sama segera menguji dan menyalahgunakan kunci-kunci yang terlibat.

Kunci yang disimpan di proyek internal saat itu memiliki hak akses cloud melebihi kebutuhan operasional sehari-hari, dan karena itu kami menilai cakupan insiden ini meluas hingga ke akun AWS.

Tahap tiga: dari AWS dan klaster bersama ke produksi

Setelah memperoleh akses root AWS, penyerang mulai mendaftar sumber daya cloud, lalu masuk ke klaster bersama Tokyo. Catatan audit cloud dan klaster menunjukkan adanya tugas sekali jalan yang tidak wajar serta perubahan hak akses di dalam klaster, termasuk pemberian hak admin klaster kepada sebuah akun layanan. Pada titik ini, penyerang memegang kendali tertinggi atas klaster bersama yang diaksesnya.

Sistem inti Zeabur berjalan di penyedia cloud yang berbeda. Database produksi tidak memiliki titik masuk jaringan publik dan hanya dapat dijangkau melalui jaringan privat. Namun, sebuah tugas pemeliharaan terjadwal yang sudah ada di klaster bersama memiliki konektivitas tersebut.

Tugas terjadwal ini dirancang untuk membersihkan layanan di dalam klaster bersama yang ditentukan, dan karena itu memerlukan konektivitas ke sistem inti. Kredensial database milik tugas tersebut dapat membaca lebih banyak daripada yang sebenarnya dibutuhkan, dan dapat terhubung kembali ke sistem inti melalui jaringan privat. Ketika penyerang menguasai klaster bersama Tokyo, mereka memperoleh akses ke koneksi jaringan sekaligus ke database.

Catatan database mengonfirmasi bahwa penyerang mengambil alih identitas layanan ini untuk membaca variabel lingkungan proyek di produksi. Setelah membandingkan catatan kueri, kami tidak menemukan bukti bahwa data lain ikut dibaca, dan kami telah mencabut kredensial ini serta menghapus jalur dari klaster bersama kembali ke sistem inti.

Tanggung jawab kami dan sebab serangan meluas

Kerentanan NextChat adalah titik masuk awal insiden ini. Sebagai platform yang memungkinkan pengguna men-deploy dan menjalankan aplikasi, kami bertanggung jawab — dan memang seharusnya bertanggung jawab — untuk membatasi jaringan, data, dan hak akses yang dapat dijangkau penyerang ketika sebuah workload disusupi. Kredensial platform yang tersimpan di cache perutean, Legacy API Key tanpa scope maupun masa berlaku, hak akses cloud berlebih yang dipegang sebuah layanan internal, serta tugas pemeliharaan yang sekaligus memiliki konektivitas lintas lingkungan dan kredensial database berhak akses berlebih — semuanya bersama-sama memperluas dampak insiden ini. Klaster bersama dan Legacy API Key sedang menjalani proses penghentian, dan menjaga isolasi serta kontrol akses yang memadai pada keduanya sampai benar-benar berhenti beroperasi merupakan bagian dari proses itu.

Penanganan dan perbaikan

Untuk cakupan terkonfirmasi yang dijelaskan di atas, kami lebih dulu menutup jalur akses yang telah kami identifikasi, lalu menangani kredensial dan lingkungan yang terdampak satu per satu.

Selesai

• Kredensial internal platform: Kami menonaktifkan atau merotasi seluruh kunci administratif internal, kata sandi database, dan kata sandi cache, serta menonaktifkan sepenuhnya autentikasi Zeabur Legacy API Key. Tidak ada kunci lama yang masih bisa dipakai untuk mengakses Zeabur.
• Access key AI Hub: Setiap access key AI Hub yang dikonfirmasi dibuat oleh penyerang telah dicabut. AI Hub masih dinonaktifkan, dan rencana kami untuk layanan ini akan diumumkan terpisah.
• Otorisasi API dan catatan akses: Kami memperkuat pemeriksaan otorisasi pada API yang ada dan menambahkan catatan akses pada Access Token saat ini. Di halaman pengelolaan Access Token, Anda dapat meninjau kapan setiap token mengirim permintaan, dari mana permintaan itu berasal, dan operasi apa yang dijalankan, sehingga Anda dapat mengenali penggunaan yang tidak Anda kenali dan menelusuri akses tidak wajar.
• Jalur akses produksi dan kredensial database: Kami memutus koneksi klaster bersama yang selama ini menuju database produksi, mencabut akun layanan database terkait, dan menghapus hak akses klaster tidak wajar yang kami temukan.
• Layanan internal lama dan klaster bersama: Kami menonaktifkan layanan internal lama yang terlibat dalam insiden ini, memisahkan informasi perutean dari kredensial pengguna, menghapus kredensial dari cache lama, dan merampungkan penggantian host klaster bersama.
• Audit, pemantauan, dan peringatan: Kami melengkapi catatan operasi klaster, jaringan, database, dan cache yang sebelumnya kurang, menambahkan peringatan untuk perubahan hak akses tinggi, penggunaan akun cloud yang tidak wajar, dan kueri database yang mencurigakan, serta mengaktifkan pemantauan keamanan runtime cloud.
• Retensi log dan pemeriksaan keamanan internal: Kami memperpanjang masa simpan data pemantauan, log, dan jejak permintaan, memperbesar kapasitas penyimpanan, dan merampungkan pemeriksaan keamanan mandiri atas perangkat karyawan serta lingkungan pengembangan yang terlibat.

Sedang berjalan

• Penyandingan log lintas sistem: Kami terus membandingkan catatan cloud, klaster, database, dan aplikasi untuk memastikan apakah masih ada aktivitas lain yang berkaitan dengan insiden ini.
• Dukungan, kompensasi, dan pelaporan kepada otoritas: Kami terus memproses permintaan dukungan dan kompensasi dari pengguna terdampak, serta melaporkan hasil investigasi kami kepada otoritas terkait.
• Penggantian kredensial pihak ketiga milik pengguna terdampak: Kami mengirim pemberitahuan pertama pada 28 Agustus pukul 08:53 dan pemberitahuan kedua pukul 17:03 di hari yang sama. Jika Anda belum menuntaskan langkah-langkah tersebut, Anda tetap perlu mencabut kredensial yang tercantum dalam pemberitahuan, membuat kredensial baru, memperbarui pengaturan layanan Anda, men-deploy ulang layanan yang terlibat, serta memeriksa catatan akses dan tagihan.
• Penggantian kredensial preventif: Untuk mengurangi risiko lanjutan, kami menyarankan penggantian setiap kredensial yang pernah disimpan di variabel lingkungan Zeabur dan masih berlaku, termasuk yang tidak tercantum dalam pemberitahuan.

Peningkatan produk dan keamanan

Setelah insiden, kami mengurangi apa yang kami simpan secara terpusat dan membatasi hak akses setiap layanan sebatas yang dibutuhkan pekerjaannya, setelah meninjau cara Zeabur menyimpan dan mengakses informasi rahasia. Pengumuman pembaruan keamanan menjelaskan fitur-fitur ini dan cara menerapkannya.

Sudah diterapkan

Variabel lingkungan disimpan di server Anda sendiri

Metode penyimpanan baru menaruh variabel lingkungan langsung di Dedicated Server Anda, bukan terpusat di database Zeabur.

Layanan baru memakai metode ini secara default. Layanan yang sudah ada dapat dimigrasikan dari halaman variabel lingkungan, dan setelah migrasi selesai, variabel terkait dihapus dari database pusat Zeabur. Saat ini fitur ini hanya berlaku untuk Dedicated Server. Layanan yang berjalan di klaster bersama tidak beralih secara otomatis.

Perubahan ini hanya mengubah cara variabel disimpan. Perubahan ini tidak membatalkan kredensial lama, sehingga kredensial yang terlibat dalam insiden ini tetap perlu diganti.

Menghapus kredensial SSH yang disimpan Zeabur

Untuk server yang baru dibeli, Zeabur tidak lagi menyimpan kata sandi atau kunci privat SSH. Untuk server lama yang mendukung migrasi, kredensial yang disimpan Zeabur juga dapat dihapus dari pengaturan server, tanpa memengaruhi fitur pengelolaan server lainnya. Anda juga dapat meninjau catatan login SSH di konsol Zeabur untuk melihat asal login yang berhasil maupun percobaan login, dan pengaturan firewall memungkinkan Anda membatasi sumber mana saja yang boleh terhubung ke server Anda.

Perbaikan yang terus berjalan

Isolasi dan pemantauan sistem yang sedang dihentikan

Kami akan terus menjaga isolasi, pemantauan, dan kontrol akses pada sistem yang sedang menjalani proses penghentian, sampai workload di dalamnya selesai dimigrasikan atau berhenti berjalan.

Autentikasi, otorisasi, dan audit

Zeabur Access Token sudah mendukung scope, sehingga hak akses dapat dibatasi menurut tujuannya. Kami juga terus memperkuat pemeriksaan scope dan otorisasi pada API yang ada, serta menyesuaikan masa berlaku token login, hak akses komponen, otorisasi sumber daya, dan pencatatan operasi sensitif.

Selama kami menyesuaikan kontrol akses, fitur terkait GitHub, pengelolaan variabel lingkungan, dan email sempat terdampak untuk sementara waktu. Kami sedang memperbaiki cara kami memvalidasi perubahan sebelum diterapkan, agar penyesuaian berikutnya lebih kecil dampaknya terhadap layanan.

Deteksi insiden dan komunikasi dengan pengguna

Kami baru memastikan insiden ini setelah menerima laporan penyalahgunaan API key pada 28 Agustus pukul 02:34. Peninjauan ulang catatan database kemudian menemukan catatan intrusi paling awal pada 27 Agustus pukul 07:54. Pemantauan dan peringatan yang berlaku saat itu tidak mengenali akses tidak sah tersebut.

Pada investigasi awal, bukti yang belum lengkap membuat kami salah menilai cakupan dampak. Kami mengirim pemberitahuan pertama pada 28 Agustus pukul 08:53, lalu yang kedua pukul 17:03. Kami meminta maaf atas ketidaknyamanan karena pemberitahuan pertama itu belum mencakup keseluruhan dampak, dan kami sedang memperbaiki cara kami memverifikasi cakupan serta memberi tahu pengguna, agar panduan penanganan yang akurat dapat kami sampaikan lebih cepat setelah sebuah insiden dipastikan.

Linimasa penting

Tabel berikut memuat linimasa yang telah dikonfirmasi dalam UTC. Waktu pemakaian pertama sebuah kredensial yang tercatat tidak berarti penyerang memperolehnya dan mulai menyalahgunakannya pada saat yang sama.

Pembaruan sebelumnya dapat dilihat di halaman status insiden.

Dukungan dan kompensasi

Jika Anda membutuhkan bantuan, atau menemukan akses tidak wajar maupun tagihan yang tidak dapat Anda jelaskan, hubungi kami melalui Zeabur Support dan kami akan membantu Anda meninjau catatan terkait serta langkah selanjutnya. Sebelum menghubungi kami, mohon:

• Cabut lebih dulu kredensial yang terdampak, untuk mengurangi risiko kredensial itu dipakai kembali.
• Berikan hanya informasi identitas yang sudah disamarkan.
• Jangan menyertakan kunci, kata sandi, atau kredensial lain yang masih utuh dan berlaku di dalam tiket dukungan maupun kanal publik mana pun.

Jika API key sebuah layanan AI pihak ketiga disalahgunakan akibat insiden ini dan menimbulkan tagihan tambahan, silakan ajukan permintaan kompensasi melalui tiket dukungan. Selanjutnya kami akan:

• meninjau bersama Anda catatan penggunaan dari penyedia layanan, periode aktivitas tidak wajar, dan tagihannya
• melanjutkan ke pengaturan kompensasi

Penutup

Kami memahami tambahan tenaga dan ketidaknyamanan yang menyusul insiden ini, yang mengharuskan para pengguna kami mengganti kredensial, memeriksa layanan, dan mencocokkan tagihan. Kami dengan tulus meminta maaf atas risiko dan kerja tambahan yang ditimbulkan insiden ini.

Kami akan terus menjalankan dukungan, kompensasi, dan perbaikan yang telah direncanakan. Perkembangan selanjutnya akan diumumkan di halaman status insiden dan dalam publikasi terkait.

Zeabur Team