ZCode Mengemas 42.411 File ke dalam Arsip yang Hanya Bisa Dibuka oleh Zhipu

Pada 18 September 2026, seorang developer yang menulis dengan nama ferstar menerbitkan pembongkaran ZCode, agen coding AI desktop buatan pengembang model asal Tiongkok Zhipu AI, setelah menyadari bahwa sebuah folder tersembunyi di direktori home-nya telah tumbuh melewati 700 MB. Di dalamnya ia menemukan arsip terenkripsi 313 MB berisi 42.411 file yang diambil dari ruang kerja 345 MB, 86,6% di antaranya adalah riwayat Git, dikemas oleh klien dan disiapkan untuk diunggah ke penyimpanan objek Alibaba Cloud. Arsip itu disegel dengan kunci yang hanya bisa dibuka oleh server Zhipu, dan klien tidak menawarkan opsi yang menghentikan pembuatannya. Zhipu meminta maaf pada malam yang sama. Catatan lengkapnya, beserta tingkat keyakinan dan status bahaya dari arsip itu sendiri, berada di Orca AI Incident Archive, yang mencatat setiap insiden AI terdokumentasi terhadap sumber yang dikutipnya.

ZCode adalah agen coding desktop milik Zhipu: ia membaca proyek, menjalankan perintah shell, dan menulis kode. Perusahaan itu diperdagangkan di Hong Kong dengan ticker 2513.HK dan menamai divisi internasionalnya sebagai Z.ai, nama yang muncul di server ZCode yang diperiksa ferstar. The Paper, media berita Shanghai yang mewawancarainya dan beberapa pengembang lain setelahnya, melaporkan bahwa postingannya berjudul, kira-kira, "Menyingkap tabir pengunggahan diam-diam seluruh riwayat Git oleh ZCode," dan bahwa postingan itu menyebar di grup-grup pengembang Tiongkok dalam beberapa jam setelah diterbitkan.

Apa yang ada di dalam folder tersembunyi itu?

Angka Ferstar sendiri adalah tulang punggung kasus ini, dan angka-angka itu telah direproduksi secara konsisten oleh The Next Web, InfoQ, dan desk keuangan China National Radio. Arsip di direktori checkpoint ZCode miliknya berukuran 313 MB. File status di sampingnya mencatat workspace sekitar 345 MB dan 42,411 file. Direktori .git menyumbang 86.6% dari payload: 196.1 MB cache penyimpanan file besar Git, 102.2 MB objek Git yang membawa riwayat commit lengkap, dan sebagian kecil reflog. Kode sumber dan dokumentasi sebenarnya berjumlah sekitar 13.4%.

Perbedaan ini penting karena riwayat Git adalah tempat materi yang telah dihapus dari pohon saat ini cenderung bertahan. Uraian Paper menegaskan hal itu secara langsung: arsip semacam ini dapat memuat riwayat penyuntingan sebuah proyek sejak commit pertamanya, konten yang telah dihapus, draf yang belum di-commit, dan file konfigurasi lama, termasuk kredensial yang telah lama dihapus dari kode tetapi tetap ada dalam commit sebelumnya dan dalam cache file besar.

Arsip 313 MB milik Ferstar sendiri tidak pernah meninggalkan mesinnya. Log statusnya menunjukkan 564 percobaan unggah yang gagal, dan arsip itu tersendat dalam status tertunda, melebihi batas ukuran. Untuk menguji apakah pipeline itu berfungsi sama sekali, ia mencoba repositori publik kecil berisi 538 file; snapshot itu dikompresi dan dienkripsi menjadi sekitar 15 KB dan diterima oleh server. Transfer itulah yang dalam catatan dikonfirmasi telah selesai dari awal hingga akhir, dan itulah yang mengubah temuan dari sekadar latihan membaca kode menjadi eksfiltrasi dengan ujung penerima yang terbukti.

Perekaman tidak terkait dengan tindakan apa pun yang akan dikenali pengguna sebagai "unggah repositori saya." Menurut rekonstruksi ferstar, satu pemicu aktif sebelum setiap prompt dikirim ke model, dan satu lagi berjalan sebagai tugas pembaruan Repo Wiki. Menghapus arsip tertunda tidak menghentikannya: sebuah tulisan di komunitas pengembang Tencent Cloud mencatat bahwa paket tersebut dibangun ulang dalam waktu 30 menit dan penghitung kegagalan naik dari 564 menjadi 565. Satu-satunya cara penghentian yang andal yang ditemukan penulis tersebut adalah membuat direktori checkpoint tidak dapat ditulisi sehingga perekaman gagal pada penulisan disk, dengan konsekuensi kehilangan rollback checkpoint dan antarmuka timeline.

Kunci yang hanya dapat digunakan oleh vendor

Enkripsinya adalah envelope encryption yang standar, dan itulah bagian yang tidak dapat diakali pengguna. Rekonstruksi InfoQ, yang disusun dari reverse engineering ferstar, menjelaskan bahwa klien mengambil ID snapshot, kunci publik RSA, dan kredensial unggah Alibaba Cloud OSS dari zcode.z.ai, mengemas dan mengenkripsi workspace secara lokal, lalu mengirim ciphertext langsung ke OSS. Konten dienkripsi dengan AES-256-CTR; kunci simetrisnya dibungkus dengan RSA-OAEP-SHA256 menggunakan kunci publik server, yang bagian privatnya tetap berada di cloud Zhipu.

Perutean sama pentingnya dengan kriptografi. Karena klien mengunggah langsung ke Alibaba Cloud, bukan melalui server aplikasi milik Zhipu sendiri, lalu lintas tersebut tidak melewati layanan Zhipu yang dapat mencatat log atau memfilternya, jadi tidak ada layanan Zhipu yang berada di jalur untuk mencatat log atau memfilter apa yang keluar. Dan karena kunci privat tidak pernah ada di perangkat, ferstar tidak dapat membuka arsipnya sendiri: The Next Web melaporkan bahwa ia mencoba setiap kunci privat di mesinnya dan gagal. Dalam unggahannya, ia menggambarkan pengaturan tersebut sebagai kunci yang hanya dapat digunakan server, yang memiliki satu tujuan.

Dua pengaturan di klien tampaknya seharusnya menghentikan ini, dan tidak satu pun yang melakukannya. Tombol "optimalkan pengalaman" mengatur apakah data dapat digunakan untuk pelatihan model; tombol "pengindeksan snapshot repositori" mengatur apakah server membangun indeks atas snapshot yang sudah tiba. Keduanya bekerja di hilir perekaman. Ferstar menemukan perekaman berjalan tanpa syarat, dan The Next Web melaporkan bahwa pembacaannya atas kebijakan privasi menemukan kebijakan itu menjelaskan pengumpulan teks percakapan dan file tetapi tidak menyebut apa pun tentang snapshot ruang kerja otomatis yang membawa riwayat Git lengkap.

Penjelasan yang diberikan Zhipu, dan empat hari setelahnya

Zhipu merespons pada hari yang sama, melalui grup pengguna resmi ZCode dan bukan melalui siaran pers. Sebagaimana dilaporkan oleh Global Times dan diterbitkan ulang oleh Security Inside, perusahaan mengaitkan perilaku tersebut dengan fitur bernama pengindeksan basis kode, yang mendukung pengindeksan lokal, pemulihan checkpoint sesi, rollback versi, dan pembuatan Repo Wiki, serta menyatakan bahwa langkah Repo Wiki itulah yang memicu unggahan repositori ke cloud. Fitur tersebut telah aktif secara default sejak peluncuran. Zhipu mengatakan data yang diunggah hanya digunakan untuk membuat halaman Repo Wiki dan langsung dihancurkan setelahnya, bahwa data tersebut tidak disimpan dan tidak digunakan untuk pelatihan, serta meminta maaf kepada pengguna yang terdampak. Perusahaan berjanji akan membuka basis kode ZCode sebagai sumber terbuka, mengundang tinjauan pihak ketiga, dan mempublikasikan hasilnya, serta menawarkan kepada setiap pengguna ZCode satu reset kuota mingguan tambahan sebagai kompensasi.

Perbaikan itu tiba keesokan harinya. The Paper melaporkan bahwa ZCode 3.14.0 dirilis pada 19 September dengan entri changelog yang berbunyi “memperbaiki masalah unggahan abnormal pada wiki repositori,” dan bahwa ferstar mengonfirmasi pada hari yang sama bahwa rantai unggahan dan endpoint-nya telah tidak ada lagi. Pada 20 September, platform MaaS Zhipu mengumumkan opsi retensi nol yang akan datang, yang membuat input dan output tidak disimpan secara statis; The Paper mencatat bahwa opsi ini bersifat opt-in melalui pengajuan permohonan, mengecualikan Batch API dan File API, dan masih memungkinkan penyimpanan selama 30 hari atau lebih jika hukum atau penyelidikan penyalahgunaan mensyaratkannya. Pada 21 September, kode sumber klien dipublikasikan di GitHub dengan lisensi Apache 2.0, mencakup aplikasi desktop, klien web, backend, CLI agen, dan runtime agen.

Dua audit dilakukan dan kesimpulannya diterbitkan dalam bentuk ringkasan. China Academy of Information and Communications Technology menemukan bucket OSS Alibaba Cloud zcode-prod dalam kondisi yang oleh Zhipu disebut sebagai keadaan nol data. Perusahaan keamanan NSFOCUS melaporkan bahwa setiap objek data dan bucket itu sendiri telah dihapus, dan bahwa pihaknya tidak menemukan jalur tersisa di ZCode 3.14.0 yang dapat memicu snapshot repositori lokal atau mengirim file keluar. Laporan penilaian lengkap belum muncul, dan The Next Web melaporkan bahwa Zhipu belum memberikan tanggal untuk laporan tersebut.

Pelanggan yang mengklaim lebih banyak, lalu menariknya kembali.

Klaim kehilangan aktual yang paling serius tidak datang dari ferstar. Pada 19 September, menurut China National Radio, Taiyuan Chengming Technology mengirimkan surat hukum kepada Zhipu bernomor Chengming [2026] Legal Letter No. 1, yang direproduksi secara rinci oleh ChainCatcher. Perusahaan itu menyatakan enam ruang kerja coding miliknya telah diunggah tanpa persetujuan—34.500 file dan sekitar 425 MB dalam bentuk teks polos—dan mencantumkan kode sumber lengkap, arsitektur sistem, riwayat versi, kata sandi basis data, kredensial cloud, serta informasi pribadi karyawan. Perusahaan itu menyebut ruang kerja ketujuh dengan 1.947 file dan sekitar 144 MB telah dikemas dan dienkripsi tetapi gagal setelah 32 kali percobaan ulang unggahan. Perusahaan itu juga mencatat bahwa kliennya telah diperbarui ke versi 3.12.3 pada 16 September, namun unggahan masih terdeteksi pada pukul 00.28 tanggal 18 September, pagi ketika Zhipu meminta maaf.

Surat itu mengajukan pertanyaan yang tidak dijawab oleh audit-audit: apakah data keluar dari negara. Chengming mengatakan permintaan jaringan ZCode mengarah ke entitas Singapura sementara perjanjian layanannya ditandatangani dengan Beijing Zhipu Huazhang, dan surat itu meminta Zhipu mengidentifikasi pihak mana yang bertanggung jawab dan apakah terjadi transfer atau penyimpanan di luar Tiongkok daratan. Surat itu memuat dua belas tuntutan, termasuk menghapus semua data yang diunggah dan turunannya, cache dan cadangan dengan sertifikat tertulis, menjelaskan ke mana data itu pergi dan apakah dibagikan kepada pihak ketiga atau digunakan untuk pelatihan, menjelaskan bagaimana kunci privat disimpan dan menyediakan log akses, mendefinisikan cakupan persis klaim "dihancurkan", dan berkomitmen secara tertulis untuk tidak pernah mengunggah lagi. Surat itu memberi Zhipu waktu hingga 10 Oktober untuk menjawab secara tertulis dan mempertahankan hak untuk menuntut ganti rugi dan mengadu kepada regulator. Caixin Global melaporkan bahwa Zhipu menyebut tuduhan itu tidak benar.

Dua hari kemudian, Chengming menariknya. Desk keuangan China National Radio melaporkan bahwa pada 21 September perusahaan itu mengeluarkan penarikan kembali yang menyatakan bahwa pernyataan sebelumnya didasarkan pada bukti yang keliru, deskripsi yang tidak tepat, dan kata-kata yang berlebihan, bahwa pernyataan itu telah merusak reputasi Zhipu, dan bahwa perusahaan akan berhenti berbicara kepada media. Reuters juga melaporkan penarikan itu, menurut The Next Web. Entri arsip untuk insiden ini bertanggal 18 September, hari penemuan; surat itu, tenggat 10 Oktober dalam surat tersebut, dan penarikan kembali semuanya muncul setelah tanggal itu. Dalam catatan publik per akhir Oktober, tidak ada perusahaan yang disebutkan namanya yang mendukung klaim bahwa rahasianya terekspos.

Rilis sumber terbuka dengan riwayatnya yang dihapus

Membuka kode sumber klien adalah solusi yang paling diandalkan Zhipu, dan itu membawa celah. The Paper melaporkan bahwa repositori yang dipublikasikan berisi dua commit: commit awal yang kosong dan satu commit yang menambahkan sekitar 6.973 file dan 1,03 juta baris, dengan pull request dikunci dan issue ditutup. Bagaimana bentuk pipeline unggah saat dirilis, dan rilis mana saja yang memuatnya, tidak ada dalam riwayat yang kini dapat dibaca siapa pun.

Tindak lanjut Ferstar sendiri membuat batas itu menjadi eksplisit. Ia mengonfirmasi bahwa pipeline unggah sudah tidak ada dan bahwa mekanisme checkpoint yang tersisa hanya melakukan pekerjaan Git lokal, lalu menunjukkan apa yang dapat dan tidak dapat ditunjukkan oleh audit terhadap bucket: mengosongkan dan menghapus bucket adalah tindakan stop-loss yang tepat, tetapi pemeriksaan pihak ketiga yang dilakukan setelah 20 September hanya dapat membuktikan bahwa bucket kosong pada titik itu. Pemeriksaan itu tidak dapat merekonstruksi apa yang melewatinya sebelum 18 September, apakah ada yang didekripsi, disalin, atau dicadangkan, atau berapa lama pipeline telah berjalan. Klaim penghapusan masih sangat bergantung pada kata-kata pihak yang menghapus.

Analisis InfoQ mencantumkan pertanyaan-pertanyaan yang masih terbuka dalam rumusan yang sama: berapa banyak snapshot repositori yang berhasil diunggah dan oleh berapa banyak pengguna, berapa lama objek disimpan, sistem sisi server atau staf mana yang dapat mendekripsinya, apakah log akses lengkap tersedia, dan apakah penghapusan mencakup cadangan dan salinan lain. Ini juga mencatat seperti apa ZCode setelah perbaikan. NOTICE milik proyek sendiri memperingatkan bahwa runtime agen bersama tidak menyediakan sandbox tingkat sistem operasi secara default, dan klien mempertahankan permukaan shell, terminal, Git, MCP, plugin, dan browser tersemat yang dapat membaca file, memulai proses, dan menjangkau jaringan dalam izin akun pengguna.

Apa yang sudah mapan, dan apa yang tidak dijawab oleh sumber mana pun

Mekanismenya tidak diperdebatkan. Pernyataan Zhipu sendiri mengakui bahwa data repositori diunggah, bahwa fitur tersebut aktif secara default, dan bahwa data itu dikirim ke bucket cloud yang dikendalikan perusahaan. Pengukuran Ferstar, permintaan maaf vendor, dua audit yang ditugaskan, dan rilis sumber terbuka semuanya menggambarkan rantai yang sama. Tidak ada dalam catatan yang membantah bahwa ruang kerja meninggalkan mesin tanpa opsi keluar yang dapat digunakan. Kerugian yang tercatat dalam catatan adalah nyata, bukan hipotetis: transfernya terjadi, dan orang-orang yang kodenya berada di dalamnya tidak dapat mencegah maupun memeriksanya.

Yang diperdebatkan, atau sekadar tidak diketahui, adalah skala dan konsekuensinya. Tidak ada sumber yang menyatakan berapa banyak pengguna yang menjalankan default terdampak, berapa lama pipeline beroperasi sebelum 18 September, atau apakah ada objek yang diunggah yang pernah didekripsi. Jaminan Zhipu bahwa data dihancurkan setelah pembuatan wiki dan tidak pernah digunakan untuk pelatihan adalah pernyataan perusahaan sendiri; temuan CAICT dan NSFOCUS menjelaskan keadaan bucket setelah perbaikan, bukan apa yang melewatinya. Arsip memberi nilai A pada catatan tersebut untuk dokumentasi, dan dokumentasinya kuat dalam hal mekanisme tetapi tipis dalam hal cakupan.

Apa yang berubah, dan apa yang tidak

Biaya komersialnya langsung terasa. China National Radio melaporkan bahwa saham Zhipu yang tercatat di Hong Kong turun 1,79% pada 21 September, 6,55% pada 22 September, dan 12,4% pada 23 September, dengan penurunan kumulatif lebih dari 16% selama tiga sesi perdagangan, serta bahwa Zhipu tidak menjelaskan berapa banyak pengguna yang terdampak atau apakah data historis telah didekripsi atau dicadangkan.

Apa yang sebenarnya diterima seorang pengguna ZCode dalam empat hari setelah penemuan itu:

• 18 September: permohonan maaf publik yang menyebut pengindeksan basis kode sebagai penyebabnya, janji untuk membuka sumber klien dan menugaskan tinjauan pihak ketiga, serta satu reset kuota mingguan tambahan per pengguna.

• 19 September: ZCode 3.14.0, dengan Repo Wiki dihapus serta jalur pembuatan snapshot lokal dan pengunggahan diputus. Ferstar mengonfirmasi rantai pengunggahan sudah tidak ada pada hari berikutnya.

• 20 September: opsi tanpa retensi yang diumumkan untuk platform MaaS Zhipu, bersifat opt-in, tidak termasuk Batch API dan File API, dan tetap tunduk pada ketentuan penyimpanan hukum selama 30 hari atau lebih.

• 21 September: ZCode diterbitkan di bawah Apache 2.0 tanpa riwayat commit pra-insidennya; ringkasan dari CAICT dan NSFOCUS melaporkan bucket penyimpanan kosong dan jalur egress tidak tersedia.

Tidak satu pun dari semua itu menjangkau masa lalu. Pertanyaan-pertanyaan spesifik yang diajukan Chengming — ke mana data itu pergi, siapa yang dapat mendekripsinya, apakah data itu keluar dari negara tersebut, dan apa yang tercakup dalam "dihancurkan" — diajukan secara tertulis dengan tenggat 10 Oktober, lalu ditarik kembali bersama perusahaan yang mengajukannya. Zhipu telah menjanjikan laporan penilaian pihak ketiga secara lengkap tanpa menyebutkan tanggal. Sampai laporan itu muncul, satu-satunya keterangan publik tentang apa yang dilakukan pipeline terhadap data yang diterimanya adalah keterangan dari perusahaan yang membangunnya, dan satu-satunya artefak yang dapat diukur secara independen adalah file 313 MB yang gagal 564 kali keluar dari laptop seorang pengembang.