Chalk ve Shai-Hulud: Eylül 2025 npm tedarik zinciri saldırılarının içinde

Oltalanan bir maintainer ve 18 zehirli paket

8 Eylül 2025'te bir saldırgan, tanınmış bir paket maintainer'ının npm hesabını oltalama yoluyla ele geçirdi ve bu hesabı, chalk ve debug yardımcı programlarının da aralarında bulunduğu 18 yaygın paketin düşmanca yeni sürümlerini yayınlamak için kullandı; bu bilgiler olaylara ilişkin bir dev.to yazısından. Bunlar küçük kütüphaneler ama devasa sayıda projenin bağımlılık ağacının derinliklerinde yer alıyorlar ve haftada toplam milyarlarca indirilmeye sahipler.

Enjekte edilen kod, tarayıcıda çalışan kripto para cüzdanı işlemlerini yakalamayı ve yönlendirmeyi denedi. Zehirli sürümler kayıt defterinden birkaç saat içinde kaldırıldı, ancak bu pencere içinde install komutu çalıştıran her proje bunları otomatik olarak aldı — kurbanın kendi koduna veya sunucularına sızmaya gerek yoktu.

Shai-Hulud: kayıt defterinin içindeki bir solucan

Yaklaşık bir hafta sonra daha ciddi bir tehdit ortaya çıktı: Shai-Hulud, kendi başına yayılabilen kötü amaçlı yazılım. Bir geliştirici enfekte bir paket kurduğunda, solucan makinede secret aramaya başladı — GitHub token'ları ile AWS, Google Cloud ve Azure için cloud kimlik bilgileri — bunları saldırganlara gönderdi ve 'Shai-Hulud' adlı herkese açık bir GitHub deposunda yayınladı. Ardından geliştiricinin kendi npm erişimini kullanarak, geliştiricinin maintainsi yaptığı diğer paketlere kendini enjekte etti ve bunları yeniden yayınlayarak kendi kendine yayılan bir enfeksiyon zinciri oluşturdu.

ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı (CISA), 23 Eylül 2025'te 500'den fazla paketin tehlikeye atıldığını bildirdi. npm'i işleten GitHub, enfekte paketleri sildi ve solucanın imzalarıyla eşleşen yüklemeleri engelledi. dev.to yazısı, kampanyanın sonraki dalgalarının yüzlerce pakete daha isabet ettiğini belirtiyor.

GitHub'ın npm'i sıkılaştırması

Olayların ardından GitHub, npm yayın süreçlerini sağlamlaştırmak için bir plan duyurdu:

• Yayına yalnızca 2FA korumalı yerel publish, kısa ömürlü granular token'lar veya güvenilir yayınlama (trusted publishing) üzerinden izin vermek
• Eski classic token'ları kullanımdan kaldırmak
• Authenticator uygulaması kodlarından (TOTP) oltalamaya dayanıklı FIDO tabanlı 2FA'ya geçmek
• Paketleri uzun ömürlü token'lar yerine kısa ömürlü OIDC kimlik bilgileriyle doğrudan CI'dan iten güvenilir yayınlamayı (trusted publishing) genişletmek

Ortak payda, her iki saldırıyı da mümkün kılan uzun ömürlü ve oltalanabilir kimlik bilgilerini ortadan kaldırmak.

Kendi derlemelerinizi sağlamlaştırmak

Kayıt defteri düzeyindeki değişiklikler maintainer'ları korur, ama her ekip yine de projelerini savunmak zorunda. dev.to yazısı pratik bir kontrol listesi sunuyor:

• Lockfile'ı commit edin (package-lock.json, pnpm-lock.yaml veya yarn.lock) ve CI'da npm ci gibi komutlarla kurulumu ondan yapın; böylece derlemeler asla sessizce daha yeni bir sürümü almaz.

• Yeni bağımlılık sürümlerini benimsemeden önce birkaç gün bekleyin; kötü amaçlı sürümlerin çoğu birkaç saat veya gün içinde yakalanır ve Renovate ile Dependabot gibi araçlar gecikmeli çalışacak şekilde yapılandırılabilir.

• Kurulum script'lerini kısıtlayın, çünkü birçok saldırı kurulum sırasında çalışır — örneğin pnpm, açıkça izin verilmedikçe bağımlılık yaşam döngüsü script'lerini engelleyebilir.

• Çoğu planda ücretsiz olan Dependabot güvenlik güncellemelerini ve GitHub secret scanning'i etkinleştirin.

• Kullanılmayan bağımlılıkları kaldırın ve kalanları yılda bir veya iki kez denetleyin; her paket bir saldırı yüzeyidir.

• GitHub, npm ve cloud konsollarında CISA'nın özellikle önerdiği oltalamaya dayanıklı 2FA kullanın (güvenlik anahtarları veya passkey).

• Uzun ömürlü secret'ları geliştirici dizüstü bilgisayarlarından uzak tutup kısa ömürlü oturumları tercih edin ve CI işlerine yalnızca ihtiyaç duydukları izinleri verin — bir test runner'ında üretim dağıtım anahtarları bulunmamalı.

Etkilendiğinizi düşünüyorsanız

CISA'nın dev.to'da özetlenen tavsiyeleri: lockfile'ları, iç içe bağımlılıklar ve önbelleğe alınmış paketler dahil, yayınlanmış riskli sürüm listeleriyle karşılaştırın; bilinen iyi sürümlere sabitleyin (pin); bir geliştiricinin veya CI makinesinin ifşa etmiş olabileceği her kimlik bilgisini değiştirin (rotate) — GitHub token'ları, npm token'ları, cloud anahtarları ve API anahtarları dahil; GitHub hesaplarını beklenmeyen depo, workflow, uygulama, webhook veya secret'lar açısından inceleyin; ve ağ kayıtlarında bilinmeyen uç noktalara yapılan bağlantıları kontrol edin.

Neden önemli

Bu olaylar, bir şirkette hiç kimse kötü kod yazmadan veya dağıtmadan bir uygulamanın tehlikeye atılabileceğini gösteriyor — bir dizüstü bilgisayarda veya derleme sunucusunda rutin bir install yeterliydi. Saldırganların hedefi kimlik bilgileriydi ve bir geliştirici makinesinden çalınan anahtarlar üretim sunucularını, veritabanlarını ve müşteri verilerini açabilir. Front-end paketleri ziyaretçilerin tarayıcılarında çalışır, dolayısıyla zehirli bir bağımlılık müşterilerinizin makinelerinde çalışan koda dönüşür — chalk saldırısının sömürmeye çalıştığı şey tam olarak buydu. Ve popüler tek bir pakete binlerce kurban aynı anda ulaştığı için tedarik zinciri birincil hedef olmaya devam edecek. Açık kaynak bağımlılıklar hâlâ akılcı bir varsayılan — kimse bir tarih kütüphanesini yeniden yazmamalı — ama sürümleri sabitlemek, yükseltmeleri yavaşlatmak, geliştirici kimlik bilgilerini korumak ve derlemeye girenleri izlemek artık isteğe bağlı ekstralar değil, temel hijyen.