ZCode Ketahuan Upload Riwayat Git ke Cloud Tanpa Izin, Ini Fakta dan Cara Proteksi

Ada pola yang mulai terasa membosankan di dunia keamanan developer: tool AI coding yang menjanjikan produktivitas, lalu ketahuan mengirim data workspace ke cloud tanpa izin yang benar-benar paham. Terakhir CrowdSec yang source code-nya bocor, sekarang ZCode, desktop app AI coding resmi dari Zhipu, yang dibedah oleh seorang peneliti dan hasilnya bikin banyak developer geleng-geleng kepala.

TL;DR

• ZCode, aplikasi AI coding dari Zhipu, ditemukan memaketkan seluruh workspace pengguna termasuk riwayat commit lengkap setiap kali login dan mengunggahnya ke cloud.
• Investigasi dimulai dari direktori ~/.zcode berukuran lebih dari 700MB, dengan arsip 313MB dari proyek komersial berstatus gagal upload hingga 564 kali, sementara satu repo publik berisi 538 file tercatat diterima server.
• Dari satu snapshot berisi 42.411 file, direktori .git mencakup 86,6 persen payload, terdiri dari cache LFS 196,1MB dan objek commit 102,2MB.
• Kunci enkripsi snapshot dipegang server, dan toggle di antarmuka aplikasi terbukti tidak menghentikan proses pengemasan dan pengunggahan.
• Proteksi yang direkomendasikan adalah mengunci direktori snapshot (misalnya chattr +i di Linux), memisahkan user account, dan merotasi kredensial yang pernah masuk riwayat Git.

Seperti dilaporkan di blog ferstar.org (18 September 2026, dengan update respons perusahaan sehari kemudian), aplikasi tersebut memaketkan seluruh workspace pengguna setiap kali login. Bukan cuma file yang sedang diedit, tetapi riwayat commit lengkap, cache LFS, reflog, sampai konfigurasi global aplikasi. Artikel ini merangkum temuannya, apa yang sudah dikonfirmasi, apa yang masih jadi tanda tanya, dan langkah proteksi yang bisa langsung dipraktikkan.

Awal Mula: 700MB yang Mencurigakan di Home Directory

Investigasi ini bermula dari hal paling membosankan sedunia: kehabisan ruang disk. Sang penulis sedang membereskan file ketika menemukan direktori ~/.zcode menempati lebih dari 700MB. Setelah dibedah, komposisinya kurang lebih begini:

• cli/ sekitar 257MB, berisi database sesi dan log eksekusi
• computer-use/ sekitar 130MB, berisi app dan dependency runtime yang dibundel
• v2/checkpoints/ sekitar 303MB, dan inilah tersangka utamanya

Di folder checkpoints itulah ditemukan arsip 313MB dari proyek komersial milik pengguna yang statusnya menggantung di antrean upload, dengan penghitung kegagalan mencapai 564 kali. Satu proyek memang gagal kirim. Tapi di situlah bagian yang bikin tidak nyaman: workspace lain, berupa repo publik berisi 538 file (sekitar 15KB setelah dikompres dan dienkripsi), berstatus diterima server. Jadi pertanyaan "apakah data benar-benar pernah keluar dari mesin" sudah terjawab: ya, minimal yang satu itu.

Peneliti lain kemudian mereproduksi pola yang sama di Windows, menemukan struktur direktori dan file state yang serupa, termasuk beberapa workspace kecil tanpa catatan kegagalan yang tampak lolos upload. Artinya ini bukan artefak satu mesin atau satu sistem operasi.

Isi Paketnya: 86 Persen adalah Folder .git

Yang membuat kasus ini berbeda dari sekadar aplikasi yang menyimpan telemetri adalah isi paketnya. Manifest (daftar isi file) dari proses pengemasan tersimpan dalam bentuk plaintext di lokal, sehingga bisa diaudit tanpa membongkar enkripsi. Salah satu snapshot berisi 42.411 file dengan komposisi kurang lebih begini:

• .git/lfs/ sebesar 196,1MB atau 56,8 persen, cache LFS berisi semua aset biner dan media besar yang pernah diunduh
• .git/objects/ sebesar 102,2MB atau 29,6 persen, storage objek commit, tree, dan blob yang lengkap
• .git/logs/ sebesar 0,6MB, reflog yang menyimpan jejak operasi lokal termasuk hal-hal yang belum sempat di-push
• Sisanya sekitar 46,2MB atau 13,4 persen baru kode sumber dan dokumen

Ditotal, direktori .git saja mencakup 86,6 persen dari payload. Ini poin yang sering salah dipahami developer: bagi pihak yang tidak seharusnya punya akses, riwayat Git sering jauh lebih berharga daripada kode hari ini. Diff lama menyimpan kredensial yang sudah dirotasi, URL internal, pola arsitektur, komentar commit yang membocorkan nama klien, sampai jejak branch proyek yang dibatalkan.

Kunci Enkripsi Ada di Tangan Server

Ada argumen pembelaan yang muncul: datanya dienkripsi kok. Sang peneliti menyebut sisi ironisnya. Untuk skenario checkpoint restore atau sinkronisasi antar perangkat, kunci semestinya hidup di sisi klien, persis seperti Git atau Time Machine yang bisa berjalan end-to-end. Dalam kasus ini, kunci justru dipegang server. Fungsi satu-satunya kunci di sisi server adalah memastikan server bisa membaca kode kapan pun ia mau.

Manifest plaintext memperkuat pembacaan itu: infrastruktur paket ini dirancang agar sisi server tahu persis apa yang dikemas, bahkan kalau isinya terenkripsi.

Toggle di UI Tidak Menghentikan Upload

Bagian yang paling mengganggu untuk soal consent: switch dan toggle pengaturan di antarmuka aplikasi terbukti tidak menghentikan proses pengemasan dan pengunggahan. Mengosongkan opsi di UI bukan mekanisme opt-out. Kebijakan privasi yang diarsipkan penulis pada 18 September juga tidak menggambarkan perilaku ini dengan jelas.

Respons perusahaan datang sehari kemudian lewat pembaruan di blog yang sama. Versi 3.14.0 disebut mengubah perilaku dibanding 3.12.3 yang dibedah, endpoint pengunggahan dilaporkan sudah tidak aktif (mengembalikan 404), dan ada klaim data tidak disimpan. Tapi beberapa pertanyaan penting masih menggantung, dan penulis aslinya sendiri merincinya dengan jujur:

• Bagaimana membuktikan klaim "langsung dihancurkan" dari luar?
• Apakah snapshot lama yang sudah terlanjur ada di cloud benar-benar dimusnahkan secara fisik, dan siapa yang memegang hak dekripsi?
• Klaim restore checkpoint agak bertabrakan dengan klaim data tidak disimpan; jadi apa yang sebenarnya tertinggal?
• Kalau benar akan open-source, apakah yang dirilis termasuk sisi upload lama yang bermasalah, atau hanya kode bersih versi terkini?

Sampai pertanyaan-pertanyaan itu dijawab dengan bukti yang bisa diaudit, posisi paling aman untuk pengguna adalah menganggap data workspace pernah keluar.

Cara Proteksi Diri: Jangan Hapus, Kunci Direktori

Rekomendasi penulis blog tersebut cukup tajam: menghapus file hasil snapshot saja tidak cukup, karena aplikasinya membuat ulang, persis permainan pukul tikus. Yang bertahan adalah mengunci direktorinya sehingga proses pengemasan gagal menulis, sekaligus berfungsi sebagai tripwire: begitu muncul error atau file baru lagi di sana, lo tahu aplikasinya mencoba mengulang.

Pola umumnya di Linux dan macOS: buat file pengganti di path target atau set permission direktori menjadi read-only untuk user lo. Di Linux, atribut immutable via chattr +i membuat file kebal terhadap perubahan sampai atributnya dilepas manual. Di macOS dan Windows ada padanan ACL-nya yang dibahas di komunitas yang mengutip riset ini. Semua ini mitigasi teknis, bukan pengganti keputusan yang lebih mendasar.

Langkah yang lebih mendasar, dan sebenarnya sudah lama jadi hygiene standar:

• Jalankan tool AI coding di user account terpisah atau environment terisolasi dengan home directory yang bersih dari kredensial.
• Jangan login tool coding AI apa pun dengan mesin yang menyimpan seluruh repo pekerjaan sensitif tanpa pemisahan.
• Perlakukan setiap ~/.namatool yang tiba-tiba membengkak sebagai barang bukti: bedah sebelum hapus.
• Rotasi kredensial yang pernah ada di riwayat Git lo, karena riwayat itu panjang umurnya, bahkan setelah lo force push.

Pelajaran yang Lebih Besar

Kasus ZCode bukan isolat. Ia satu seri dengan kejadian lain di 2026 ini: kebocoran source code CrowdSec yang memaksa orang membaca ulang arti aman di tooling keamanan, sampai temuan heap overflow yang bisa menembus repo internal sebuah lab AI besar. Polanya konsisten: tool yang menyentuh kode lo punya hak akses paling besar di mesin lo, dan audit eksternal hampir selalu datang terlambat.

Untuk developer Indonesia yang mulai pakai AI coding tool sebagai kebutuhan harian, insiden ini bukan alasan untuk berhenti pakai. Ini alasan untuk mengubah cara pakainya. Beda antara productivity tool dan malware yang sopan sering cuma soal siapa yang membaca traffic-nya duluan.

Satu kebiasaan murah yang layak mulai sekarang: sekali seminggu, cek ukuran direktori home lo. Perintah du -h --max-depth=1 ~ | sort -h | tail sudah cukup. Kalau ada folder tool AI yang tumbuh tanpa penjelasan, curigalah lebih dulu, baru cari tahu. Di kasus ini, kecurigaan seperti itulah yang membongkar semuanya.

Kenapa Fitur Checkpoint Ada di Tempat Pertama

Supaya adil, mari bicara sisi aplikasinya. Fitur checkpoint, yaitu menyimpan snapshot workspace supaya sesi bisa di-restore atau dilanjutkan di perangkat lain, adalah fitur yang jujur berguna. Agent AI modern bekerja dalam sesi panjang; ketika sebuah sesi rusak di tengah refactor besar, kemampuan memutar balik ke titik terakhir yang diketahui sehat adalah pembeda antara perkakas yang matur dan mainan. Masalahnya bukan adanya checkpoint. Masalahnya adalah checkpoint yang disimpan di cloud pihak ketiga dengan kunci di tangan mereka, tanpa default yang jelas, dan ternyata tanpa hormat pada toggle di UI-nya sendiri.

Ada juga pelajaran desain produk yang mahal dari kasus ini: ketika kontrol pengguna tidak mengubah perilaku sistem, kontrol itu lebih buruk daripada tidak ada, karena memberi rasa aman palsu. Ini pola yang berulang di industri; regulator di beberapa yurisdiksi mulai menyebutnya dark pattern. Untuk developer yang membangun tooling sendiri, perlakukan setiap switch di halaman settings sebagai kontrak: kalau ada jalur kode yang bisa menembusnya, jangan tampilkan switch-nya.

Cara Mengaudit Tool Coding AI di Mesin Lo Malam Ini

Investigasi di atas bisa dilakukan siapa pun dengan alat yang sudah ada di laptop lo. Urutan audit yang praktis:

• Cari jejak datanya. Jalankan du -h --max-depth=2 ~ | sort -h | tail -20. Tool AI coding yang rajin checkpoint akan meninggalkan direktori seukuran ratusan MB sampai beberapa GB di home lo.
• Lihat koneksi keluar prosesnya. lsof -p $(pgrep -f nama-tool | head -1) atau ss -tnp saat tool sedang bekerja akan menunjukkan ke endpoint mana ia bicara. Endpoint upload yang tidak lo kenali adalah red flag langsung.
• Baca file manifest lokal. Seperti kasus ini, yang membuka semuanya adalah manifest plaintext di folder checkpoint. Sebelum menghapus apa pun, catat strukturnya; file state sering menyimpan status upload, URL tujuan, dan ukuran paket.
• Bedah paket aplikasinya. Aplikasi Electron menaruh sumbernya di berkas asar yang bisa diurai dengan tool publik. Tidak perlu pembalikan mesin tingkat negara untuk menemukan URL endpoint di source JavaScript yang hanya di-minify.
• Tangkap traffic kalau perlu. Proxy lokal seperti mitmproxy dengan sertifikat CA milik lo sendiri akan memperlihatkan POST apa pun yang keluar, termasuk yang disembunyikan dari UI.

Semua langkah ini legal di mesin milik sendiri dan etis sebagai audit privasi personal. Yang tidak boleh adalah menyebarkan kredensial atau data klien yang muncul di hasil audit lo.

Daftar Bersih: Kerjakan Sekarang Juga

Nasihat paling membosankan sekaligus paling melindungi. Pertama, cuci riwayat Git lo dari rahasia. Kalau kredensial pernah masuk commit, ia ada di setiap salinan repo itu, termasuk snapshot checkpoint tool pihak ketiga. Jalankan scan secret di seluruh riwayat, bukan cuma HEAD; rotate apa pun yang muncul. Kedua, pisahkan mesin kerja dan mesin eksperimen tool AI kalau memungkinkan; minimal buat user account berbeda. Ketiga, untuk repo komersial, cek kebijakan perusahaan lo: data yang tidak boleh keluar laptop tidak boleh keluar lewat checkpoint tool yang tidak di-sanction.

Sumber

• blog.ferstar.org: Inside ZCode: Silently Uploading Your Entire Git History to the Cloud (18 Sep 2026, update 19 Sep 2026)
• Diskusi Hacker News: judul item muncul di top stories 17-19 September 2026
• Reproduksi Windows (NodeSeek) dan cross-check lokal (silencestar) sebagaimana dikutip dalam posting tersebut

Rekomendasi Tools & Layanan

Kalau lo mau langsung praktikkan panduan di atas, dua layanan yang gue pake sehari-hari: free trial Alibaba Cloud buat coba-coba tanpa biaya di awal, dan ECS instance 9th-gen kalau udah siap naik ke VPS production.

FAQ

Apa yang ditemukan ZCode kirim ke cloud tanpa izin?

Aplikasi ini memaketkan seluruh workspace pengguna setiap kali login, bukan hanya file yang sedang diedit. Isinya mencakup riwayat commit lengkap, cache LFS, reflog, sampai konfigurasi global aplikasi.

Bagaimana kasus ini pertama kali terungkap?

Seorang peneliti menemukan direktori ~/.zcode menempati lebih dari 700MB saat membereskan ruang disk. Setelah dibedah, ditemukan arsip snapshot proyek komersial berstatus menggantung di antrean upload dengan 564 kali kegagalan, sementara satu repo publik kecil tercatat diterima server.

Mengapa riwayat Git dianggap lebih berisiko daripada kode yang sedang dikerjakan?

Riwayat Git menyimpan diff lama yang bisa memuat kredensial yang sudah dirotasi, URL internal, pola arsitektur, dan komentar commit yang membocorkan nama klien. Pada kasus ini, direktori .git mencakup 86,6 persen dari total payload snapshot.

Apakah toggle di UI ZCode bisa menghentikan upload data?

Tidak, switch dan toggle pengaturan di antarmuka aplikasi terbukti tidak menghentikan proses pengemasan dan pengunggahan. Kebijakan privasi yang diarsipkan pada 18 September juga tidak menggambarkan perilaku ini dengan jelas.

Apa langkah proteksi yang direkomendasikan untuk pengguna?

Jangan hanya menghapus file snapshot karena aplikasi akan membuatnya ulang; kunci direktorinya misalnya dengan chattr +i di Linux sehingga proses pengemasan gagal menulis. Jalankan juga tool AI coding di user account terisolasi dan rotasi kredensial yang pernah ada di riwayat Git.

Sumber & Referensi

Rujukan resmi yang dipakai untuk memverifikasi klaim di artikel ini:

• Man page chattr
• Situs resmi Z.ai (Zhipu)
• Situs resmi CrowdSec