Insiden keamanan Zeabur Oktober 2026

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

Pada 15 Oktober 2026 pukul 13:56, kami menerima laporan dari pengguna dan memulai investigasi. Setelah mencocokkan catatan, kami baru mengetahui bahwa penyerang sudah memakai kredensial internal Zeabur sejak 14 Oktober pukul 01:36, sekitar 36 jam sebelum kami menyadarinya. Selama itu penyerang memakai kredensial yang sah dan jalur akses resmi Zeabur, sehingga tidak ada satu pun peringatan yang terpicu.

Penyerang masuk lewat dua jalur yang bertemu di jaringan internal Zeabur pada 15 Oktober, lalu membaca database platform. Kredensial yang dipakai kali ini tidak tercakup dalam rotasi mana pun setelah insiden Agustus.

Yang perlu Anda lakukan

Tangani sekarang juga, tanpa menunggu email pemberitahuan. Data yang sudah bocor masih dapat disalahgunakan, dan 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 sudah memindahkan variabel lingkungannya ke Dedicated Server sendiri, variabel tersebut tidak termasuk dalam data database platform yang dibaca kali ini. Namun, 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: Di catatan audit GitHub, periksa 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 untuk pemakaian kredensial oleh penyerang, tetapi kredensial mungkin sudah bocor lebih awal, jadi periksa juga catatan yang lebih lama jika ada.

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 Anda 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, lalu pastikan tidak ada metode login yang tidak dikenal dengan mengikuti daftar pemeriksaan GCP di atas.

Dampak

Rincian untuk setiap sistem ada di bawah.

Database platform

Pada 15 Oktober pukul 16:10 hingga 16:47, penyerang membaca data yang tercantum di tabel di atas. Data akun mencakup informasi di halaman profil, seperti email, nama pengguna, dan nomor ponsel. Dari tabel autentikasi dua faktor dan passkey, yang dikueri hanya informasi statistiknya, dan tidak ada catatan pembacaan isinya. Token akses platform hanya disimpan sebagai nilai hash, tetapi tetap kami cabut semuanya.

Penyerang terutama mencari API key yang bisa langsung dipakai, khususnya kunci layanan AI. Penyerang mencari API key dan kunci privat di variabel lingkungan dan file konfigurasi, membaca kredensial di n8n dan new-api/one-api secara massal, dan mencoba memanggil Amazon Bedrock dengan kunci AWS milik Zeabur. Ini pengamatan kami berdasarkan isi perintah dan perilaku penyerang sesudahnya. Penyerang juga membaca data akun, dan semua data yang terbaca kami perlakukan sebagai sudah bocor.

Setelah insiden Agustus, Zeabur menyediakan panduan dan fitur migrasi sekali klik bagi pengguna Dedicated Server: merotasi kredensial, menghapus variabel lingkungan dan file konfigurasi yang disimpan di Zeabur, lalu menyimpannya di server sendiri. Untuk proyek yang sudah bermigrasi, data ini hanya ada di server pengguna dan tidak termasuk dalam data yang dibaca kali ini. Untuk proyek yang belum bermigrasi, variabel lingkungan masih tersimpan di Zeabur dan kali ini ikut terbaca. Kebocoran akibat penyusupan host tidak termasuk dalam pengecualian ini: Dedicated Server GCP yang disusupi tetap perlu ditangani sesuai Yang perlu Anda lakukan.

Penyamaran akun

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.

Penyerang membaca kunci yang dipakai untuk menerbitkan kredensial login, dan kredensial login yang dipakai dinilai dipalsukan dengan kunci ini. Token akses platform hanya disimpan sebagai nilai hash, dan penyerang baru membacanya secara massal pukul 16:47, sehingga token itu tidak dapat menjelaskan penyamaran yang sudah dimulai pukul 16:12. Pukul 20:25, kami merotasi kunci penandatanganan, 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. Tabel berikut adalah penilaian kami berdasarkan isi perintah:

Kami memeriksa 607 n8n yang memakai PostgreSQL, dan 602 di antaranya menuliskan kunci enkripsinya di variabel lingkungan. Akibatnya, kredensial pihak ketiga di dalam n8n sama saja dengan bocor dalam teks biasa. Pembacaan ini terjadi di dalam container, jadi rotasi kata sandi database setelah insiden Agustus tidak melindungi dari pembacaan semacam ini.

Selain itu, di region Tokyo (hnd1) setidaknya 2 PostgreSQL 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 tidak dapat dikonfirmasi. Begitu hal ini ditemukan, kami memberi tahu pengguna terdampak untuk mengganti kredensial.

Dedicated Server GCP

Penyerang pernah login dengan hak akses root ke 101 server, terakhir kali pada 15 Oktober pukul 20:36. Di 50 server di antaranya, penyerang menambahkan kunci publik SSH yang dikendalikannya agar tetap bisa login di kemudian hari. Penyerang juga membuat 5 mesin virtual di proyek GCP Zeabur dan memasang 16 salinan disk server pelanggan ke mesin-mesin itu.

Ke-101 server ini kami perlakukan sebagai server yang datanya mungkin sudah bocor dan mungkin masih memiliki backdoor. Kami telah mengirim email kepada pengguna terdampak dan mereset kata sandi root server-server tersebut.

Hetzner, DigitalOcean, Linode, dan Tencent Cloud

Token untuk mengelola server pelanggan di Hetzner dan DigitalOcean 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 itu pada 16 Oktober pukul 01:09. Kedua penyedia tidak menyediakan API audit operasi, sehingga apakah token dipakai tidak dapat dikonfirmasi. Kami hanya dapat mengesampingkan satu hal: reset kata sandi dan pembuatan image di Hetzner pada 15 Oktober dilakukan oleh pelanggan sendiri dan oleh jadwal sistem. Untuk DigitalOcean, tidak ada hasil pencocokan.

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

GitHub App

Pada 15 Oktober pukul 15:05, penyerang membaca kunci privat GitHub App Zeabur. Pemegang kunci privat ini dapat mengakses repositori yang diizinkan pengguna untuk diakses Zeabur. Kami merotasi kunci privat itu pukul 18:54. Apakah kunci itu dipakai tidak dapat dikonfirmasi: kami tidak memperoleh catatan audit lengkap organisasi GitHub, dan permintaan catatan kami kepada GitHub Support tidak pernah dibalas.

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 isinya diunduh tidak dapat dikonfirmasi. Semua upaya penyerang memanggil Amazon Bedrock gagal dan tidak menimbulkan biaya.

Dampak terhadap layanan

Kronologi kejadian

Penyerang menempuh dua jalur. Jalur A bergerak dari klaster bersama ke AWS dan layanan pengelolaan rahasia Zeabur, sedangkan Jalur B memperoleh hak akses root ke Dedicated Server GCP. Pada 15 Oktober, kedua jalur bertemu di jaringan internal Zeabur. Teknik MITRE ATT&CK untuk setiap langkah tercantum di lampiran.

Jalur A: dari klaster bersama ke layanan pengelolaan rahasia

1. Memperoleh kredensial. Pada 14 Oktober pukul 01:36, penyerang mulai memakai kunci AWS internal Zeabur, lalu pukul 01:40 mulai memakai token admin klaster bersama. Kedua kredensial ini disimpan dalam teks biasa di repositori konfigurasi privat Zeabur, di konfigurasi yang sama dengan alamat koneksi setiap klaster. Bagaimana penyerang memperolehnya tidak dapat dikonfirmasi; dugaan kami ada di Hipotesis yang belum terbukti.
2. Masuk ke klaster bersama. Token admin tidak memiliki masa berlaku, dan antarmuka admin klaster saat itu terbuka ke internet publik, sehingga penyerang dapat masuk dari luar ke klaster bersama di 9 region. Sejak pukul 01:51 penyerang membaca sebagian rahasia sistem, dan 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; region lainnya kami perlakukan sebagai sudah bocor.
3. Membaca database pengguna. 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. Totalnya 865 layanan database, dan tidak semua perintah berhasil.
4. Memperoleh kunci layanan pengelolaan rahasia dari cadangan. 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.
5. Membaca rahasia produksi. 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: hak akses root ke Dedicated Server GCP

1. Login ke server. Sejak 14 Oktober pukul 13:40, penyerang login sebagai root ke Dedicated Server yang dikelola Zeabur di GCP, sebanyak 101 server. Saat server-server ini dibuat, kata sandi root ditulis dalam teks biasa di konfigurasi inisialisasi dan tidak dihapus setelah penyiapan selesai. Platform sendiri juga perlu login ke server dengan kata sandi ini, sehingga yang disimpan adalah teks biasa, bukan nilai hash. Kunci GCP lama yang dipegang penyerang dapat membaca konfigurasi ini, dan kata sandi itu dinilai diperoleh dengan cara tersebut.
2. Menambahkan kunci SSH. Sejak 15 Oktober pukul 14:26, penyerang memakai kunci GCP lama untuk mengubah konfigurasi server dan menambahkan kunci SSH miliknya. Pukul 15:05, penyerang juga memperoleh sebuah kunci GCP produksi dari layanan pengelolaan rahasia.
3. Mencoba lagi dengan kunci lain. Kami menonaktifkan kunci lama pukul 17:17. Penyerang beralih ke kunci yang baru diperolehnya 11 menit kemudian dan kembali menambahkan kunci SSH. Pukul 17:31, kunci ini juga kami nonaktifkan.

Login ini terjadi pada 14 Oktober, lebih dari sehari sebelum pembacaan rahasia produksi paling awal yang diketahui di Jalur A (15 Oktober pukul 14:52). Jadi, titik awal Jalur B tidak dapat dijelaskan dengan rahasia yang dibaca lewat Jalur A. Pada 1–5 September, sumber yang tidak diketahui juga pernah login dengan kata sandi root ke kelompok server yang sama, sekitar 98 server pada 5 September saja. Apakah ini penyerang yang sama tidak dapat dikonfirmasi.

Kedua jalur bertemu

1. Bergabung ke jaringan internal. Pada 15 Oktober pukul 15:30, di salah satu server GCP yang disusupi, penyerang memakai kredensial admin jaringan internal dari Jalur A untuk menggabungkan sebuah node ke jaringan internal Zeabur.
2. Membaca database platform. 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).
3. Menghapus node. Pukul 17:58, kami menghapus node tersebut.

Kesimpulan bahwa database platform dibaca berasal dari catatan koneksi di kedua sisi jaringan internal dan log database. Ke-29 koneksi database selama periode ini semuanya dapat dikaitkan dengan node tersebut, dan login serta kueri di dalamnya dapat ditelusuri satu per satu, dengan total 8.903 catatan operasi.

Deteksi

Kami baru memulai investigasi pada 15 Oktober pukul 13:56, setelah menerima laporan pengguna. Saat itu sudah sekitar 36 jam berlalu sejak penyerang pertama kali memakai kredensial (14 Oktober pukul 01:36), dan aktivitas serangan pada 14 Oktober saja berlangsung lebih dari 16 jam.

Selama periode itu tidak ada peringatan sama sekali:

• Penyerang memakai kredensial yang sah melalui jalur akses resmi Zeabur. Di catatan, aktivitasnya tidak berbeda dari operasi admin biasa.
• Saat itu belum ada peringatan untuk perilaku semacam ini, misalnya pemakaian hak akses admin yang tidak wajar, eksekusi perintah di dalam container, pembacaan rahasia secara massal, node baru yang bergabung ke jaringan internal, atau pemakaian kunci cloud dari sumber yang tidak dikenal.

Penanganan

Penahanan

Sekitar 4 jam setelah investigasi dimulai, kami menghapus node jaringan internal milik penyerang. Berikut penanganan pada 15–16 Oktober:

Kunci yang diganti selama insiden tetap dipakai penyerang

Sebagian kredensial yang kami pasang pada hari penanganan kemudian tetap dipakai penyerang. Masalahnya ada pada cadangan harian klaster. Cadangan ini mencakup semua sumber daya di klaster, termasuk rahasia, dan penyerang membaca kunci akses cadangan tersebut pada 15 Oktober pukul 15:04:

1. Pukul 15:40, kami memasang kunci baru.
2. Pukul 16:00, cadangan harian ikut menyimpan kunci baru ini.
3. Pukul 18:51, kami menghapus kunci akses cadangan.
4. Pukul 20:30, penyerang memakai kunci baru tersebut.
5. Pukul 21:47, kami merotasi lagi kredensial yang terdampak.

Bahwa kunci baru tersimpan di cadangan lalu dipakai kemudian, keduanya terkonfirmasi; bahwa penyerang mengunduh cadangan ini, statusnya dinilai. Kunci yang dipakai pukul 20:30 juga mungkin berasal dari cadangan yang sudah diperoleh penyerang sebelum pukul 18:51.

Pemberantasan dan pemulihan

• Menghapus kunci SSH penyerang dari Dedicated Server GCP, mereset kata sandi root, dan mengirim email kepada pengguna terdampak.
• Menghapus salinan disk, snapshot, dan sumber daya uji yang ditinggalkan penyerang.
• Mencabut token akses platform semua pengguna.
• Menonaktifkan kredensial Tencent Cloud, Alibaba Cloud, dan Linode yang tertanam di kode.
• Merotasi rahasia produksi lain yang terbaca, termasuk akun dan kata sandi database platform, serta mencabut kredensial lain yang bocor.
• Mengamankan catatan audit dari setiap sistem.
• Semua fitur yang terdampak sudah pulih. Periode dampak setiap fitur ada di Dampak terhadap layanan.

Akar masalah

Sejak awal, penyerang sudah memegang token admin klaster Zeabur dan beberapa kunci cloud. Kredensial ini disimpan di repositori konfigurasi privat Zeabur dalam teks biasa, mengikuti kebiasaan lama. Kemungkinan terbesar, repositori konfigurasi ini bocor, tetapi jalur kebocorannya tidak dapat dikonfirmasi; dugaan kami ada di Hipotesis yang belum terbukti.

Celah yang membuka jalan ke database platform

• Token admin tanpa masa berlaku, dan antarmuka admin terbuka ke internet publik. Token dibuat pada Januari 2024 dan tidak pernah dirotasi sejak itu, termasuk dalam rotasi setelah insiden Agustus.
• Rahasia disimpan dalam teks biasa. Kunci dalam teks biasa ada di repositori konfigurasi, kode, konfigurasi layanan di klaster bersama, dan job build. Konfigurasi inisialisasi server GCP menyimpan kata sandi root; masalah ini sudah kami temukan pada 3 September, tetapi belum diperbaiki sebelum insiden. Migrasi rahasia yang dimulai pada 3 Oktober juga belum digabungkan ke branch utama saat insiden terjadi.
• Cadangan menyimpan semua rahasia, dan kunci cadangan disimpan bersama rahasia lain. Karena itu penyerang dapat memperoleh lebih banyak kredensial dari cadangan, dan sebagian kredensial yang dipasang selama insiden ikut tersimpan di cadangan berikutnya.
• Hak akses melebihi kebutuhan.
  • Kunci yang hanya perlu membaca satu ruang penyimpanan ternyata dapat membaca semua ruang penyimpanan di akun AWS.
  • Akun layanan default server GCP memiliki izin ubah di tingkat proyek.
  • Aturan jaringan internal mengizinkan node dengan tag tertentu terhubung ke database platform, dan kredensial admin jaringan internal dapat langsung memberi tag itu kepada node baru.
  • Akun database internal baca-saja dapat membaca semua data.
  • Deploy key milik layanan yang sudah dihentikan masih berlaku empat bulan setelah layanan itu dihentikan.
• Layanan internal dan layanan pengguna berjalan di klaster yang sama. Saat membaca konfigurasi pengguna, penyerang sekaligus memperoleh kredensial layanan internal.
• Deteksi dan pencatatan tidak memadai. Serangan berlangsung sekitar 36 jam tanpa memicu peringatan, lihat Deteksi. Catatan akses penyimpanan, GCP, dan GitHub tidak lengkap, sehingga sebagian akses dan cakupan dampak tidak dapat ditelusuri.

Kaitan dengan insiden Agustus

Ini adalah insiden keamanan kedua Zeabur dalam waktu kurang dari dua bulan. Banyak pengguna sudah melakukan penyesuaian sesuai panduan kami setelah Agustus, dan ingin tahu mengapa insiden ini tetap terjadi meski langkah-langkah itu sudah diambil, serta 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 memindahkan variabel lingkungan dan file konfigurasi ke server sendiri, menghapus kredensial SSH yang disimpan Zeabur, dan melihat 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, lalu 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.

Evaluasi

Yang sudah tepat

• Untuk proyek yang sudah bermigrasi 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.
• Sekitar 4 jam setelah investigasi dimulai, kami menghapus node jaringan internal milik penyerang. Pada hari yang sama, kami juga memblokir akses internet publik ke antarmuka admin klaster dan ke Dedicated Server GCP.
• Catatan koneksi di kedua sisi jaringan internal dan log database lengkap, sehingga cakupan pembacaan database platform dapat dipastikan entri demi entri.

Yang keliru

• Rotasi setelah insiden Agustus tidak mencakup kredensial yang dipakai kali ini, dan pernyataan di laporan insiden Agustus tidak lengkap. Lihat Kaitan dengan insiden Agustus.
• Pada 3 September kami sudah menemukan bahwa konfigurasi inisialisasi server GCP menyimpan kata sandi root, tetapi tidak memperbaikinya sebelum insiden.
• Kunci yang dipasang pada hari penanganan ikut tersimpan di cadangan harian, dan sebagian kemudian tetap dipakai penyerang. Lihat Kunci yang diganti selama insiden tetap dipakai penyerang.
• Serangan berlangsung sekitar 36 jam dan baru diketahui dari laporan pengguna. Lihat Deteksi.

Tindak lanjut

Zeabur akan berhenti beroperasi pada 31 Desember 2026, jadi di bawah ini hanya tercantum perbaikan yang sudah dijalankan.

Hal yang belum terungkap

Hal yang tidak dapat dipastikan

Karena keterbatasan catatan yang ada, hal-hal berikut tetap tidak dapat dipastikan hingga laporan ini difinalkan. Data dan kredensial yang tidak dapat dipastikan bebas dari akses penyerang kami perlakukan sebagai sudah bocor.

• Dari mana kredensial awal berasal. Log audit GitHub hanya mencatat unduhan arsip, bukan operasi clone. Catatan menunjukkan bahwa pada 30 Agustus dan 2 September, seseorang mengunduh repositori konfigurasi dengan otorisasi GitHub milik seorang karyawan, tetapi siapa orangnya tidak dapat dikonfirmasi. Kami meminta catatan lengkap kepada GitHub Support, dan pada akhirnya tidak mendapat balasan.
• Dari mana kunci GCP lama bocor. Kami sudah memeriksa riwayat git, layanan pengelolaan rahasia, dan cadangan klaster lama, tetapi tidak menemukan titik kebocorannya. Apakah 31.57.201.201, yang login dengan kata sandi root ke Dedicated Server GCP pada awal September, adalah penyerang yang sama juga belum dapat disimpulkan.
• Berapa banyak data yang benar-benar dibaca dari database di klaster bersama. Log audit menyimpan perintah, tetapi tidak mencatat outputnya. Kami hanya tahu perintah apa saja yang dijalankan penyerang.
• 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. Cadangan ini berbeda dari cadangan klaster yang berisi kredensial internal. Untuk cadangan database di Taipei (tpe1) dan Hong Kong (hkg1) serta ruang penyimpanan unggahan kode sumber, yang terkonfirmasi hanya bahwa daftar objeknya pernah diambil. Pencatatan akses objek belum diaktifkan saat itu, sehingga apakah objek-objek itu diunduh tidak dapat dikonfirmasi. Untuk pembacaan cadangan klaster lama juga tidak ada bukti langsung, sehingga statusnya tetap dinilai.
• Cakupan pembacaan sumber daya GCP. Saat itu proyek GCP belum mengaktifkan log audit akses data, sehingga hanya operasi tulis yang tercatat, dan tidak ada cara lain untuk memeriksanya kemudian.
• Apakah token Hetzner dan DigitalOcean dipakai. Kedua penyedia tidak menyediakan API audit operasi. Selain operasi di Hetzner pada 15 Oktober yang sudah terkonfirmasi dilakukan oleh pelanggan sendiri dan oleh jadwal sistem, sisanya tidak dapat dikonfirmasi.
• Apakah kunci privat GitHub App dipakai. Kami tidak memperoleh catatan audit lengkap organisasi GitHub, dan GitHub Support tidak membalas.
• Apa yang dikembalikan oleh kueri ke database platform. Kami sudah mengonfirmasi kueri yang dijalankan penyerang, jumlah entri yang dikembalikan oleh 7 kueri utama, dan bahwa 14 koleksi mengembalikan data. Kueri-kueri utama itu terbaca sampai entri terakhir. Log database tidak mencatat isi yang dikembalikan, dan kami juga tidak dapat mengetahui bagaimana penyerang kemudian menyimpan atau memakai data tersebut.
• Cakupan aktivitas di sebagian klaster. Log audit klaster Taipei (tpe0) dan klaster khusus tempat penyerang membuat sumber daya tidak lengkap, dan setelah itu tidak diselidiki lebih lanjut.
• Apa yang terjadi sebelum 14 Oktober. Di catatan klaster bersama dan AWS, tidak ada aktivitas yang memakai kredensial sah sebelum 14 Oktober pukul 01:36. Sebagian IP yang kemudian menyalahgunakan kredensial sudah muncul sejak 10 Oktober di catatan akses API Zeabur tanpa login. Namun, IP tersebut mungkin server proxy yang dipakai bersama banyak orang, sehingga kesamaan IP saja tidak dapat memastikan bahwa pelakunya orang yang sama. Pada 13 Oktober juga ada percobaan login SSH ke Dedicated Server, dan semuanya gagal. Apakah ada data yang bocor pada periode ini tidak dapat dikonfirmasi.

Hipotesis yang belum terbukti

Berikut penjelasan yang menurut kami paling mungkin. Penjelasan ini didukung bukti tidak langsung, tetapi tidak memiliki catatan langsung, sehingga tidak dapat dikutip sebagai fakta. Hingga laporan ini difinalkan, tidak ada hipotesis yang terbukti maupun terbantahkan.

Hipotesis 1: kredensial awal 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. Tidak ada bukti yang membuktikan jalur ini secara langsung; yang ada 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. Jadi, meskipun kunci privat sudah diganti, siapa pun yang memperoleh isi repositori antara 27 dan 31 Agustus masih memegang kredensial yang berlaku hingga Oktober.
• Petunjuk lain yang mendukung:
  • 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 sah 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.
• Mengapa tidak dapat dibuktikan: Kami meminta kepada GitHub Support 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. GitHub Support pada akhirnya tidak membalas. Unduhan dengan otorisasi karyawan itu juga tidak dapat dikesampingkan sebagai jalur perolehan lain.

Hipotesis 2: penjajakan sebelum 14 Oktober adalah pengintaian oleh penyerang yang sama

• Hipotesis: Penjajakan anonim dan percobaan SSH pada 10–13 Oktober adalah pengintaian oleh penyerang yang sama sebelum memakai kredensial.
• Petunjuk 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.
• Mengapa tidak dapat dibuktikan: 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.

Hipotesis 3: akses deploy key pada 15 Oktober dilakukan penyerang

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

Lampiran

Linimasa

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. Tingkat kepercayaan memakai skala STIX 0 sampai 100: Terkonfirmasi 85, Dinilai 60, dan Tidak dapat dikonfirmasi 30. Versi yang dapat dibaca mesin tersedia di file STIX 2.1, dan indikator IP di dalamnya berlaku hingga 13 Januari 2027.

Pemetaan MITRE ATT&CK

Diurutkan berdasarkan taktik MITRE ATT&CK.

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.

Dukungan dan biaya

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 kredensial yang bocor disalahgunakan, Anda mungkin harus menanggung biaya tambahan, dan kami sungguh menyesal atas hal itu. Dengan kondisi keuangan saat ini, Zeabur tidak dapat menanggung biaya layanan pihak ketiga yang timbul akibat insiden ini. Sebagian besar penyedia cloud dan API memiliki jalur pengajuan keberatan atau keringanan biaya, dan Anda dapat melampirkan laporan ini sebagai penjelasan kepada penyedia. Jika penyedia meminta bukti lain, beri tahu kami melalui tiket, dan kami akan berusaha menyediakannya. Pengembalian saldo akun tidak terpengaruh oleh insiden ini. Rinciannya ada di Tindak lanjut Zeabur atas insiden keamanan Oktober 2026.

Zeabur telah mengumumkan akan berhenti beroperasi pada 31 Desember 2026; ini adalah keputusan operasional. Sampai saat itu, kami akan terus menangani permintaan dukungan terkait insiden ini.

Kami baru mengetahui insiden ini dari laporan pengguna, sekitar 36 jam setelah penyerang mulai memakai kredensial. Melindungi kredensial yang Anda simpan di Zeabur adalah tanggung jawab kami, dan kami gagal melakukannya. Kami meminta maaf kepada semua pengguna yang terdampak.

Tim Zeabur