Insiden keamanan Zeabur Oktober 2026 (laporan awal)

Semua waktu dalam artikel ini menggunakan Waktu Universal Terkoordinasi (UTC). Investigasi masih berjalan, dan artikel ini akan diperbarui sesuai perkembangannya.

Ringkasan

• Apa yang terjadi: Pada 14–15 Oktober 2026, penyerang memakai kredensial internal Zeabur yang bocor untuk menyusup ke klaster bersama, sebagian Dedicated Server, dan sistem internal Zeabur, hingga akhirnya membaca database platform.
• Titik masuk yang sudah ditutup: Token admin klaster, kunci AWS dan GCP, serta node jaringan internal yang dipakai penyerang telah dicabut atau dihapus, dan akses SSH publik ke antarmuka admin dan server telah diblokir. Semua pengguna telah dikeluarkan dari sesi login, dan semua token akses platform telah dicabut. Menurut catatan yang ada, aktivitas terakhir penyerang terjadi pada 15 Oktober pukul 21:05.
• Siapa yang terdampak: Terutama layanan di klaster bersama dan Dedicated Server GCP. Variabel lingkungan yang disimpan di database platform Zeabur juga ikut dibaca; untuk proyek yang setelah Agustus telah mengikuti panduan dan memigrasikan variabel lingkungannya ke Dedicated Server sendiri, variabel tersebut tidak termasuk dalam cakupan pembacaan database platform.
• Apa yang perlu Anda lakukan: Data yang sudah bocor masih dapat disalahgunakan. Ganti semua kata sandi dan kunci yang disimpan di Zeabur, meskipun Anda sudah menggantinya setelah insiden Agustus. Langkah-langkahnya ada di Apa yang perlu Anda lakukan.
• Akar masalah: Akar masalah insiden ini ada di Zeabur: kredensial admin berumur panjang disimpan dalam teks biasa dan dapat dipakai dari internet publik. Lihat Mengapa ini terjadi.
• Kaitan dengan insiden Agustus: Rotasi pada Agustus tidak mencakup kredensial yang dipakai kali ini; proyek yang telah memigrasikan variabel lingkungannya sesuai panduan Agustus terhindar dari kebocoran database platform. Lihat Kaitan dengan insiden Agustus.

Istilah dalam artikel ini: "Terkonfirmasi" berarti ada log yang mencatatnya secara langsung; "Dinilai" berarti waktu dan isinya cocok, tetapi tidak ada catatan langsung; "Tidak dapat dikonfirmasi" berarti tidak ada catatan yang dapat diperiksa, dan kami selalu memperlakukannya sebagai sudah bocor; "Hipotesis" berarti penjelasan yang mungkin dan hanya didukung bukti tidak langsung, yang dikumpulkan di Hipotesis yang belum terbukti.

Apa yang terjadi

Penyerang menempuh dua jalur, yang akhirnya bertemu di jaringan internal Zeabur.

Jalur A: klaster bersama dan AWS

1. Sejak 14 Oktober pukul 01:36, penyerang memakai kunci AWS internal Zeabur, dan sejak pukul 01:40 memakai token admin klaster bersama. Kredensial ini disimpan dalam teks biasa di repositori konfigurasi privat Zeabur. Bagaimana penyerang memperolehnya saat ini tidak dapat dikonfirmasi; kami menduga hal ini berkaitan dengan kunci privat GitHub App yang bocor dalam insiden Agustus, lihat Hipotesis yang belum terbukti.
2. Antarmuka admin klaster bersama saat itu terbuka ke internet publik, dan token admin tidak memiliki masa berlaku. Karena itu, penyerang dapat mengakses klaster bersama di 9 region dari luar.
3. Sejak pukul 01:51, penyerang membaca sebagian rahasia sistem. Sejak pukul 12:39, cakupannya meluas ke pengaturan dan rahasia semua layanan, termasuk variabel lingkungan. Di region yang memiliki catatan pembacaan lengkap, pembacaan isinya terkonfirmasi; di region lain catatannya tidak ada, dan kami memperlakukannya sebagai sudah bocor.
4. Sejak pukul 13:40, penyerang menjalankan perintah baca di dalam container database milik pengguna. Awalnya beberapa new-api/one-api, lalu sejak pukul 15:41 membaca n8n secara massal, sejak pukul 16:50 membaca sebagian PostgreSQL tabel demi tabel, dan perintah terakhir tercatat pukul 17:04. Secara keseluruhan, penyerang menjalankan perintah di 865 layanan database, tetapi tidak semua perintah berhasil.
5. Penyerang memakai kunci lain di klaster yang hak aksesnya berlebih untuk membaca cadangan sebuah klaster lama (Dinilai). Cadangan itu berisi kunci yang dapat membaca layanan pengelolaan rahasia Zeabur.
6. Pada 15 Oktober pukul 14:52 hingga 16:51, penyerang membaca sekitar 53 rahasia produksi (Terkonfirmasi). Di antaranya kredensial admin jaringan internal, akun database platform, dan kunci privat GitHub App.

Jalur B: Dedicated Server GCP

1. Sejak 14 Oktober pukul 13:40, penyerang login sebagai root ke Dedicated Server yang dikelola Zeabur di GCP, sebanyak 101 server.
2. Konfigurasi inisialisasi server-server ini menyimpan kata sandi root dalam teks biasa. Penyerang memegang sebuah kunci GCP lama yang dapat membaca konfigurasi tersebut. Kami menilai penyerang memperoleh kata sandi itu dengan kunci tersebut.
3. Sejak 15 Oktober pukul 14:26, penyerang memakai kunci GCP lama untuk mengubah konfigurasi server dan menambahkan kunci SSH miliknya. Pukul 15:05, penyerang memperoleh lagi sebuah kunci GCP produksi dari layanan pengelolaan rahasia. Setelah kami menonaktifkan kunci lama pukul 17:17, penyerang beralih ke kunci ini pukul 17:28 untuk kembali menambahkan kunci SSH, dan kami juga menonaktifkannya pukul 17:31. Login pertama ke server GCP pada 14 Oktober terjadi lebih awal daripada catatan pembacaan rahasia produksi pertama yang diketahui pada 15 Oktober; yang kedua tidak dapat disebut sebagai titik awal yang pertama.
4. Sebelumnya, pada 1–5 September, sumber yang tidak diketahui sudah login dengan kata sandi root ke kelompok server yang sama, sekitar 98 server pada 5 September saja. Apakah ini penyerang yang sama saat ini tidak dapat dikonfirmasi.

Kedua jalur bertemu

1. Pada 15 Oktober pukul 15:30, di salah satu server GCP yang disusupi, penyerang memakai kredensial admin jaringan internal yang diperoleh dari Jalur A untuk menggabungkan sebuah node ke jaringan internal Zeabur.
2. Aturan jaringan internal mengizinkan node seperti ini terhubung ke database platform. Pukul 16:10 hingga 16:47, penyerang membaca database platform dengan akun internal baca-saja (Terkonfirmasi). Kami mencocokkan catatan koneksi di kedua sisi jaringan internal dengan log database. Ke-29 koneksi database selama periode ini semuanya dapat dikaitkan dengan node tersebut, dan login serta kueri di dalam koneksi itu dapat ditelusuri satu per satu, dengan total 8.903 catatan operasi.
3. Pukul 17:58, kami menghapus node tersebut.

Sebagian kredensial yang dirotasi selama insiden kemudian tetap digunakan tanpa izin. Cadangan harian klaster Zeabur menyimpan semua rahasia, dan penyerang membaca kunci akses cadangan tersebut pada 15 Oktober pukul 15:04. Kunci baru yang kami pasang pukul 15:40 ikut tersimpan dalam cadangan pukul 16:00; penyerang memakainya pukul 20:30. Kami menghapus kunci akses cadangan pukul 18:51, dan merotasi kembali kredensial yang terdampak pukul 21:47. Bahwa kunci baru tersimpan dalam cadangan lalu dipakai kemudian, keduanya terkonfirmasi; apakah penyerang mengunduh cadangan ini termasuk dinilai. Penyerang mungkin sudah memperoleh cadangan itu sebelum pukul 18:51, jadi pemakaian pukul 20:30 tidak berarti cadangan masih dapat diunduh setelah pukul 18:51.

Data apa yang terdampak

Database platform. Pada 15 Oktober pukul 16:10 hingga 16:47, penyerang membaca data dalam tabel di atas. Data akun mencakup informasi di halaman profil, seperti email, nama pengguna, dan nomor ponsel. Penyerang juga mencari API key dan kunci privat di variabel lingkungan dan file konfigurasi. Dilihat dari isi perintah dan perilaku selanjutnya, penyerang terutama mencari API key yang dapat langsung dipakai, khususnya kunci layanan AI: penyerang mencari kunci di database platform, membaca kredensial di n8n dan new-api/one-api secara massal, dan juga mencoba memanggil Amazon Bedrock dengan kunci AWS milik Zeabur. Ini hanya pengamatan atas niat penyerang; penyerang juga membaca data akun, dan kami tetap memperlakukan semua data yang terbaca sebagai sudah bocor. Untuk tabel data autentikasi dua faktor dan passkey, yang dikueri hanya informasi statistiknya, dan tidak ada catatan pembacaan isinya. Kami telah mencabut token akses platform semua pengguna, dan token lama tidak dapat dipakai lagi.

Variabel lingkungan yang sudah dimigrasikan tidak termasuk dalam cakupan pembacaan database platform. Setelah insiden Agustus, Zeabur menyediakan panduan dan fitur bagi pengguna Dedicated Server untuk merotasi kredensial, menghapus variabel lingkungan dan file konfigurasi yang disimpan di Zeabur, serta memigrasikannya dengan sekali klik ke server mereka sendiri. Untuk proyek yang sudah selesai bermigrasi, data ini hanya tersimpan di server pengguna dan tidak disimpan Zeabur, sehingga tidak termasuk dalam data database platform yang dibaca kali ini. Untuk proyek yang belum bermigrasi, variabel lingkungan masih tersimpan di Zeabur dan kali ini juga ikut dibaca. Hal ini tidak menutup kemungkinan kebocoran akibat penyusupan host; Dedicated Server GCP yang disusupi tetap perlu mengikuti saran penanganan di bawah.

Penyamaran akun. Penyerang membaca kunci yang dipakai untuk menerbitkan kredensial login, dan kami menilai penyerang memakainya untuk memalsukan kredensial login. Penyerang baru membaca token akses platform secara massal pukul 16:47, dan token hanya disimpan sebagai nilai hash, sehingga hal itu tidak dapat menjelaskan penyamaran yang sudah dimulai pukul 16:12. Pada 15 Oktober pukul 16:12 hingga 17:19, penyerang memanggil API Zeabur atas nama dua akun untuk membaca daftar akun dan proyek; salah satunya adalah akun karyawan Zeabur. Permintaan ini tidak mengubah sumber daya apa pun. Kami merotasi kunci penandatanganan pukul 20:25, dan semua pengguna telah dikeluarkan dari sesi login.

Database di klaster bersama. Penyerang menjalankan perintah baca di dalam container 865 database. Catatan audit hanya mencatat perintah, bukan outputnya, dan sebagian perintah gagal karena error, sehingga berapa banyak data yang benar-benar terbaca dari setiap database tidak dapat dikonfirmasi. Kami menilainya berdasarkan isi perintah:

Dari n8n yang memakai PostgreSQL, 602 (dari 607 yang diperiksa) menuliskan kunci enkripsinya di variabel lingkungan, sehingga kredensial pihak ketiga di dalam n8n setara dengan bocor dalam teks biasa. Karena pembacaan data ini terjadi di dalam container, rotasi kata sandi database setelah insiden Agustus tidak memutus jalur akses ini.

Selain itu, setidaknya 2 PostgreSQL di region Tokyo (hnd1) telah disisipi program yang terhubung balik ke luar sejak 14 Oktober pukul 01:51, dan salah satunya masih terhubung balik pada 15 Oktober pukul 16:24. Apakah titik masuknya adalah kata sandi yang bocor pada Agustus saat ini tidak dapat dikonfirmasi. Kami telah memberi tahu pengguna terdampak untuk mengganti kredensial segera setelah hal ini ditemukan.

Dedicated Server GCP. Investigasi mengonfirmasi bahwa penyerang pernah login dengan hak akses root ke 101 server, terakhir kali pada 15 Oktober pukul 20:36. Di 50 server di antaranya, penyerang juga menambahkan kunci publik SSH yang dikendalikannya untuk membangun akses berkelanjutan. Penyerang juga membuat 5 mesin virtual di proyek GCP Zeabur dan memasang 16 salinan disk server pelanggan ke mesin virtual tersebut.

Berdasarkan cakupan akses tersebut, ke-101 server ini dikategorikan sebagai host terdampak yang mungkin mengalami kebocoran data dan mungkin masih memiliki mekanisme akses tanpa izin. Kami telah memberi tahu pengguna terdampak melalui email dan mengatur ulang kata sandi root server-server tersebut.

Hetzner dan DigitalOcean. Token untuk mengelola server pelanggan di kedua penyedia ini tertulis di kode internal dan variabel lingkungan, dan ikut bocor bersama database platform. Pemegang token dapat mereset kata sandi, menginstal ulang sistem, atau menyalin disk. Kami mencabut semua token tersebut pada 16 Oktober pukul 01:09. Kedua penyedia tidak memiliki catatan audit operasi; semua kejadian di akun Hetzner dapat dikaitkan dengan pengguna sendiri atau jadwal sistem, sedangkan DigitalOcean masih dicocokkan.

Linode dan Tencent Cloud. Dari 890 server Linode, 847 server yang memiliki catatan tidak menunjukkan login penyerang. Kredensial admin Tencent Cloud tidak memiliki catatan pemakaian.

GitHub App. Penyerang membaca kunci privat GitHub App Zeabur pada 15 Oktober pukul 15:05. Pemegang kunci privat dapat mengakses repositori yang diotorisasi pengguna untuk diakses Zeabur. Kami merotasi kunci privat itu pukul 18:54, dan sejauh ini tidak ditemukan pemakaiannya. Kami telah meminta catatan audit lengkap kepada GitHub Support dan belum menerima balasan.

Sistem internal Zeabur. Penyerang memakai beberapa kunci AWS milik Zeabur. Sebagian besar permintaan ditolak, tetapi penyerang berhasil mendaftar isi cadangan database pengguna di dua region dan isi unggahan kode sumber; apakah semuanya diunduh tidak dapat dikonfirmasi. Penyerang mencoba memanggil Amazon Bedrock, tetapi semuanya gagal dan tidak menimbulkan biaya.

Apa yang telah kami lakukan

Selesai

Kami juga menonaktifkan kredensial Tencent Cloud, Alibaba Cloud, dan Linode yang tertanam di kode, menghapus kunci SSH penyerang dari server GCP, dan mengamankan catatan audit dari setiap sistem.

Setelah itu, kami juga telah menyelesaikan:

• Mencabut token akses platform semua pengguna.
• Merotasi rahasia produksi lain yang terbaca, termasuk akun dan kata sandi database platform, serta mencabut kredensial lain yang bocor.
• Mengirim email kepada pengguna Dedicated Server GCP dan mereset kata sandi root server.
• Membatasi koneksi ke database platform hanya untuk layanan tertentu.
• Cadangan klaster tidak lagi menyimpan rahasia dalam teks biasa, dan kunci cadangan disimpan terpisah dari rahasia lainnya.
• Menghapus salinan disk, snapshot, dan sumber daya uji yang ditinggalkan penyerang.

Sedang berjalan

• Menelusuri sumber kebocoran repositori konfigurasi, kunci GCP lama, dan login server pada awal September.
• Menambahkan peringatan untuk: pemakaian hak akses admin yang tidak wajar, eksekusi perintah di dalam container, pembacaan rahasia atau database secara massal, node baru yang bergabung ke jaringan internal, dan pemakaian kunci cloud dari sumber yang tidak dikenal.

Dampak terhadap layanan

Apa yang perlu Anda lakukan

Tangani sekarang juga, tanpa menunggu email pemberitahuan. Kredensial yang sudah Anda ganti setelah insiden Agustus juga perlu diganti sekali lagi.

Semua pengguna

1. Ganti semua kredensial di variabel lingkungan. Termasuk API key, kunci cloud, kata sandi database, serta kunci penandatanganan dan enkripsi. Cabut dulu kredensial lama di penyedia layanan, lalu buat yang baru dan deploy ulang. Untuk proyek yang setelah Agustus telah memigrasikan variabel lingkungannya ke Dedicated Server sendiri, variabel tersebut tidak termasuk dalam cakupan pembacaan database platform kali ini; jika host itu sendiri disusupi, kredensial yang tersimpan di host tetap perlu diganti.
2. Login ulang dan buat ulang Access Token. Semua token akses platform lama telah dicabut. Buat token baru di halaman pengelolaan Access Token, dan periksa apakah ada permintaan yang tidak Anda kenali.
3. Pengguna zSend: Buat ulang API key zSend.
4. Pengguna GitHub: Periksa catatan audit GitHub Anda untuk operasi dari GitHub App Zeabur pada 15 Oktober pukul 15:05 hingga 18:54. Perhatikan hal-hal berikut:
   • clone atau push yang tidak terduga
   • deploy key yang baru ditambahkan
   • webhook yang diubah
5. Periksa tagihan. Periksa penggunaan dan tagihan setiap layanan sejak 14 Oktober 2026; pengguna Dedicated Server GCP perlu menelusuri hingga 1 September. 14 Oktober adalah waktu paling awal yang kami ketahui saat ini untuk pemakaian kredensial oleh penyerang, dan tidak berarti kredensial belum bocor sebelumnya; jika ada catatan yang lebih awal, periksa juga.

Pengguna klaster bersama

1. Ganti kata sandi di dalam database. Mengubah variabel lingkungan di Zeabur saja tidak mengubah kata sandi di dalam database. Mengganti kata sandi juga tidak membuat data yang sudah bocor menjadi tidak berlaku; jika database Anda menyimpan hash kata sandi, sesi login, atau token milik pengguna Anda, cabut dan buat ulang semuanya.
2. n8n: Ganti kunci enkripsi n8n, dan buat ulang semua kredensial pihak ketiga di dalam n8n.
3. new-api/one-api: Cabut kunci layanan AI upstream, dan buat ulang token akses.
4. PostgreSQL: Periksa apakah ada role, function, trigger, tugas terjadwal, atau extension yang tidak Anda kenali. Jika ragu, buat database baru dan impor datanya saja.
5. Region Taipei (tpe1) dan Hong Kong (hkg1): Perlakukan data di cadangan database sebagai sudah bocor.

Pengguna Dedicated Server GCP

Perlakukan server sebagai sudah disusupi:

1. Cadangkan data, lalu bangun ulang server. Ini cara paling andal untuk menghapus backdoor.
2. Jika belum dapat membangun ulang, setidaknya:
   • Hapus kunci di /root/.ssh/authorized_keys yang berkomentar @zeabur-pentest atau yang tidak Anda kenali.
   • Periksa grup google-sudoers, akun sistem, crontab, layanan systemd, dan workload k3s.
   • Ganti kata sandi root, dan nonaktifkan login SSH dengan kata sandi.
3. Ganti semua kredensial di server, termasuk kredensial cloud milik Anda sendiri, dan periksa tagihan terkait.
4. Periksa catatan login berdasarkan indikator penyusupan, ditelusuri hingga 1 September 2026.

Pengguna Dedicated Server Hetzner dan DigitalOcean

Di konsol, periksa apakah kata sandi root direset atau sistem diinstal ulang setelah 14 Oktober, dan pastikan tidak ada metode login yang tidak dikenal sesuai daftar pemeriksaan GCP di atas.

Mengapa ini terjadi

Pemicu: Penyerang memegang token admin klaster Zeabur dan beberapa kunci cloud. Kredensial ini disimpan dalam teks biasa di repositori konfigurasi. Bagaimana penyerang memperolehnya saat ini tidak dapat dikonfirmasi; jalur yang paling mungkin dijelaskan di Hipotesis yang belum terbukti.

Faktor yang memperluas dampak:

• Siklus hidup token admin dan kontrol akses antarmuka. Token admin tidak memiliki masa berlaku, tidak pernah dirotasi sejak dibuat pada Januari 2024, dan tidak termasuk dalam rotasi setelah insiden Agustus. Antarmuka admin dapat diakses dari internet publik.
• Penyimpanan rahasia dan kemajuan perbaikan. Kunci yang disimpan dalam teks biasa ada di repositori konfigurasi, kode, serta konfigurasi layanan dan job build di klaster bersama. Konfigurasi inisialisasi server GCP juga menyimpan kata sandi root; masalah ini sudah teridentifikasi pada 3 September, tetapi belum selesai diperbaiki sebelum insiden. Perubahan migrasi rahasia yang dimulai pada 3 Oktober belum digabungkan ke branch utama saat insiden terjadi.
• Isi cadangan dan isolasi kunci. Cadangan klaster berisi semua rahasia, dan kunci akses cadangan disimpan di lingkungan yang sama dengan rahasia lain, sehingga menjadi jalur tambahan untuk mengakses isi cadangan. Sebagian kredensial yang dirotasi selama insiden juga ikut tersimpan di cadangan berikutnya.
• Izin akses dan cakupan sumber daya.
  • Kunci yang hanya perlu membaca satu ruang penyimpanan ternyata dapat membaca seluruh ruang penyimpanan di akun AWS.
  • Akun layanan default di server GCP memiliki izin ubah di tingkat proyek.
  • Aturan jaringan internal mengizinkan node dengan tag tertentu terhubung ke database platform.
  • Akun database internal hanya-baca dapat membaca semua data.
  • Deploy key milik layanan yang sudah dihentikan masih berlaku empat bulan setelah layanan itu dihentikan.
• Isolasi lingkungan antara layanan internal dan layanan pengguna. Keduanya berjalan di klaster yang sama, sehingga saat membaca konfigurasi pengguna, penyerang juga dapat memperoleh kredensial layanan internal.
• Cakupan deteksi dan log audit. Aktivitas serangan lebih dari 16 jam pada 14 Oktober tidak memicu peringatan; tim mengidentifikasi insiden keesokan harinya setelah menerima laporan pengguna. Karena catatan akses penyimpanan, GCP, dan GitHub tidak lengkap, sebagian akses dan cakupan dampak hingga kini masih tidak dapat dikonfirmasi.

Kaitan dengan insiden Agustus

Ini adalah insiden keamanan kedua Zeabur dalam waktu kurang dari dua bulan. Banyak pengguna telah melakukan penyesuaian sesuai panduan kami setelah Agustus, dan wajar jika mereka bertanya: mengapa insiden ini tetap terjadi meski langkah-langkah itu sudah diambil, dan apakah kedua insiden saling berkaitan.

Apa yang dilakukan setelah Agustus. Kami merotasi kunci internal yang saat itu terkonfirmasi bocor, dan menonaktifkan Legacy API Key. Di sisi produk, proyek Dedicated Server dapat memigrasikan variabel lingkungan dan file konfigurasi ke server sendiri, menghapus kredensial SSH yang disimpan Zeabur, dan meninjau catatan login SSH. Dalam pemberitahuan dan pengumuman insiden Agustus, kami juga menyarankan pengguna merotasi kredensial, menghapus variabel lingkungan dan file konfigurasi yang disimpan di Zeabur, serta bermigrasi ke server sendiri.

Mengapa tetap terjadi. Rotasi pada Agustus tidak mencakup token admin klaster dan kunci AWS yang disimpan dalam teks biasa di repositori konfigurasi, dan kata sandi root di konfigurasi inisialisasi server GCP juga belum diperbaiki. Kredensial inilah yang dipakai penyerang kali ini. Laporan insiden Agustus menyatakan "menonaktifkan atau merotasi seluruh kunci administratif internal"; pernyataan itu tidak lengkap, dan kami mengoreksinya di sini. Bagaimana penyerang memperoleh kredensial ini saat ini tidak dapat dikonfirmasi; dugaan kami dijelaskan di Hipotesis yang belum terbukti.

Apa yang berhasil. Untuk proyek yang telah menyelesaikan migrasi sesuai panduan Agustus, variabel lingkungan dan file konfigurasi hanya tersimpan di server milik pengguna sendiri, dan tidak termasuk dalam data database platform yang dibaca kali ini.

Linimasa

Hal yang belum jelas dan keterbatasan investigasi

Hal-hal berikut belum dapat dikonfirmasi karena keterbatasan cakupan atau kelengkapan catatan yang ada. Untuk data dan kredensial yang tidak dapat dipastikan bebas dari akses tanpa izin, kami mengambil langkah penanganan dengan asumsi data tersebut mungkin telah bocor.

• Cara kredensial awal diperoleh. Log audit GitHub yang tersedia tidak mencakup operasi clone dan hanya mencatat unduhan arsip. Catatan menunjukkan bahwa repositori konfigurasi diunduh melalui otorisasi GitHub milik seorang karyawan pada 30 Agustus dan 2 September, tetapi siapa yang melakukannya belum dapat dikonfirmasi. Kami telah meminta catatan lengkap kepada GitHub. Penilaian kami saat ini ada di Hipotesis yang belum terbukti.
• Cakupan data yang benar-benar dibaca dari database di klaster bersama. Log audit menyimpan perintah yang dijalankan, tetapi tidak mencatat outputnya, sehingga data yang benar-benar diperoleh tidak dapat dikonfirmasi sepenuhnya.
• Cakupan unduhan cadangan dan objek penyimpanan. Bukti di host yang disusupi mengonfirmasi bahwa pada 15 Oktober pukul 15:42 penyerang memperoleh cadangan database pelanggan melalui URL unduhan yang telah ditandatangani sebelumnya. Bukti ini berbeda dari cadangan klaster yang dinilai terkait dengan kebocoran kredensial internal; apakah cadangan klaster tersebut diunduh belum dapat dikonfirmasi. Karena pencatatan akses objek belum diaktifkan saat itu, cakupan unduhan objek lain dan cadangan klaster masih belum dapat dikonfirmasi sepenuhnya.
• Cakupan pembacaan sumber daya GCP. Catatan proyek GCP yang tersedia tidak mencakup operasi baca; saat ini hanya operasi tulis yang dapat dikonfirmasi.
• Penggunaan token Hetzner dan DigitalOcean. Kedua penyedia tidak menyediakan log audit operasi yang dapat dipakai untuk investigasi ini, sehingga belum dapat dikonfirmasi apakah token tersebut digunakan.
• Isi spesifik hasil kueri database platform. Kueri yang dijalankan penyerang, serta jumlah catatan yang dikembalikan oleh 7 kueri utama, sudah dikonfirmasi. Namun, log database tidak mencatat isi yang dikembalikan, dan cara penyerang kemudian menyimpan atau menggunakan data tersebut juga tidak dapat dikonfirmasi.
• Cakupan aktivitas di sebagian klaster. Log audit klaster Taipei (tpe0) dan klaster khusus tempat penyerang membuat sumber daya tidak lengkap, sehingga membatasi verifikasi aktivitas terkait.
• Aktivitas dan dampak sebelum 14 Oktober. Dalam catatan klaster bersama dan AWS yang tersedia, tidak ada aktivitas yang memakai kredensial sah sebelum 14 Oktober pukul 01:36. Sebagian IP yang kemudian terlibat penyalahgunaan kredensial sudah muncul sejak 10 Oktober di catatan akses API Zeabur tanpa login; namun, IP tersebut mungkin dipakai bersama oleh layanan proxy, sehingga kesamaan IP saja tidak dapat memastikan identitas operatornya. Pada 13 Oktober juga ada percobaan login SSH ke Dedicated Server, dan semuanya gagal. Saat ini belum dapat dikonfirmasi apakah terjadi kebocoran data pada periode tersebut.

Hipotesis yang belum terbukti

Berikut adalah penjelasan yang saat ini kami anggap paling mungkin. Penjelasan ini didukung bukti tidak langsung, tetapi tidak memiliki catatan langsung, sehingga tidak dapat dikutip sebagai fakta. Kami akan memperbarui atau menariknya setelah memperoleh bukti baru.

1. Kredensial awal mungkin berasal dari insiden Agustus

• Hipotesis: Penyerang memanfaatkan kunci privat GitHub App yang bocor dalam insiden Agustus untuk memperoleh isi repositori konfigurasi privat Zeabur, termasuk kunci AWS dan token admin klaster yang dipakai pada 14 Oktober.
• Saat ini tidak ada bukti yang secara langsung membuktikan jalur ini. Berikut hanya petunjuk tidak langsung yang cocok dari segi waktu dan kemampuan.
• Apa yang diganti dan apa yang tidak:
  • Kunci privat GitHub App: sudah diganti. Dalam insiden Agustus, kunci privat ini terbaca pada 27 Agustus. Berdasarkan catatan audit GitHub dan waktu versi di layanan pengelolaan rahasia, kunci privat diganti pada 31 Agustus, sehingga periode yang dapat dimanfaatkan sekitar 4 hari. App ini terpasang di organisasi GitHub Zeabur, dan pemegang kunci privatnya dapat membaca semua repositori di organisasi tersebut.
  • Kredensial teks biasa di repositori konfigurasi: tidak diganti. Kunci AWS dan token admin klaster yang pertama kali dipakai penyerang pada 14 Oktober sudah ada dalam teks biasa di repositori konfigurasi pada 27 Agustus. Setelah insiden Agustus, kami hanya mengganti kunci privat, tidak mengganti kredensial ini, dan baru menonaktifkannya saat penanganan insiden pada 15 Oktober. Karena itu, meskipun kunci privat sudah diganti, jika seseorang memperoleh isi repositori antara 27 dan 31 Agustus, kredensial di dalamnya masih berlaku hingga Oktober.
• Petunjuk tidak langsung lainnya:
  • Sebagian nama rahasia internal yang dicoba dibaca penyerang hanya muncul di repositori internal lain. Penyerang mungkin memegang isi kedua repositori sekaligus, dan ini sesuai dengan hak akses tingkat organisasi milik kunci privat App.
  • Sebelum 14 Oktober pukul 01:36, tidak ada catatan pemakaian kredensial yang valid di klaster bersama dan AWS, dan IP yang kemudian menyalahgunakan kredensial juga tidak pernah login di API Zeabur. Ini sesuai dengan situasi "hanya memegang kredensial dari repositori".
• Petunjuk yang tidak mendukung: IP penyerang dalam insiden Agustus dan insiden ini tidak tumpang tindih.
• Perkembangan pengumpulan bukti: Kami telah meminta catatan terkait kepada GitHub Support, termasuk token akses yang diterbitkan App ini antara 27 dan 31 Agustus, catatan clone dan unduhan repositori konfigurasi, serta sumber unduhan repositori konfigurasi dengan otorisasi karyawan pada 30 Agustus dan 2 September. Hingga artikel ini diperbarui, kami belum menerima balasan. Sebelum catatan tersebut diperoleh, jalur ini hanyalah hipotesis; unduhan dengan otorisasi karyawan juga tidak dapat dikesampingkan sebagai jalur perolehan lain.

2. Penyelidikan sebelum 14 Oktober mungkin merupakan pengintaian oleh penyerang yang sama

• Hipotesis: Penyelidikan anonim dan percobaan SSH pada 10–13 Oktober adalah pengintaian oleh penyerang yang sama sebelum memakai kredensial.
• Bukti yang mendukung:
  • 103.237.102.191: mengunjungi Zeabur tanpa login pada 10 Oktober pukul 18:27, dan mengakses klaster bersama dengan token admin pada 14 Oktober.
  • 23.106.46.239: sejak 12 Oktober pukul 12:52 melakukan banyak percobaan ke API Zeabur tanpa login, pada 13 Oktober mencoba login SSH ke Dedicated Server, dan pada 14 Oktober pukul 01:36 pertama kali memakai kunci AWS yang bocor.
• Belum terbukti: Penyerang banyak memakai server proxy, dan satu IP mungkin dipakai bersama oleh orang yang berbeda, sehingga kesamaan IP saja tidak dapat memastikan bahwa pelakunya orang yang sama.

3. Akses deploy key pada 15 Oktober mungkin dilakukan penyerang

• Hipotesis: Pada 15 Oktober pukul 15:02, deploy key milik layanan yang sudah dinonaktifkan membaca repositori konfigurasi, yang dinilai dilakukan oleh penyerang.
• Bukti yang mendukung: Akses ini terjadi selama penyerang membaca rahasia produksi (14:52 hingga 16:51); layanan pemilik kunci itu sudah dinonaktifkan selama empat bulan, sehingga seharusnya tidak ada akses normal.
• Belum terbukti: Saat ini tidak ada catatan yang dapat mengaitkan akses ini secara langsung dengan penyerang.

4. Kunci pengguna yang bocor mungkin sudah disalahgunakan

• Hipotesis: Pada 16 Oktober pukul 01:50 hingga 02:56, API key OpenAI milik seorang pengguna yang disimpan di Zeabur dipakai untuk mengirim sekitar 1.107 permintaan pembuatan gambar. Kami menduga kunci ini berasal dari variabel lingkungan yang bocor dalam insiden ini.
• Belum terbukti: Tidak dapat dikesampingkan bahwa kunci ini bocor melalui jalur lain. Inilah juga alasan artikel ini menyarankan semua pengguna mengganti kunci, lihat Apa yang perlu Anda lakukan.

Indikator penyusupan

Jika Anda menemukan indikator berikut di sistem Anda atau di catatan penyedia layanan, perlakukan kredensial terkait sebagai sudah bocor dan hubungi kami. Penyerang banyak memakai server proxy yang berganti-ganti, sehingga tabel di bawah hanya mencantumkan alamat yang representatif.

Penjelasan istilah

• Klaster bersama (Shared Cluster): Klaster Kubernetes tempat layanan banyak pengguna berjalan bersama. Kami telah mengumumkan penghentiannya pada Februari 2026, dan semua layanan yang terdampak di-deploy sebelum pengumuman tersebut.
• Dedicated Server: Server yang dikelola Zeabur dan hanya menjalankan layanan milik satu pengguna.
• Token admin: Kredensial yang dapat mengelola seluruh klaster; pemegangnya dapat membaca pengaturan semua layanan dan menjalankan perintah di container mana pun.
• Layanan pengelolaan rahasia: Layanan AWS yang dipakai Zeabur untuk menyimpan rahasia produksi secara terpusat.
• Jaringan internal: Jaringan privat (Tailscale) yang menghubungkan layanan produksi Zeabur; database platform hanya menerima koneksi dari jaringan ini.
• Database platform: Database produksi Zeabur yang menyimpan semua akun, proyek, layanan, dan variabel lingkungan.

Informasi lebih lanjut

Jika Anda membutuhkan bantuan, atau menemukan akses tidak wajar maupun biaya yang tidak dikenal, hubungi kami melalui Zeabur Support. Sebelum menghubungi kami, cabut dulu kredensial terkait, dan berikan hanya informasi yang sudah disamarkan; jangan menempelkan kunci atau kata sandi yang masih berlaku di tiket maupun kanal publik.

Jika API key pihak ketiga atau akun cloud Anda menimbulkan biaya tambahan akibat insiden ini, ajukan permintaan kompensasi melalui tiket dukungan. Kami akan memeriksa catatan penggunaan dan biaya dari penyedia layanan, lalu menjelaskan hasil pemeriksaannya.

Zeabur telah mengumumkan akan berhenti beroperasi pada 31 Desember 2026; ini adalah keputusan operasional. Sampai saat itu, kami akan terus menangani permintaan dukungan dan kompensasi terkait insiden ini, serta terus memperbarui artikel ini dan halaman status. Kami meminta maaf kepada semua pengguna yang terdampak.

Zeabur Team