GitHub Actions’da Mini Shai-Hulud Tehdidi Yeniden Canlandı

Yazılım geliştirme dünyasının kritik bileşenlerinden GitHub Actions zararlı yazılım tehlikesiyle bir kez daha gündeme geldi. Geçtiğimiz günlerde, daha önce Mayıs 2026’daki kapsamlı Mini Shai-Hulud kampanyasında ele geçirilen iki popüler GitHub Action’ın kısa süreliğine tekrar erişilebilir hale gelmesi, yazılım tedarik zinciri güvenliği endişelerini tazeledi. Bu durum, temizlenmemiş zararlı kodun binlerce projede potansiyel olarak yeniden çalışmasına zemin hazırlayarak ciddi bir risk oluşturdu.

Ele Geçirilen Aksiyonlar ve Olayın Tekrarı

Bahsi geçen güvenlik açığı, yaygın olarak kullanılan actions-cool/issues-helper ve actions-cool/maintain-one-comment adlı GitHub Actions’ları üzerinde yoğunlaştı. Bu aksiyonlar, geliştirme ekiplerinin iş akışlarını otomatikleştirerek sorun takibi ve yorum yönetimi gibi görevleri kolaylaştıran araçlar olarak biliniyor. Ancak Mayıs 2026’da bu depolar, Mini Shai-Hulud adı verilen geniş çaplı bir tedarik zinciri saldırısının hedefi olmuştu.

Saldırının ardından devre dışı bırakılan depolar, 16 Eylül 2026 tarihinde, bilinmeyen bir nedenle tekrar erişilebilir hale geldi. Socket araştırmacısı Karlo Zanki’nin açıklamasına göre, depoların yeniden etkinleşmesiyle birlikte, içerideki kötü amaçlı yazılım ne yazık ki temizlenmemişti. Bu durum, sürüm etiketleriyle (release tags) bu aksiyonları referans alan tüm iş akışlarının, bir sonraki çalıştırmalarında zararlı yükü otomatik olarak indirip yürütmesine yol açtı. GitHub personeli durumu fark ettiğinde, aksiyonlar ikinci kez devre dışı bırakıldı ve depoların erişimi engellendi. Şu anda bu depolara erişmeye çalışanlar, GitHub’ın hizmet koşulları ihlali nedeniyle erişimin kapatıldığı uyarısıyla karşılaşıyor.

Mini Shai-Hulud’un Teknik İşleyişi

Mini Shai-Hulud zararlı yazılımının teknik altyapısı, özellikle sürekli entegrasyon ve sürekli dağıtım (CI/CD) işlem hatlarını hedef almasıyla dikkat çekiyor. İlk olarak 18 Mayıs 2026 tarihinde bu GitHub Actions’lara enjekte edilen kötü amaçlı kod, çalıştığı her ortamda hassas kimlik bilgilerini toplamaya odaklanmıştı. Bu bilgiler arasında API anahtarları, belirteçler ve diğer gizli veriler bulunuyordu. Ele geçirilen bu veriler daha sonra saldırgan kontrolündeki t.m-kosche[.]com sunucusuna sızdırılıyordu.

Socket Tehdit İstihbarat Başkanı Philipp Burckhardt, ilk saldırı döneminde bu aktivitenin ‘@antv’ ekosistemindeki npm paketleriyle kullanılan sızdırma alanıyla örtüştüğünü belirtmişti. Bu bağlantı, olayların ayrı ayrı değil, aynı Mini Shai-Hulud aktivite kümesinin bir parçası olduğunu gösteriyor. En son olayda ise tehlikenin boyutu daha da arttı; kötü amaçlı kodun temizlenmemesi, saldırganların yeni bir istismar mekanizması geliştirmesine veya yeni bir altyapı kurmasına gerek kalmadan, sadece depoların yeniden erişilebilir olmasıyla tehdidin otomatik olarak aktive olmasına neden oldu. Bu durum, yazılım tedarik zincirinde sürekli denetimin ve kod tabanı temizliğinin hayati önemini bir kez daha ortaya koydu.

Yazılım Tedarik Zincirine Yönelik Etkileri

Bu tür olayların yazılım tedarik zinciri güvenliği üzerindeki etkisi oldukça geniş kapsamlıdır. GitHub Actions gibi otomasyon araçları, modern yazılım geliştirme süreçlerinin vazgeçilmez bir parçasıdır. Geliştiriciler, bu aksiyonları genellikle günlük periyotlarla veya belirli olaylar (yeni bir sorun açılması, çekme isteği gönderilmesi gibi) tetiklendiğinde çalışacak şekilde yapılandırır. Depoların 16 Eylül’deki kısa süreli yeniden etkinleşmesi, birçok etkilenen deponun zararlı yazılımı bir gün içinde çalıştırmasına neden olmuş olabilir.

Bu durum, doğrudan kullanılan projelerin CI/CD ortamlarında depolanan tüm hassas sırların (API anahtarları, veritabanı kimlik bilgileri, bulut erişim anahtarları) açığa çıkma potansiyeli taşıdığı anlamına geliyor. Bir tedarik zinciri saldırısında, bir bileşenin güvenliğinin ihlal edilmesi, zincirdeki tüm bağımlı projelere ve nihayetinde son kullanıcılara kadar yayılabilen bir risk silsilesi yaratır. Bu olay, üçüncü taraf bağımlılıklarına olan güvenin ve bunların sürekli denetiminin ne denli kritik olduğunu acı bir şekilde gösteriyor. Özellikle saldırganların yeni bir zafiyet bulma çabasına girmeden, sadece mevcut temizlenmemiş kod sayesinde otomatik olarak yeniden saldırı gerçekleştirebilmesi, modern güvenlik stratejilerinde yeni bir boyut oluşturuyor.

Geliştiriciler İçin Güvenliği Yeniden Sağlama Adımları

Bu olaydan etkilenme potansiyeli olan geliştiriciler ve proje yöneticileri için acil önlemler almak büyük önem taşıyor. GitHub, depoları tekrar devre dışı bırakmış olsa da, geçmişteki çalıştırmalar ve potansiyel olarak ele geçirilmiş sırlar hala risk oluşturabilir. Socket araştırmacılarının önerdiği adımlar, bu tür tehditlere karşı korunmak için kritik bir yol haritası sunuyor:

• Etkilenen Aksiyonları Tespit Edin: Projelerinizde actions-cool/issues-helper ve actions-cool/maintain-one-comment aksiyonlarına yapılan tüm referansları bulun. Özellikle actions-cool/issues-helper@v2.2.1 sürümünün de etkilenenler arasında olduğunu unutmayın.
• Güvenli Sürüme Sabitleyin: Etkilenen aksiyonları iş akışlarınızdan kaldırın. Ardından, bu aksiyonları kullanmaya devam etmeniz gerekiyorsa, 18 Mayıs 2026 öncesindeki bilinen temiz bir commit SHA’sına sabitleyerek kullanın. Bu, zararlı kodun önceki güvenli bir sürümünü çalıştırmanızı sağlar.
• Maruz Kalmış Sırları Değiştirin: CI/CD işlem hattınızda bu aksiyonlarla birlikte kullanılan tüm hassas sırları (API anahtarları, tokenlar, parolalar vb.) derhal değiştirin (rotate edin). Herhangi bir ihlal olasılığına karşı bu adım hayati öneme sahiptir.
• İş Akışı Geçmişini İnceleyin: Depoların 16 Eylül 2026 tarihinde yeniden etkinleşmesinden sonraki iş akışı çalıştırma geçmişinizi dikkatlice gözden geçirin. Bu tarihten sonra gerçekleşen şüpheli veya beklenmedik başarılı çalıştırmaları arayın.

Bu adımlar, mevcut riskleri azaltmanın yanı sıra, gelecekte benzer saldırılara karşı daha dirençli bir duruş sergilemenize yardımcı olacaktır.

Tedarik Zinciri Saldırılarında Yeni Bir Paradigmaya Doğru

GitHub Actions’taki bu olay, yazılım tedarik zinciri güvenliğine yönelik süregelen zorlukların altını bir kez daha çiziyor. Bir güvenlik ihlalinin ardından zararlı kodun temizlenmemesi ve sistemlerin beklenmedik bir şekilde yeniden aktif hale gelmesi, saldırganlara sıfır çaba ile aynı tehdidi tekrar yayma fırsatı sunuyor. Bu durum, sadece yeni zafiyetlerin keşfedilmesine odaklanan geleneksel güvenlik yaklaşımlarının ötesine geçerek, sürekli denetim, kapsamlı temizlik prosedürleri ve bağımlılıkların yaşam döngüsü boyunca izlenmesinin ne kadar önemli olduğunu gösteriyor.

Karlo Zanki’nin belirttiği gibi, “Sürüm etiketleri ilk başta temizlenmedi. Hala 18 Mayıs’ta tanıtılan kötü amaçlı içeriği işaret ediyorlardı, bu yüzden herhangi bir sürüm etiketiyle eylemi referans alan herhangi bir iş akışı, bir sonraki çalıştırmasında yükü indirmeye ve yürütmeye devam etti.”

Bu açıklama, sorunun temelini net bir şekilde ortaya koyuyor. Yazılım geliştirme ekosistemlerinin karmaşıklığı arttıkça, üçüncü taraf bağımlılıklarının ve otomasyon araçlarının güvenliği, tek bir zayıf halka nedeniyle tüm yapıyı riske atabilecek kritik bir faktör haline geliyor. Geliştiricilerin ve güvenlik ekiplerinin bu yeni paradigmaya uyum sağlaması, sürekli tetikte olması ve otomasyonun getirdiği kolaylıkların yanı sıra potansiyel riskleri de titizlikle yönetmesi gerekiyor. Aksi takdirde, eski tehditler beklenmedik anlarda yeniden canlanarak ciddi güvenlik açıklarına yol açabilir.