Serangan Gheist Bobol 850 Akun GitHub, Ini Cara Cek dan Amankan Repo

Dunia developer kembali diguncang kabar kebocoran. Tim Wiz Research melaporkan kampanye bernama Gheist, yaitu serangan otomatis yang memakai token GitHub curian untuk menyedot secret dari repositori korban. Sampai laporan itu terbit pada 25 Oktober 2026, Wiz sudah menemukan lebih dari 13.500 branch berbahaya di lebih dari 850 akun GitHub yang disusupi.

Artikel ini akan menjelaskan bagaimana serangan Gheist bekerja, kenapa repo privat justru paling rawan, apa saja tanda repo yang terdampak, dan langkah yang perlu diambil supaya akun serta secret tetap aman. Ada juga catatan khusus buat tim dan developer di Indonesia yang memakai GitHub Actions untuk deploy ke cloud.

Kronologi singkat serangan Gheist

Serangan ini tidak muncul tiba-tiba. Wiz sudah memantaunya selama lebih dari sebulan sebelum mempublikasikan temuannya. Berikut urutan kejadian yang tercatat di laporan Wiz dan liputan media keamanan:

1. 15 September 2026: Wiz Research mulai melacak aktivitas aneh berupa workflow bernama sync-check yang muncul di banyak repositori sekaligus.
2. 28 September 2026: muncul varian kedua (Wiz menyebutnya Tool B) yang menambahkan batas waktu enam menit dan mulai menyasar secret di level environment.
3. 6 Oktober 2026: sebanyak 391 akun yang sama-sama bobol tiba-tiba mengganti nama sekitar 1.461 repositori menjadi umpan software bajakan, misalnya fl-studio-crack.
4. 18–19 Oktober 2026: sebagian akun dipakai untuk menambang kripto lewat runner Windows, dan Tool B menambahkan job kedua yang menyasar self-hosted runner.
5. 24 Oktober 2026: Wiz menyatakan serangan masih berjalan dan terus berkembang, meski sekitar dua pertiga akun yang terlibat sudah tidak tersedia lagi di GitHub.
6. 25–26 Oktober 2026: laporan Wiz terbit, lalu diangkat oleh Dark Reading dan The Hacker News.

Catatan: Wiz belum menyebut berapa banyak organisasi yang benar-benar kehilangan secret. Angka 850 akun dan 13.500 branch adalah jumlah yang berhasil mereka temukan, bukan jumlah total korban.

Nama Gheist sendiri berasal dari user agent gheist yang terbawa di setiap permintaan API milik alat penyerang. Jadi ini adalah label dari peneliti, bukan nama grup peretas yang mengaku.

Cara kerja serangan, dijelaskan dengan bahasa sederhana

Inti serangan Gheist sebenarnya cukup sederhana, tapi licin. Penyerang tidak membobol GitHub itu sendiri. Mereka memakai token akses yang sudah dicuri sebelumnya, lalu memanfaatkan fitur GitHub Actions untuk membocorkan secret milik korban.

Langkahnya kira-kira seperti ini:

1. Alat penyerang memakai token curian untuk membuka semua repositori yang bisa diakses token tersebut.
2. Di setiap repo, alat itu membuat branch baru bernama ci-sync- diikuti enam karakter acak.
3. Branch itu berisi satu file baru, .github/workflows/sync-check.yml, dengan pesan commit ci: sync config. Commit-nya tidak ditandatangani dan tercatat atas nama pemilik token.
4. Push tersebut langsung memicu workflow. Workflow itu mencetak semua environment variable dan seluruh isi secrets ke log, tapi sudah diubah dulu ke format base32.
5. Alat penyerang mengunduh log lewat API GitHub, lalu menghapus run tersebut hanya beberapa detik kemudian.

Kenapa base32 penting? GitHub memang menyensor secret di log, tapi hanya kalau nilainya muncul persis sama. Begitu nilainya diubah ke format lain, sensor itu tidak mengenalinya, sehingga secret tercetak utuh.

Ada dua hal lain yang bikin serangan ini sulit dicegah:

• Tidak ada server penyerang yang bisa diblokir. Data keluar lewat API resmi GitHub, jadi firewall tidak melihat koneksi mencurigakan.
• Secret di level environment ikut bocor. Kalau repo punya environment seperti production, alat ini membuat matriks job supaya secret produksi juga ikut tercetak.

Di organisasi besar, Wiz melihat alat ini berganti-ganti token milik beberapa pengguna dan akun otomasi hanya dalam hitungan menit. Beberapa jam kemudian, kredensial cloud dari organisasi yang sama dipakai untuk menelusuri AWS Secrets Manager.

Kenapa repo privat justru paling rawan

Ini bagian yang cukup mengejutkan. Sejak 28 Juli 2026, GitHub punya pengaman baru yang menahan workflow mencurigakan di repo publik sampai ada kolaborator yang menyetujuinya. Menurut Wiz, semua run Gheist di repo publik yang mereka cek tertahan di status action_required, jadi payload-nya tidak pernah berjalan.

Masalahnya, pengaman itu tidak berlaku untuk:

• Repositori privat di GitHub.com.
• GitHub Enterprise Server yang di-hosting sendiri.

Di dua tempat itu, Wiz menemukan log audit yang menunjukkan run di branch ci-sync-* selesai berjalan lalu dihapus oleh user agent gheist. Peneliti Wiz, Rami McCarthy, mengatakan kepada Dark Reading bahwa pengaman GitHub tersebut berfokus melindungi repo publik, dan begitu kredensial perusahaan bobol, kontrol itu tidak lagi berlaku.

Peringatan: banyak tim merasa aman karena repo mereka privat. Pada kasus Gheist, justru repo privat yang paling sering berhasil dibobol, karena workflow langsung jalan tanpa perlu persetujuan.

Varian terbaru juga menambahkan job khusus untuk self-hosted runner. Job ini mencari 31 jenis format token (termasuk kunci API Anthropic, Hugging Face, Groq, dan NVIDIA), file .env, kunci privat, state Terraform, riwayat shell, sampai kredensial AWS di mesin runner. Untungnya, Wiz mencatat job ini masih penuh bug, misalnya salah mencari file kunci runner dan gagal mengambil token GCP maupun Azure.

Dari mana token curian itu berasal

Gheist tidak mencuri token dari nol. Kampanye ini memanfaatkan token yang sudah bocor lewat kejadian lain. Menurut Wiz, sumber kredensial yang bisa dilacak cocok dengan dua pola:

• Log malware infostealer, yaitu malware pencuri data yang menyedot kata sandi, cookie, dan token dari laptop korban.
• Token yang bocor di serangan rantai pasok sebelumnya, misalnya kasus Trivy pada Maret 2026.

Wiz juga menemukan bahwa akun yang sama dipakai oleh kampanye lain. Contohnya:

1. Repo umpan malware, yaitu repo yang diubah namanya menjadi software bajakan untuk menjebak orang mengunduh.
2. Penambangan kripto gratis, dengan membuat repo "Windows RDP Runner" untuk memakai jatah komputasi GitHub Actions.
3. PolinRider, malware yang dikaitkan dengan Korea Utara, yang menyelipkan kode JavaScript di file konfigurasi build seperti vite.config.js.
4. Megalodon, kampanye pada Mei 2026, di mana 57 akun dari fase awal Gheist juga pernah menjadi korban.

Pola ini menunjukkan satu hal penting: satu token yang bocor bisa dipakai berkali-kali oleh banyak pelaku berbeda. Jadi kalau ada token yang pernah terekspos, menghapus commit saja tidak cukup. Token itu harus dicabut.

Perlu dicatat juga, Wiz menegaskan Gheist berbeda dengan kampanye GhostAction yang pernah ramai sebelumnya. GhostAction memakai file workflow lain dan mengirim data ke alamat IP tertentu, sementara Gheist mengandalkan API GitHub sendiri.

Cara cek apakah repo terdampak

Kabar baiknya, tanda-tanda serangan Gheist cukup khas sehingga bisa dicek sendiri. Berikut hal-hal yang disarankan Wiz untuk diperiksa:

Baca juga Telegram Android Kena Bug Panggilan Suara, Cek Versinya

1. Cari branch mencurigakan. Periksa apakah ada branch dengan pola ci-sync- diikuti enam huruf atau angka acak, yang isinya hanya menambah file .github/workflows/sync-check.yml.
2. Cek pesan commit. Commit dengan pesan ci: sync config yang tidak pernah dibuat tim sendiri adalah tanda bahaya.
3. Buka log audit GitHub. Cari workflow run di branch ci-sync-* yang dihapus kurang dari satu menit setelah selesai, serta aktivitas dengan user agent gheist.
4. Cek log cloud kalau memakai OIDC. Kalau workflow login ke AWS atau cloud lain lewat OIDC, cari role assumption yang subjeknya menyebut branch ci-sync-. Ini bukti Actions sempat jalan di branch penyerang, meski log GitHub tidak dikumpulkan.
5. Periksa self-hosted runner. Cari file .gdmp_pat, .gdmp_patg, dan .gdmp_sweep, serta tulisan gdmp-pivot di log job.

Untuk pengecekan cepat di repo lokal, perintah sederhana ini bisa membantu melihat branch remote yang mencurigakan:

git fetch --all --prune
git branch -r | grep -E "ci-sync-[0-9a-z]{6}$"

Kalau perintah itu memunculkan hasil, jangan langsung menghapus branch dan merasa urusan beres. Lanjutkan ke langkah pengamanan di bawah.

Tips: jangan pernah menyetujui run sync-check yang tertahan, dan jangan menjalankan kode apa pun dari branch ci-sync-*.

Langkah amankan akun dan secret

Wiz menekankan bahwa menghapus run atau branch tidak membatalkan kebocoran. Begitu secret sudah tercetak dan diunduh, anggap saja secret itu sudah di tangan orang lain. Langkah yang disarankan:

1. Ganti semua secret di level repositori, organisasi, dan environment yang bisa diakses repo terdampak, termasuk kunci cloud, token database, dan kunci API layanan AI.
2. Cabut token yang dipakai untuk mendorong commit berbahaya, lalu periksa laptop pemilik token dari kemungkinan infeksi infostealer.
3. Anggap self-hosted runner sudah bobol kalau branch ci-sync sempat berjalan di sana, termasuk instance role milik mesin itu.
4. Wajibkan reviewer untuk environment yang menyimpan secret produksi.
5. Batasi kepercayaan OIDC supaya hanya branch atau environment yang dilindungi yang boleh login ke cloud.
6. Ganti personal access token lama dengan GitHub App atau token fine-grained yang masa berlakunya pendek. Saran yang sama juga disampaikan Waseem Ahmed dari Secure.com kepada Dark Reading.
7. Jalankan self-hosted runner sebagai mesin sekali pakai, tanpa akses ke Docker socket dan tanpa akses bebas ke metadata cloud.

Langkah nomor 6 mungkin terasa paling repot, tapi efeknya paling besar. Token lama yang berlaku bertahun-tahun adalah bahan bakar utama kampanye seperti Gheist.

Yang perlu diperhatikan developer di Indonesia

Laporan Wiz tidak menyebut korban berdasarkan negara, jadi belum ada data apakah ada perusahaan Indonesia yang terkena. Meski begitu, pola kerja banyak tim di sini membuat risiko ini cukup dekat. Banyak startup, agensi, dan tim freelance di Indonesia menyimpan kode di repo privat GitHub dan memakai GitHub Actions untuk deploy otomatis ke AWS, Google Cloud, atau server VPS.

Beberapa kebiasaan yang sebaiknya dicek ulang:

• Satu token dipakai bareng-bareng. Di tim kecil, kadang satu personal access token dibagi ke banyak orang atau disimpan di banyak tempat. Kalau satu laptop kena infostealer, semua repo ikut terbuka.
• Laptop kerja dipakai unduh software bajakan. Infostealer paling sering masuk lewat crack software atau game bajakan. Ironisnya, akun yang bobol di kasus ini malah dipakai untuk menyebar repo umpan berisi crack.
• Kunci API AI disimpan sebagai secret repo. Banyak proyek AI lokal menyimpan kunci OpenAI, Anthropic, atau Hugging Face di GitHub Secrets. Varian terbaru Gheist justru mencari jenis kunci ini, dan tagihan bisa membengkak kalau kunci dipakai orang lain.
• Self-hosted runner di server kantor. Kalau runner jalan di server yang sama dengan database atau aplikasi produksi, satu workflow berbahaya bisa membuka akses ke semuanya.

Dari sisi aturan, perusahaan yang mengelola data pribadi pelanggan juga perlu ingat kewajiban di UU Pelindungan Data Pribadi. Kalau secret yang bocor membuka akses ke database pelanggan, kejadian itu bukan lagi sekadar urusan tim IT.

Reaksi komunitas dan pelajaran dari kasus ini

Kasus Gheist datang di tengah rentetan insiden rantai pasok yang ramai dibahas developer dalam beberapa minggu terakhir. Pada hari yang sama, The Register melaporkan bahwa serangan ke LiteLLM berawal dari master key yang tidak dicabut setelah sempat ter-commit ke repo publik pada Mei 2026. Media yang sama juga memberitakan worm npm keluarga Miasma yang mempersenjatai 42 repo GitHub.

Benang merahnya sama: kredensial yang bocor dan tidak segera dicabut. Beberapa pelajaran yang bisa diambil:

1. Repo privat bukan jaminan aman. Pengaman GitHub untuk repo publik justru terbukti efektif, sementara repo privat dan Enterprise Server tertinggal.
2. Rotasi token harus jadi kebiasaan, bukan reaksi setelah kejadian.
3. Log audit perlu dikumpulkan. Tanpa log, serangan yang menghapus jejaknya sendiri dalam hitungan detik akan sulit dilacak.
4. Keamanan laptop developer sama pentingnya dengan keamanan server, karena token paling sering dicuri dari perangkat pribadi.

Sisi positifnya, kontrol yang ditambahkan GitHub pada Juli terbukti bekerja di repo publik. Banyak praktisi keamanan berharap perlindungan serupa segera diperluas ke repo privat.

Poin penting

• Gheist memakai token GitHub curian untuk menanam workflow sync-check yang membocorkan secret ke log.
• Wiz menemukan lebih dari 13.500 branch berbahaya dari lebih dari 850 akun sejak 15 September 2026.
• Repo publik terlindungi pengaman GitHub sejak Juli 2026, tapi repo privat dan GitHub Enterprise Server tidak.
• Tanda utama serangan adalah branch ci-sync- plus enam karakter acak dan commit ci: sync config.
• Menghapus branch tidak cukup; semua secret harus diganti dan token pelaku harus dicabut.

Checklist

• Cari branch ci-sync-* di semua repo, termasuk repo privat
• Periksa log audit GitHub untuk user agent gheist
• Cek log cloud untuk login OIDC dari branch ci-sync-
• Ganti semua secret repo, organisasi, dan environment yang terdampak
• Cabut personal access token lama dan pindah ke token fine-grained
• Wajibkan reviewer untuk environment produksi
• Pindai laptop tim dari kemungkinan infostealer

Referensi

1. Wiz Research (2026). Gheist: Attempted Scaled Abuse of Stolen GitHub Tokens Stumbles
2. Dark Reading (2026). Liputan kampanye Gheist dan wawancara Wiz serta Secure.com
3. The Hacker News (2026). Liputan kampanye Gheist dan token GitHub curian
4. The Register (2026). Laporan insiden rantai pasok LiteLLM dan worm Miasma
5. GitHub Docs. Using secrets in GitHub Actions
6. GitHub Docs. Managing your personal access tokens