GitHub Actions Kembali Diaktifkan Saat Payload Mini Shai-Hulud Masih Aktif
Dua GitHub Actions pihak ketiga yang sebelumnya dikompromikan dalam kampanye malware Mini Shai-Hulud sempat diaktifkan kembali oleh maintainer tanpa terlebih dahulu membersihkan kode berbahaya yang masih tersimpan di dalam repository.
Akibatnya, workflow GitHub Actions yang menggunakan kedua action tersebut melalui release tag yang terdampak kembali mengunduh dan menjalankan payload malware lama.
Kedua action yang terlibat adalah actions-cool/issues-helper dan actions-cool/maintain-one-comment. GitHub sebelumnya telah menonaktifkan keduanya setelah kompromi pada Mei 2026 untuk mencegah workflow pengguna mengambil kode berbahaya.
Menurut peneliti dari perusahaan keamanan aplikasi Socket, kedua repository tersebut kembali aktif mulai 16 September hingga 25 September 2026 dan selama periode tersebut masih mengarah ke commit yang mengandung payload berbahaya.
Dua GitHub Actions Kembali Aktif
Masalah bermula ketika kedua repository yang sebelumnya telah dinonaktifkan kembali dapat diakses pada 16 September.
Socket menemukan bahwa release tag yang digunakan oleh kedua action tersebut tidak dibersihkan sebelum repository diaktifkan kembali.
Akibatnya, tag yang sama masih menunjuk ke commit yang berisi payload berbahaya yang sebelumnya ditambahkan pada 18 Mei 2026.
Hal ini menyebabkan workflow yang menggunakan action berdasarkan version tag dapat kembali mengambil dan menjalankan kode malware ketika workflow tersebut dijalankan.
Socket menjelaskan bahwa repository tersebut menjadi aktif kembali tanpa adanya proses pembersihan release tag terlebih dahulu.
Belum diketahui secara pasti mengapa repository diaktifkan kembali dalam kondisi tersebut.
Payload Mini Shai-Hulud Masih Berada di index.js
Peneliti Socket menemukan bahwa release tag dari kedua action mengarah ke commit yang masih mengandung payload yang telah di-obfuscate di dalam file:
index.js
Karena GitHub Actions dapat menjalankan kode yang terdapat dalam repository sebagai bagian dari workflow otomatis, action yang telah dikompromikan dapat menjadi jalur eksekusi malware pada lingkungan CI/CD.
Masalah menjadi semakin serius ketika workflow menggunakan version tag yang dapat berubah atau kembali aktif tanpa memeriksa commit yang sebenarnya digunakan.
Dalam kondisi tersebut, developer mungkin menganggap action yang digunakan sebagai versi yang sama seperti sebelumnya, padahal isi commit yang ditunjuk oleh tag masih mengandung kode berbahaya.
GitHub Sebelumnya Memblokir Kedua Action
Kedua action tersebut awalnya dikompromikan pada 18 Mei 2026.
Tim keamanan GitHub kemudian menghapus atau menonaktifkan actions-cool/issues-helper dan actions-cool/maintain-one-comment sehingga workflow downstream tidak lagi dapat mengunduh malware dari repository tersebut.
Tindakan tersebut menghentikan penyebaran lebih lanjut melalui GitHub Actions pada saat itu.
Namun, ketika repository kembali diaktifkan pada September tanpa membersihkan tag dan commit berbahaya, workflow yang masih menggunakan referensi tersebut kembali berpotensi menjalankan payload.
Pada 25 September, Socket kembali menemukan bahwa kedua action tersebut telah dinonaktifkan.
Dengan kondisi tersebut, workflow yang merujuk pada action terdampak kini akan gagal dijalankan daripada mengeksekusi payload yang masih tersimpan.
Mini Shai-Hulud Sebelumnya Menargetkan Ekosistem npm
Insiden GitHub Actions ini berkaitan dengan kampanye Mini Shai-Hulud yang sebelumnya menyerang ekosistem npm.
Kampanye tersebut pada Mei 2026 berdampak pada sekitar 323 package dan 639 versi package di npm.
Malware yang disisipkan ke dalam package dirancang untuk menargetkan informasi sensitif milik developer, termasuk token, kredensial, serta secret yang digunakan dalam lingkungan CI/CD.
Serangan supply-chain seperti ini menjadi sangat berbahaya karena malware tidak harus menyerang komputer developer secara langsung. Penyerang dapat memasukkan kode berbahaya ke dalam software atau dependency yang kemudian dipercaya dan digunakan oleh organisasi lain.
GitHub Actions memberikan target tambahan karena action dapat dijalankan secara otomatis dalam workflow dan sering memiliki akses terhadap secret yang diperlukan untuk proses build, testing, deployment, atau publikasi software.
Sekitar 15.000 Repository Bergantung pada issues-helper
Socket menyebut GitHub dependency graph menunjukkan sekitar 15.000 repository memiliki ketergantungan terhadap issues-helper.
Namun, angka tersebut tidak berarti seluruh repository tersebut telah terkompromikan.
Salah satu faktor penting adalah bagaimana masing-masing workflow mereferensikan action.
Peneliti Socket mengatakan mereka belum mengetahui berapa banyak repository yang menggunakan mutable tag dibandingkan commit yang sudah dipin secara eksplisit.
Perbedaan tersebut sangat penting dalam keamanan supply chain.
Jika workflow menggunakan tag seperti v1 atau referensi versi lain yang dapat berubah, isi yang dijalankan dapat berbeda dari commit yang sebelumnya dianggap aman.
Sebaliknya, penggunaan commit SHA yang telah diverifikasi memberikan kepastian lebih besar mengenai kode yang akan dijalankan.
Action Terdampak Digunakan Secara Rutin
Socket juga mencatat bahwa kedua action tersebut digunakan untuk pekerjaan housekeeping pada issue GitHub dan berpotensi dijalankan hampir setiap hari.
Artinya, workflow yang menggunakan action tersebut tidak harus menunggu proses deployment besar untuk menjalankan kode berbahaya.
Workflow rutin yang berjalan otomatis juga dapat mengambil action yang terdampak ketika dipicu.
Periode paparan berlangsung mulai 16 September 2026, antara pukul 11.09 hingga 18.16 GMT+2, sampai kedua action kembali dinonaktifkan pada 25 September.
Developer yang memiliki workflow terjadwal perlu memperhitungkan seluruh eksekusi yang terjadi dalam periode tersebut ketika melakukan pemeriksaan keamanan.
Developer Diminta Memeriksa Workflow
Socket merekomendasikan pengguna segera mencari seluruh referensi terhadap:
actions-cool/issues-helper
actions-cool/maintain-one-commentJika ditemukan, referensi tersebut sebaiknya dihapus atau diarahkan ke commit yang telah diverifikasi bersih.
Administrator dan developer juga perlu meninjau seluruh workflow yang menjalankan kedua action tersebut sejak 16 September 2026.
Pemeriksaan ini penting untuk mengetahui apakah workflow sempat berjalan ketika repository berada dalam kondisi berbahaya.
Secret dan Token Perlu Diputar Ulang
Jika sebuah workflow menjalankan action yang terdampak selama periode paparan, langkah penting berikutnya adalah melakukan rotasi secret dan kredensial yang dapat diakses oleh workflow tersebut.
GitHub Actions sering diberikan akses ke berbagai secret, misalnya token repository, package registry credentials, cloud API keys, deployment credentials, dan secret lainnya.
Jika payload malware berhasil membaca environment variable atau secret tersebut, kredensial dapat digunakan untuk mengakses sistem lain di luar GitHub.
Karena itu, developer tidak sebaiknya hanya menghapus referensi action tanpa mempertimbangkan kredensial yang mungkin telah tersedia pada workflow ketika payload dijalankan.
Pinning Commit Menjadi Langkah Penting
Insiden ini juga menunjukkan risiko penggunaan action berdasarkan mutable tag.
Dalam workflow CI/CD, menggunakan commit SHA yang telah diverifikasi dapat membantu memastikan bahwa workflow menjalankan kode yang memang telah diperiksa.
Sebaliknya, tag dapat dipindahkan atau diarahkan ke commit berbeda. Dalam kasus ini, release tag yang sudah ada tetap menunjuk ke commit yang mengandung payload lama ketika repository kembali diaktifkan.
Untuk lingkungan produksi, organisasi sebaiknya mempertimbangkan kebijakan dependency pinning, verifikasi perubahan action, serta pembatasan secret yang tersedia bagi workflow.
GitHub Actions Kembali Dinonaktifkan
Pada 25 September, kedua action tersebut kembali dinonaktifkan di GitHub.
Dengan kondisi tersebut, workflow yang masih mereferensikan action terdampak akan gagal berjalan dan tidak lagi mengeksekusi payload yang terdapat di dalam repository.
Namun, penonaktifan tersebut tidak menghapus risiko dari workflow yang sebelumnya sudah berjalan selama periode paparan.
Developer yang terdampak tetap perlu memeriksa execution history sejak 16 September dan melakukan rotasi terhadap secret yang dapat diakses oleh workflow.
Insiden ini menjadi pengingat bahwa keamanan software supply chain tidak berhenti pada pemeriksaan package atau source code. GitHub Actions dan dependency CI/CD juga dapat menjadi jalur serangan ketika kode pihak ketiga diberikan akses otomatis ke repository, token, maupun kredensial deployment.
Sumber: Socket
