Trivy diserang lagi: kebocoran rahasia akibat manipulasi tag GitHub Actions secara luas

• GitHub Action resmi dimanipulasi lewat pembaruan paksa tag, memicu serangan rantai pasok yang menyebarkan malware
• Penyerang mengganti 75 dari 76 tag ke commit berbahaya, berdampak pada sekitar lebih dari 10 ribu workflow
• Skrip yang dimanipulasi bekerja dalam 3 tahap: mengumpulkan, mengenkripsi, dan mengekfiltrasi rahasia, serta menyertakan kode TeamPCP Cloud stealer
• Tag yang terinfeksi masih aktif, dan dipastikan hanya @0.35.0 atau commit SHA tertentu yang aman
• Wajib mengganti semua kredensial dan menggunakan pin commit SHA, dan pencemaran yang sama juga dikonfirmasi pada image Docker Hub

---

Ringkasan serangan rantai pasok Trivy GitHub Actions

• GitHub Action resmi milik Trivy (aquasecurity/trivy-action) dimanipulasi oleh penyerang melalui force-push pembaruan tag, sehingga malware tersebar
• Penyerang mengganti 75 dari 76 tag versi ke commit berbahaya agar dieksekusi otomatis di pipeline CI/CD
• Sekitar lebih dari 10.000 file workflow GitHub merujuk ke action tersebut, sehingga cakupan dampaknya sangat luas
• Tag yang terinfeksi masih aktif, dan dipastikan hanya @0.35.0 yang merupakan versi aman
• Socket mendeteksi 182 event GitHub Action berbahaya secara real-time sejak 19:15 UTC, diklasifikasikan sebagai Backdoor, Infostealer, dan Reconnaissance

Penyebab dan cara serangan berlangsung

• Menurut maintainer Trivy, serangan ini terjadi akibat pencurian kredensial yang memiliki izin tulis
  • Pada kompromi sebelumnya di awal Maret, rahasia lingkungan CI bocor, dan proses rotasi tidak tuntas sehingga sebagian kredensial baru tetap berada di tangan penyerang
  • Penyerang memakai kredensial ini untuk melakukan pembaruan tag terautentikasi tanpa memanfaatkan kerentanan GitHub itu sendiri
• Alih-alih melakukan push branch atau membuat rilis, penyerang memaksa tag yang sudah ada agar menunjuk ke commit baru
  • Setiap tag dipalsukan agar tampak normal dengan menyalin metadata commit asli seperti penulis, email, stempel waktu, dan pesan commit
  • Namun commit asli ditandatangani GPG, sedangkan commit penyerang tidak memiliki tanda tangan, dan tanggal parent commit tidak konsisten karena berada di tahun 2026
• Meski GitHub menampilkan status Immutable Release, penyerang bisa saja memublikasikannya dalam kondisi berbahaya lalu menguncinya
  • Karena itu, jangan mengandalkan badge “Immutable”; hanya pinning commit SHA yang aman untuk konsumsi

Struktur manipulasi tag

• Penyerang membuat commit baru berdasarkan commit terbaru branch master (57a97c7e)
  • Hanya file entrypoint.sh yang diganti dengan versi berbahaya, sedangkan file lain tetap sama
  • Setiap tag dipalsukan dengan menyalin nomor PR, pesan commit, dan informasi penulis dari aslinya
• Jika halaman GitHub Release menampilkan “0 commits to master since this release”, itu bisa menjadi indikator visual tag yang telah dimanipulasi
• Satu-satunya alasan tag 0.35.0 tidak dimanipulasi adalah karena tag tersebut sudah menunjuk ke HEAD master

Struktur payload berbahaya

• entrypoint.sh yang dimanipulasi memiliki total 204 baris; baris 4~105 berisi kode Infostealer, lalu diikuti kode pemindaian Trivy yang normal
• Malware terdiri dari tiga tahap
  • Tahap 1: Collection — mengekstrak rahasia dari memori proses runner dan filesystem
  • Tahap 2: Encryption — mengenkripsi data yang dikumpulkan dengan AES-256-CBC dan RSA-4096
  • Tahap 3: Exfiltration — mengirimkannya ke domain yang dikendalikan penyerang atau ke akun GitHub korban

• Tahap 1: pengumpulan rahasia

  • Membaca variabel lingkungan dari proses runner GitHub Actions (Runner.Worker, Runner.Listener, runsvc, run.sh) melalui /proc/<pid>/environ, lalu mengekstrak entri yang memuat kata kunci env, ssh
  • Pada runner yang di-host GitHub, skrip memory dump berbasis Python dijalankan dengan sudo untuk mencari pola "isSecret":true di memori proses Runner.Worker
  • Pada runner self-hosted, dijalankan pengumpul kredensial filesystem yang diidentifikasi sebagai TeamPCP Cloud stealer
    • Targetnya sangat luas, termasuk SSH key, kredensial AWS/GCP/Azure, token Kubernetes, konfigurasi Docker, kata sandi DB, file environment, TLS key, konfigurasi VPN, URL webhook, kunci dompet, dan lainnya

• Tahap 2: enkripsi

  • Menghasilkan session key 32 byte dengan openssl rand, lalu mengenkripsi data memakai AES-256-CBC
  • Session key dienkripsi dengan public key RSA-4096 menggunakan padding OAEP
  • Data terenkripsi (payload.enc) dan session key (session.key.enc) dibundel menjadi tpcp.tar.gz

• Tahap 3: eksfiltrasi data

  • Kanal pertama: kirim HTTPS POST ke https://scan[.]aquasecurtiy[.]org (menggunakan domain typo dari aquasecurity)
  • Kanal kedua: jika gagal, memakai GitHub Personal Access Token milik korban untuk membuat repositori publik bernama tpcp-docs
    • Mengunggah tpcp.tar.gz sebagai release asset → penyerang lalu menemukan repositori itu lewat pencarian GitHub untuk mengambil data
  • Dengan memanfaatkan infrastruktur GitHub, penyerang berupaya melewati firewall dan meningkatkan peluang lolos deteksi
  • Terakhir, file sementara dihapus untuk meminimalkan jejak

Penyerang dan pihak di baliknya

• Komentar dalam kode berbahaya secara eksplisit menyebut “TeamPCP Cloud stealer”
  • TeamPCP (DeadCatx3, PCPcat, ShellForce) adalah kelompok penyerang lingkungan cloud-native, dengan riwayat eksploitasi Docker API, Kubernetes, Redis, dan dashboard Ray
  • Pada Februari 2026, Flare dan The Hacker News melaporkan mereka terkait kampanye ransomware, pencurian data, dan penambangan kripto
• Fitur untuk mengumpulkan kunci validator Solana dan dompet kripto sejalan dengan motif finansial

Tanggapan dan rekomendasi

• Hentikan penggunaan semua tag versi Trivy Action, dan gunakan hanya commit SHA 57a97c7e7821a5776cebc9bb87c984fa69cba8f1 atau tag 0.35.0
• Pipeline yang terinfeksi harus dianggap mengalami kebocoran rahasia total; semua kredensial cloud, SSH key, API token, kata sandi DB, dan token Docker harus segera diganti
• Disarankan memeriksa apakah ada repositori tpcp-docs di organisasi GitHub Anda dan meninjau log trivy-action yang berjalan setelah 19 Maret pukul 19:00 UTC

Indikator kompromi (IOCs)

• Indikator jaringan: scan[.]aquasecurtiy[.]org
• Hash file: 18a24f83e807479438dcab7a1804c51a00dafc1d526698a66e0640d1e5dd671a (entrypoint.sh)
• GitHub Actions yang terinfeksi: semua versi aquasecurity/trivy-action@0.0.1 ~ @0.34.2 (total 75 tag)

Pembaruan tambahan (22 Maret)

• Di Docker Hub, image Trivy (0.69.4, 0.69.5, 0.69.6, latest) juga dipastikan tercemar oleh payload Infostealer yang sama
• Tag latest ditetapkan ke image berbahaya dan didistribusikan ke pengguna selama periode paparan
• Detail terkait dapat dilihat dalam laporan terpisah Socket “Trivy Docker Images Compromised”

[GN⁺]

Opini Hacker News

• Penasaran kenapa GitHub tidak mewajibkan versioning yang immutable untuk Actions
  Panduan keamanannya memang menyarankan untuk me-pin ke commit SHA, tetapi rasanya masalah seperti ini bisa dikurangi jika Action tidak bisa dipublikasikan kecuali sudah di-pin

  • Diskusi seperti ini selalu punya dua sisi
    Dari sudut pandang tim keamanan, versi yang di-pin memang lebih aman, tetapi di sisi lain bisa berisiko jika pembaruan keamanan tidak terpasang otomatis
    Pada akhirnya dibutuhkan solusi yang memenuhi keduanya tanpa mengorbankan produktivitas
    Rasanya cocok disebut “paradoks pinning”
  • GitHub Actions mengikuti model tag git, jadi sepertinya sulit mengubah struktur saat ini
    Meski begitu, tetap harus mulai dikerjakan suatu saat nanti
  • Bagaimana jika versi yang di-pin ternyata sudah terkontaminasi sejak awal?
    Membiarkan pembaruan justru bisa meningkatkan keamanan
    Ini mirip perdebatan static linking vs dynamic linking
    Lagi pula, Trivy Action memang dirancang untuk selalu mengambil versi terbaru

• Insiden ini menjadi peringatan bahwa produk supply chain security pada praktiknya bisa sama rapuhnya dengan stack yang ingin mereka lindungi
  Terutama alat keamanan yang “berjalan di mana-mana” bisa menciptakan vektor serangan baru yang, dengan satu kali kompromi, langsung membahayakan sangat banyak pengguna sekaligus

• Awalnya saya kira Trivy gagal melakukan rotasi kredensial dengan benar
  Namun mereka menjelaskan bahwa “penyerang mungkin mengetahui token baru selama proses rotasi yang non-atomic”
  GitHub tidak menampilkan token lagi setelah diterbitkan, jadi ini bisa bergantung pada metode autentikasi yang dipakai

  • Pembuat OpenClaw juga bilang pernah mengalami hal serupa
    Begitu membuat organisasi GitHub baru, namanya langsung dibajak, sehingga mereka harus meminta GitHub melakukan pembuatan secara atomic

• Ini kasus yang sangat pas untuk ungkapan “harus memindai kerentanan, bukan menjadi kerentanan”

  • Sampai muncul lelucon, “jika kamu menatap kerentanan, kerentanan juga menatapmu”

• Ada insiden terkait: kompromi sementara pada supply chain Trivy

  • Istilah “sementara” terasa terlalu halus untuk menggambarkannya

• Pada 22 Maret, penyerang memublikasikan image DockerHub Trivy v0.69.5 dan v0.69.6 yang berbahaya dengan kredensial yang dicuri
  (tautan pengumuman keamanan)
  Ada dua insiden pada 19 dan 22 Maret, dan penyerang tampaknya terus mempertahankan akses meski sudah ada dua kali rotasi kredensial

  • Sebenarnya, sejak Februari sudah terjadi kompromi seluruh repositori, dan ini adalah serangan sukses ketiga oleh penyerang yang sama

• “Dua minggu terakhir adalah yang terburuk”
  Karena Trivy dibobol, banyak sekali laporan keamanan dan rapat yang harus ditangani

• Ini pelajaran bahwa “membuat perangkat lunak keamanan tidak otomatis berarti kompeten”
  Tim keamanan kami juga tiap bulan ingin memasang pemindai baru, tetapi kalau kami memberikan hak akses yang luas seperti yang mereka minta, kami mungkin sudah berkali-kali dibobol

  • Saya pernah mengaudit GitHub Actions milik Trivy, dan Action setup-trivy ternyata meng-clone branch utama apa adanya lalu menjalankan skrip shell
    Artinya, eksekusi kode arbitrer dimungkinkan di semua workflow CI
    Aqua dibobol awal bulan ini, lalu setelah dua kali kegagalan isolasi, akun Docker Hub mereka juga ikut ditembus
    Menurut saya sekarang mereka perlu bantuan dari pakar eksternal
  • Memberikan hak akses luas kepada “alat keamanan” bukan mengurangi risiko, melainkan menyebarkannya
    Kebanyakan cuma generator laporan yang berisik, dan saat penyerang sudah masuk ke dalam, alat itu tidak mampu bertahan sama sekali
    Pemindai baru seharusnya hanya boleh mengakses data read-only di sandbox terisolasi, dan jangan diberi hak produksi sampai benar-benar tervalidasi
    Kalau tidak, itu tak ada bedanya dengan mengunggah secret key ke pastebin
  • Keamanan perusahaan belakangan ini terasa seperti memasang solusi endpoint security di semua perangkat lalu mengirim semua log ke dashboard AI
    Jadinya seperti budaya keamanan “bergerak cepat dan merusak semuanya”
  • Di departemen keamanan, praktis tidak ada pilihan untuk berkata “tidak ada produk yang layak di pasar, jadi kami tidak akan memakai apa pun”
    Akibatnya muncul budaya mengadopsi perangkat lunak keamanan berkualitas rendah tanpa banyak pertimbangan
    Menurut saya Trivy sendiri tidak buruk, dan perusahaan kami juga memakainya
    Hanya saja kami me-pin versi dengan Nix dan menulis sendiri workflow Actions, jadi tidak terdampak oleh kompromi kali ini

• Penyerang yang sudah terautentikasi bisa melakukan force-update tag
  Ini sebenarnya bisa dicegah andaikan pengaturan lama GitHub, “larang penimpaan tag”, diaktifkan
  Semakin sering insiden seperti ini terjadi, semakin kuat rasanya kebutuhan akan standar seperti Software Building Code
  Saya penasaran berapa banyak alasan tambahan seperti ini yang akan muncul pada 2026