npm Güven Açığı: 1.500'den Fazla Paket Ele Geçirilmeye Açıktı

GitHub, npm ekosisteminde keşfedilen ciddi bir güvenlik açığına karşı önlem aldı. Artık doğrulanmamış npm güvenilir yayıncı yapılandırmaları, oluşturulmalarından itibaren 48 saat içinde kullanılmazsa otomatik olarak geçersiz sayılacak. Microsoft'a bağlı platform, bu değişikliği sahipliği el değiştiren depo veya proje isimlerine duyulan güvenden kaynaklanan riski sınırlamak amacıyla hayata geçirdi.
Açığı tespit eden Bloom Security şirketi, saldırganların herhangi bir kimlik bilgisi çalmadan başka bir kullanıcıya ait paketin yeni sürümlerini yayınlayabildiğini ortaya koydu. Bulgular 6 Haziran 2026'da GitHub'a iletildi.

SlugFest Saldırısı Nasıl Çalışıyordu?​

Güvenlik araştırmacısı Golan Myers'ın "SlugFest" olarak adlandırdığı bu saldırı vektörü, npm'in güvenilir yayıncı mimarisindeki yapısal bir zayıflıktan besleniyordu. Temmuz 2025'te npm'e eklenen güvenilir yayıncı özelliği, geliştiricilerin GitHub Actions gibi CI/CD platformlarından OpenID Connect (OIDC) token'ları aracılığıyla kimlik bilgisi saklamak zorunda kalmadan paket yayınlamasına imkân tanıyan bir sistem olarak tasarlanmıştı. Ancak bu sistem, depoyu kalıcı sayısal kimliğiyle değil, "sahip/depo" biçimindeki okunabilir adresiyle, yani slug'ıyla tanımlıyordu.
Sorun tam da burada başlıyordu. GitHub, OIDC token'larına deponun kalıcı sayısal kimliğini eklese de npm bu kimliği ilk başarılı yayın gerçekleşene kadar tamamen görmezden geliyordu. Dolayısıyla güven, değişmez bir kimliğe değil, bir isme bağlıydı. Myers bunu şu sözlerle özetledi: "Bu, evin sahibini değil kapının adresini kontrol eden bir kilit gibi; sahibi taşınınca içeri giren herkes anahtarı alıyor."
Saldırı için tek ön koşul, kurbanın güvenilir yayıncı yapılandırmasının bir saldırganın ele geçirebileceği bir slug'a işaret etmesi ve o depodan daha önce hiç paket yayınlanmamış olmasıydı. Bir bakımcı deposunu yeniden adlandırdığında, başka bir hesaba devrettiğinde ya da sildiğinde, boşalan slug'ı ele geçiren saldırgan şu adımları izleyebiliyordu: Boşalan slug'da yeni bir depo oluşturmak, bir npm yayın iş akışı tetiklemek, üretilen OIDC token'ını npm'e göndermek ve npm'in slug eşleşmesini onaylayarak yayın kimlik bilgisi vermesiyle birlikte kurbana ait pakete kötü amaçlı değişiklikler göndermek. Bu sayede saldırgan, paketin mevcut itibarını, indirme sayısını ve bağımlılık ilişkilerini de miras alıyordu.

1.500'den Fazla Paket Risk Altındaydı​

Bloom Security'nin araştırması, bu yöntemle ele geçirilmeye açık 1.500'den fazla paket tespit etti. Söz konusu paketlerin toplamda 10 milyondan fazla kez indirildiği belirlendi. Açık, tedarik zinciri saldırılarına kapı aralıyor; üstelik yapay zeka ajanlarının yaygınlaşmasıyla bu risk daha da büyüyordu. Bloom Security'nin aktardığına göre ajanlar bağımlılıkları kendi başlarına çözümlüyor, genellikle en güncel sürümü tercih ediyor ve paketin nereden geldiğini nadiren denetliyordu. Bu durum, kötü amaçlı bir sürümün insan müdahalesi olmaksızın otomatik olarak çekilip çalıştırılmasına zemin hazırlıyordu.
Myers, saldırının ne içeriden bilgi ne kimlik bilgisi hırsızlığı ne de bir yarış koşulu gerektirdiğini vurguladı. "Tek ön koşul slug'ın müsait olması; bu da tamamen kurbanın kendi depo düzenine bağlı" diye ekledi.

GitHub'ın Aldığı Önlemler​

GitHub, açığı kapatmak için birkaç adım attı. Bunların başında doğrulanmamış güvenilir yayıncı yapılandırmalarının 48 saatlik süre dolunca otomatik geçersiz sayılması geliyor. Bir yapılandırma, ilk başarılı yayın tamamlandığında doğrulanmış sayılıyor ve bu süre sınırından muaf tutuluyor; böylece yapılandırma deponun değişmez kimliğine bağlanmış oluyor. GitHub'a göre depo ya da proje kimliğinin değiştirilmesi yeni bir güven ilişkisi ve yeni bir 48 saatlik doğrulama penceresi gerektiriyor; sıradan düzenlemeler bu süreyi yeniden başlatmıyor.
Bunun yanı sıra npm, artık GitHub Actions'taki issue_comment olaylarından gelen güvenilir yayıncı token'larını da reddediyor. Bu kısıtlama, daha önce uygulamaya konan pull_request_target sınırlamasına ek olarak devreye alındı.

Geliştiricilere Yönelik Uyarılar​

Bloom Security, npm paketi yöneten geliştiricilere şu adımları uygulamalarını tavsiye etti: Güvenilir yayıncı bağlamalarını denetleyerek listelenen slug'ın hâlâ kendi kontrollerindeki depoya işaret edip etmediğini doğrulamak; depo yeniden adlandırılmış ya da devredilmişse mevcut güven bağlamasını silip güncel slug'a yönelik yeni bir bağlama oluşturmak; beklenmedik npm yayın olaylarını izlemek ve bir depo silindiğinde, devredildiğinde ya da yeniden adlandırıldığında güven bağlamalarını derhal kaldırmak.
Myers, araştırmanın temel dersini şöyle özetledi: "Güvenlik topluluğunun tedarik zinciri saldırılarında defalarca gördüğü şeyi bu araştırma bir kez daha kanıtlıyor: İnsan tarafından okunabilir bir tanımlayıcı ile o tanımlayıcının işaret ettiği şey arasındaki bağ, her güven sisteminin en kritik değişmezi. Bu bağ sessizce değiştirilebildiğinde, güven garantisi çöküyor."
Bu, Bloom Security'nin son dönemde ortaya koyduğu tek tedarik zinciri açığı da değil. Ağustos ayında aynı araştırmacılar, Open VSX ve Microsoft'un VS Code Marketplace'inin uzantı paketlerinin var olmayan uzantılara başvurmasına izin verdiğini keşfetti. "Uzantı Dirilişi" olarak adlandırılan bu teknikle Open VSX'te 87, VS Code Marketplace'te ise 677 paketin savunmasız olduğu belirlendi.

Sıkça Sorulan Sorular​

SlugFest saldırısı nedir ve npm paketlerini nasıl tehdit ediyordu?​

SlugFest, Bloom Security'nin keşfettiği bir saldırı yöntemidir. npm'in güvenilir yayıncı sistemi, depoları kalıcı sayısal kimlik yerine okunabilir adresle (slug) tanımlıyordu. Bir saldırgan, bakımcının yeniden adlandırdığı veya sildiği bir deponun slug'ını ele geçirerek kimlik bilgisi çalmadan o depoya bağlı npm paketine kötü amaçlı kod yayınlayabiliyordu.

GitHub bu açığı kapatmak için ne yaptı?​

GitHub, doğrulanmamış güvenilir yayıncı yapılandırmalarını oluşturulmalarından 48 saat sonra otomatik olarak geçersiz sayacak şekilde sistemi güncelledi. İlk başarılı yayın tamamlandığında yapılandırma doğrulanmış sayılıyor ve bu süre sınırından muaf tutuluyor. Ayrıca npm, GitHub Actions'taki issue_comment olaylarından gelen token'ları artık reddediyor.

Kaç npm paketi bu açıktan etkilenebilirdi?​

Bloom Security'nin araştırmasına göre 1.500'den fazla paket bu saldırıya açık durumdaydı. Bu paketler toplamda 10 milyondan fazla kez indirilmişti.

Yapay zeka ajanları bu güvenlik açığını neden daha tehlikeli hale getiriyor?​

Bloom Security'ye göre yapay zeka ajanları bağımlılıkları kendi başlarına çözümlüyor, genellikle en güncel sürümü tercih ediyor ve paketin kaynağını nadiren denetliyor. Bu durum, kötü amaçlı bir sürümün herhangi bir insan müdahalesi olmaksızın otomatik olarak çekilip çalıştırılmasına yol açabiliyor.

npm paketi yöneten geliştiriciler bu riske karşı ne yapmalı?​

Bloom Security'nin tavsiyesine göre geliştiriciler güvenilir yayıncı bağlamalarını denetleyerek slug'ların hâlâ kendi kontrollerindeki depolara işaret ettiğini doğrulamalı; depo yeniden adlandırılmış ya da devredilmişse eski bağlamayı silip yeni bir tane oluşturmalı; beklenmedik yayın olaylarını izlemeli ve bir depoyu sildiklerinde, devrettiklerinde ya da yeniden adlandırdıklarında ilgili güven bağlamalarını derhal kaldırmalıdır.