· kaynak dev.to (home feed)
npm paket imzaları Shai-Hulud solucanını neden durduramadı
Shai-Hulud, çalınmış maintainer kimlik bilgileriyle kötü amaçlı paket sürümleri yayınladığı için npm üzerinde yayıldı; böylece imza doğrulamaları geçti. dev.to analizinde, token sızdığında kimlik doğrulamasının neden başarısız olduğu açıklanıyor.

Shai-Hulud olarak bilinen kendi kendini çoğaltan bir solucan, 2025 yılının sonlarında maintainer hesaplarını ele geçirerek ve bu maintainerların zaten kontrol ettiği paketlere kötü amaçlı güncellemeler göndererek npm registry üzerinde yayıldı. Sonatype'ın tedarik zinciri zaman çizelgesine dayanan bir dev.to analizine göre kampanya 180'den fazla npm paketini etkiledi ve Mayıs 2026'ya gelindiğinde TeamPCP ya da "Mini Shai-Hulud" olarak adlandırılan bir halef örüntü ortaya çıktı — güvenlik ekiplerinin kendilerinin bağımlı olduğu paketlere ulaştı.
Yazıya göre rahatsız edici olan ayrıntı, bir registry'nin zehirlenmiş olması değil. Zehirlenen sürümlerin geçerli yayıncı kimlik bilgileri taşıması; bütünlük mekanizmalarının tam olarak garanti etmesi gereken şeyin bu olması. Kimlik bilgisi zincirindeki hiçbir şey sahtelenmedi; saldırgan sadece anahtarların elindeydi.
Kimlik bilgileri nasıl ele geçirildi
İlk erişim, registry'nin kendisi yerine geliştiricinin ortamına odaklandı. Belgelenmiş giriş yolları arasında ele geçirilmiş CI/CD workflow'ları, kötü amaçlı pull request'ler, kurulum sırasında çalışan typosquat ve dependency-confusion paketleri, ele geçirilmiş maintainer hesapları ve geliştirici makinelerindeki infostealer kötü amaçlı yazılımları yer alıyor.
2026 TanStack olayı bunun ne kadar hızlı geliştiğini gösteriyor. dev.to analizinde bildirildiği gibi, altı dakikalık bir süre içinde 42 pakete yaklaşık 84 kötü amaçlı sürüm düştü; daha sonra bu sayı 170'ten fazla pakete ve 404 kötü amaçlı sürüme genişledi. Olaya 9.6 CVSS puanıyla CVE-2026-45321 tanımlayıcısı atandı.
Temel zafiyet kavramsal: imzalar ve provenance kanıtları bir sürümü kimin yayınladığını belirler, bunu yapmak isteyip istemediğini asla. Bir saldırgan maintainer token'ını kontrol ettiğinde, bir sürümün gerçek sahibinden gelip gelmediğini soran her aşağı akış kontrolü evet yanıtı verir.
Kurulum betikleri zararı neden büyütüyor
Preinstall ve postinstall gibi yaşam döngüsü hook'ları, native bağımlılıkların derlenebilmesi için var; bu da onları tasarım gereği rastgele kod çalıştırma haline getiriyor. Bunları çalıştıran her paket, ulaştığı ortamı okuyabilir — ve CI/CD'de bu ortamda deployment anahtarları, bulut sağlayıcı token'ları, registry parolaları ve veritabanı bağlantı dizeleri bulunur.
Analiz, araç zincirinin başka bir yerindeki paralel bir başarısızlığa işaret ediyor: Temmuz 2026'da atanan CVE-2026-47751 olarak izlenen Claude Code Action zafiyeti. Oradaki bir workflow, saldırgan kontrollü bir pull request dalını checkout etti, o daldaki bir yapılandırma dosyasını okudu ve dosyada bildirilen sunucuları otomatik olarak onayladı — katılımcıya runner üzerinde kod çalıştırma imkanı verdi. Her iki durumda da güven modeli, kriptografi devreye girmeden önce çoktan bozulmuştu.
Sonucu değiştiren kontroller
- Sabitle ve doğrula: bütünlük hash'leriyle kilit dosyaları, yalnızca incelenmiş sürümleri sunan iç mirror'lar ve beklenen pencerenin dışında yayınlanan sürümleri reddeden kabul kontrolleri, zehirli bir sürümün üretime ulaşmasının maliyetini yükseltir.
- Mümkünse kurulum betiklerini devre dışı bırakın: bunlardan vazgeçebilen projeler, bağımlılık yolundan tüm bir çalıştırma primitifini kaldırır.
- CI/CD'ye ayrıcalıklı muamele edin: token'ları iş başına kapsamlandırın, uzun ömürlü bulut anahtarları yerine kısa ömürlü workload identity tercih edin, secret okuyan workflow'ları kimin tetikleyebileceğini kısıtlayın ve güvenilmeyen bir daldan gelen yapılandırmayı asla otomatik onaylamayın.
- Geliştirici uç noktasını sağlamlaştırın: infostealer'ların yeni bir tekniğe ihtiyacı yok, yalnızca bir tarayıcı profiline. Uç nokta tespiti, tarayıcı eklentisi allowlist'leri ve token'ları bir dotfile yerine secrets manager'da saklamak pratik karşı önlemlerdir.
- Solucan benzeri davranışa dikkat edin: bir hesabın kısa bir pencerede çok sayıda pakete yayın yapması veya yeni sürümlerin kurulum sırasında ağ çağrıları eklemesi, bir advisory beklemeye gerek kalmadan tespit edilebilir.
Neden önemli
Provenance ve imzalama, hangi kimliğin bir artifact ürettiğini yanıtlar; o kimliğin onay verip vermediğini yanıtlayamaz. 2025 ve 2026'nın npm kampanyaları, bir paket ekosistemindeki en zayıf halkanın genellikle yayın haklarına sahip bir insan hesabı olduğunu ve o hesaba giden en hızlı yolun token'ını tutan dizüstü bilgisayardan veya pipeline'dan geçtiğini hatırlatıyor. Registry tarafındaki bütünlük araçları ancak yayıncı tarafındaki erişim kontrolü eşit derecede güçlüyse işe yarar — bu ders, aynı güven varsayımları üzerine kurulmuş her registry ve build sistemine kadar uzanıyor.
- #npm
- #supply-chain-security
- #malware
- #ci-cd
- #package-management