Trivy yeniden saldırı altında: Geniş çaplı GitHub Actions etiket manipülasyonu gizli bilgileri sızdırıyor

• Resmî GitHub Action, etiketlerin zorla güncellenmesi yoluyla manipüle edilerek kötü amaçlı kodun dağıtıldığı bir tedarik zinciri saldırısına uğradı
• Saldırganlar, 76 etiketin 75’ini kötü amaçlı commit ile değiştirdi; yaklaşık 10 binden fazla workflow etkilendi
• Manipüle edilen betik, gizli bilgi toplama·şifreleme·sızdırma olmak üzere 3 aşamada çalışıyor ve TeamPCP Cloud stealer kodunu içeriyor
• Enfekte etiketler hâlâ aktif; yalnızca @0.35.0 veya belirli commit SHA güvenli kabul ediliyor
• Tüm kimlik bilgilerinin değiştirilmesi ve commit SHA sabitleme kullanılması zorunlu; Docker Hub imajlarında da aynı kirlenme doğrulandı

---

Trivy GitHub Actions tedarik zinciri saldırısına genel bakış

• Trivy’nin resmî GitHub Action’ı (aquasecurity/trivy-action), saldırganlar tarafından etiketlerin zorla güncellenmesi (force-push) yöntemiyle manipüle edilerek kötü amaçlı kodun dağıtıldığı bir olay yaşandı
• Saldırganlar, 76 sürüm etiketinden 75’ini kötü amaçlı commit ile değiştirdi ve bunun CI/CD pipeline’larında otomatik çalışmasını sağladı
• Yaklaşık 10.000’den fazla GitHub workflow dosyası bu action’a referans verdiği için etki alanı oldukça geniş
• Enfekte etiketler hâlâ aktif ve @0.35.0 tek güvenli sürüm olarak doğrulandı
• Socket, 19:15 UTC’den itibaren gerçek zamanlı olarak 182 kötü amaçlı GitHub Action olayını tespit etti ve bunları Backdoor, Infostealer ve Reconnaissance türlerinde sınıflandırdı

Saldırının nedeni ve ilerleyiş biçimi

• Trivy bakımcılarına göre bu saldırı, yazma yetkisine sahip kimlik bilgilerinin ele geçirilmesi nedeniyle gerçekleşti
  • Mart başında yaşanan önceki ihlalde CI ortamındaki gizli bilgiler sızdırıldı ve rotasyon süreci eksik kaldığı için bazı yeni kimlik bilgileri saldırganların elinde kaldı
  • Saldırganlar bu kimlik bilgilerini kullanarak, GitHub’ın kendisinde bir zafiyet olmadan kimliği doğrulanmış etiket güncellemeleri yaptı
• Saldırganlar branch push veya release oluşturmak yerine, mevcut etiketlerin üzerine zorla yeni commit yazdı
  • Her etiket, meşru görünmesi için orijinal commit’in meta verilerini (yazar, e-posta, zaman damgası, commit mesajı) kopyalayacak şekilde sahte olarak üretildi
  • Ancak orijinal commit GPG ile imzalıyken saldırganın commit’lerinde imza yoktu ve parent commit tarihi 2026 olarak tutarsızdı
• GitHub’daki Immutable Release işareti bulunsa bile, saldırganın önce kötü amaçlı durumda yayımlayıp sonra kilitlemiş olması mümkün
  • Bu nedenle “Immutable” rozetine güvenilmemeli; güvenli tüketim için tek yöntem commit SHA sabitleme (pinning)

Etiket manipülasyonunun yapısı

• Saldırganlar, master branch’inin en son commit’i (57a97c7e) temel alınarak yeni commit’ler oluşturdu
  • Yalnızca entrypoint.sh dosyası kötü amaçlı sürümle değiştirildi, diğer dosyalar aynı bırakıldı
  • Her etiket, orijinal PR numarasını, commit mesajını ve yazar bilgilerini aynen kopyalayarak sahte biçimde yeniden üretildi
• GitHub release sayfasında “0 commits to master since this release” ifadesi görünüyorsa, bu manipüle edilmiş etiketin görsel göstergesi olabilir
• 0.35.0 etiketinin manipüle edilmemesinin nedeni, zaten master HEAD’ini işaret ediyor olmasıydı

Kötü amaçlı payload yapısı

• Manipüle edilen entrypoint.sh toplam 204 satırdan oluşuyor; 4~105. satırlar Infostealer kodunu, sonrasında ise normal Trivy tarama kodunu içeriyor
• Kötü amaçlı kod üç aşamadan oluşuyor
  • 1. aşama: Toplama (Collection) — runner süreç belleğinden ve dosya sisteminden gizli bilgileri çıkarma
  • 2. aşama: Şifreleme (Encryption) — toplanan verileri AES-256-CBC ve RSA-4096 ile şifreleme
  • 3. aşama: Sızdırma (Exfiltration) — verileri saldırgan kontrollü domaine veya kurbanın GitHub hesabına gönderme

• 1. aşama: Gizli bilgi toplama

  • GitHub Actions runner süreçlerinin (Runner.Worker, Runner.Listener, runsvc, run.sh) ortam değişkenleri /proc/<pid>/environ üzerinden okunuyor ve env, ssh anahtar sözcüklerini içeren girdiler ayıklanıyor
  • GitHub tarafından barındırılan runner’larda Python tabanlı bellek dökümü betiği sudo ile çalıştırılıyor ve Runner.Worker süreç belleğinde "isSecret":true deseni aranıyor
  • Self-hosted runner’larda, TeamPCP Cloud stealer olarak tanımlanan dosya sistemi kimlik bilgisi toplayıcısı çalıştırılıyor
    • SSH anahtarları, AWS/GCP/Azure kimlik bilgileri, Kubernetes token’ları, Docker yapılandırmaları, DB parolaları, ortam dosyaları, TLS anahtarları, VPN yapılandırmaları, Webhook URL’leri, cüzdan anahtarları gibi çok geniş bir hedef kümesini kapsıyor

• 2. aşama: Şifreleme

  • openssl rand ile 32 baytlık bir oturum anahtarı oluşturuluyor, ardından veriler AES-256-CBC ile şifreleniyor
  • Oturum anahtarı, RSA-4096 açık anahtarıyla OAEP padding uygulanarak şifreleniyor
  • Şifrelenmiş veriler (payload.enc) ve oturum anahtarı (session.key.enc) tpcp.tar.gz içine paketleniyor

• 3. aşama: Veri sızdırma

  • Birincil kanal: https://scan[.]aquasecurtiy[.]org adresine HTTPS POST gönderimi (aquasecurity yazım hatalı domain kullanılıyor)
  • İkincil kanal: Başarısız olursa kurbanın GitHub Personal Access Token’ı kullanılarak tpcp-docs adlı herkese açık bir depo oluşturuluyor
    • tpcp.tar.gz, release varlığı olarak yükleniyor → saldırgan GitHub aramasıyla bu depoyu bularak veriyi topluyor
  • GitHub altyapısı kullanılarak güvenlik duvarı atlatılmaya çalışılıyor, bu da tespit edilmeden kalma olasılığını artırıyor
  • Son olarak geçici dosyalar silinerek izler en aza indiriliyor

Saldırganlar ve arka plan

• Kötü amaçlı kod içindeki yorumlarda “TeamPCP Cloud stealer” ifadesi açıkça yer alıyor
  • TeamPCP (DeadCatx3, PCPcat, ShellForce), cloud-native ortamları hedef alan bir saldırı grubu olarak biliniyor; Docker API, Kubernetes, Redis ve Ray dashboard zafiyetlerini istismar ettiği vakalar bulunuyor
  • 2026 Şubat’ında Flare ve The Hacker News tarafından fidye yazılımı, veri hırsızlığı ve kripto para madenciliği kampanyaları ile ilişkilendirildiği bildirildi
• Solana doğrulayıcı anahtarları ve kripto para cüzdanlarını toplama işlevi, finansal motivasyonla uyumlu görünüyor

Müdahale ve öneriler

• Tüm Trivy Action sürüm etiketlerinin kullanımı durdurulmalı; yalnızca commit SHA 57a97c7e7821a5776cebc9bb87c984fa69cba8f1 veya 0.35.0 etiketi kullanılmalı
• Enfekte pipeline’lar tam gizli bilgi sızıntısı olarak değerlendirilmelidir; tüm bulut kimlik bilgileri, SSH anahtarları, API token’ları, DB parolaları ve Docker token’ları derhâl değiştirilmelidir
• GitHub organizasyonunda tpcp-docs deposunun varlığı kontrol edilmeli ve 19 Mart 19:00 UTC sonrasında çalıştırılan trivy-action loglarının incelenmesi önerilir

İhlal göstergeleri (IOCs)

• Ağ göstergesi: scan[.]aquasecurtiy[.]org
• Dosya hash’i: 18a24f83e807479438dcab7a1804c51a00dafc1d526698a66e0640d1e5dd671a (entrypoint.sh)
• Enfekte GitHub Actions: aquasecurity/trivy-action@0.0.1 ~ @0.34.2 arasındaki tüm sürümler dahil (toplam 75 etiket)

Ek güncelleme (22 Mart)

• Docker Hub’da da Trivy imajlarının (0.69.4, 0.69.5, 0.69.6, latest) aynı Infostealer payload ile kirletildiği doğrulandı
• latest etiketi kötü amaçlı imaja işaret edecek şekilde ayarlandığı için maruz kalma süresi boyunca kullanıcılara dağıtıldı
• İlgili ayrıntılar, Socket’in ayrı raporu “Trivy Docker Images Compromised” içinde bulunabilir

[GN⁺]

Hacker News görüşleri

• GitHub'ın Actions için değiştirilemez sürümlendirmeyi (immutable versioning) neden zorunlu kılmadığını merak ediyorum
  Güvenlik rehberi commit SHA'ya sabitlemeyi (pin) öneriyor ama hiç sabitlemeden Action yayımlamayı baştan engelleseler bu tür sorunlar azalabilirmiş gibi geliyor

  • Bu tür tartışmalarda her zaman iki taraflı bir durum var
    Güvenlik ekibi açısından sabitlenmiş sürümler daha güvenli, ama aynı zamanda güvenlik güncellemelerinin otomatik alınmaması da riskli
    Sonuçta üretkenliği bozmadan ikisini birden sağlayan bir çözüme ihtiyaç var
    Buna “Pinning paradoksu” demek isterim
  • GitHub Actions'ın git etiket modelini izlediğini düşünüyorum, bu yüzden mevcut yapıyı değiştirmek zor
    Yine de bir gün bunu değiştirme işine başlamak gerekecek
  • Ya sabitlediğiniz sürüm zaten kirlenmiş durumdaysa?
    Güncellemelere izin vermek aslında güvenliği artırabilir
    Bu, statik bağlantı vs dinamik bağlantı tartışmasına benzer bir mesele
    Ayrıca Trivy Action zaten en güncel sürümü alacak şekilde tasarlanmıştı

• Bu olay, “tedarik zinciri güvenliği (supply chain security)” ürünlerinin pratikte korumaya çalıştıkları yığın kadar kırılgan olabileceğini gösteren bir uyarı
  Özellikle “her yerde çalışın” tarzı güvenlik araçları, tek bir saldırıyla çok sayıda kullanıcıyı aynı anda riske atan yeni bir saldırı vektörü sunuyor

• İlk başta Trivy'nin kimlik bilgisi rotasyonunu düzgün yapmadığını sanmıştım
  Ama onların açıklamasına göre “atomik olmayan (non-atomic) rotasyon sürecinde saldırgan yeni token'ı öğrenmiş olabilir”
  GitHub token'ı oluşturulduktan sonra tekrar göstermiyor, ama kullanılan kimlik doğrulama yöntemine göre durum değişebilir

  • OpenClaw'ın geliştiricisi de benzer bir şey yaşadığını söylemiş
    Yeni bir GitHub organizasyonu oluşturur oluşturmaz isim ele geçirilmiş ve GitHub'dan atomik oluşturma işlemi talep etmek zorunda kalmış

• “Açıkları taramalısın, açığın kendisi olmamalısın” sözü bu olay için tam yerine oturuyor

  • Hatta “Açığa bakarsan, açık da sana bakar” diye şaka yapılıyor

• İlgili bir olay olarak Trivy tedarik zincirinin geçici ihlali vardı

  • “Geçici” ifadesi bana fazla yumuşatılmış geliyor

• 22 Mart'ta saldırgan, ele geçirilmiş kimlik bilgileriyle kötü amaçlı Trivy v0.69.5 ve v0.69.6 DockerHub imajları yayımladı
  (güvenlik duyurusu bağlantısı)
  19 Mart ve 22 Mart'ta iki ayrı olay yaşandı ve saldırganın, iki kez yapılan kimlik bilgisi rotasyonuna rağmen erişimi sürdürdüğü anlaşılıyor

  • Aslında Şubat ayından beri tüm depoyu kapsayan bir ihlal vardı ve bu, aynı saldırganın gerçekleştirdiği üçüncü başarılı saldırıydı

• “Son 2 hafta berbat geçti”
  Trivy'nin ele geçirilmesi yüzünden çok sayıda güvenlik raporu ve toplantısıyla uğraşmak zorunda kalmışlar

• Buradaki ders şu: “güvenlik yazılımı yapmak, mutlaka yetkin olduğun anlamına gelmez”
  Bizim güvenlik ekibimiz de her ay yeni bir tarayıcı getirmeye çalışıyor ama onların istediği geniş erişim izinlerini versek şimdiye kadar muhtemelen defalarca ihlal edilmiştik

  • Daha önce Trivy'nin GitHub Actions'ını denetlemiştim (audit); setup-trivy Action'ı ana dalı olduğu gibi klonlayıp shell script çalıştırıyordu
    Yani tüm CI iş akışlarında keyfi kod çalıştırma mümkündü
    Aqua bu ayın başında ihlal edildi, iki kez izolasyon başarısızlığı yaşandı ve sonunda Docker Hub hesabı da ele geçirildi
    Artık dış uzmanlardan yardım almaları gerektiğini düşünüyorum
  • “Güvenlik araçlarına” geniş erişim izinleri vermek, riski azaltmak değil riski yaymaktır
    Çoğu sadece gürültülü rapor üreticisi ve saldırgan içeri girdiğinde hiçbir savunma sağlayamıyor
    Yeni bir tarayıcı, izole bir sandbox içinde yalnızca salt okunur verilere erişebilmeli ve yeterince doğrulanana kadar üretim izinleri almamalı
    Aksi halde bu, gizli anahtarları pastebin'e koymaktan farksız
  • Günümüz kurumsal güvenliği, her cihaza uç nokta güvenlik çözümü kurup tüm logları bir AI panosuna göndermek gibi ilerliyor
    “Hızlı hareket et ve her şeyi kır” türü bir güvenlik kültürü oluşmuş durumda
  • Güvenlik ekiplerinin fiilen “piyasada işe yarar ürün yok, o yüzden hiçbir şey kullanmayacağız” deme şansı yok
    Bu yüzden düşük kaliteli güvenlik yazılımlarını bile mecburen devreye alma kültürü oluşuyor
    Bence Trivy'nin kendisi kötü değil ve bizim şirket de kullanıyor
    Ama biz Nix ile sürümü sabitleyip Actions iş akışlarını kendimiz yazdığımız için bu ihlalden etkilenmedik

• Saldırgan, kimliği doğrulanmış durumdayken etiketi zorla güncelleyebiliyordu (force-update)
  GitHub'ın eski ayarlarından “etiketin üzerine yazmayı yasakla” seçeneği açık olsaydı bu engellenebilirdi
  Bu tür olaylar tekrarlandıkça Software Building Code benzeri standartlara ihtiyaç olduğu düşüncesi güçleniyor
  2026'da bunun için daha kaç gerekçe çıkacağını merak ediyorum