npm Trusted Publishing açığı 1.500'den fazla paketi ele geçirilmeye açık bıraktı

Help Net Security'nin aktardığına göre Bloom Security araştırmacıları, npm'in Trusted Publishing özelliğindeki bir tasarım zayıflığının saldırganlara hiçbir kimlik bilgisi çalmadan başkalarına ait paketlerin yeni sürümlerini yayımlama imkânı verdiğini açıkladı. Bloom, toplam indirme sayısı 10 milyonu, aylık indirmesi 1 milyonu aşan 1.500'den fazla paketin etkilendiğini tespit etti. npm'i işleten GitHub düzeltmeyi 2 Ekim'de duyurdu; ancak değişiklikten önce oluşturulmuş bağlantıların geriye dönük olarak korunup korunmadığı belirsiz.

Neler oldu?

Trusted Publishing, paketlerin uzun ömürlü npm jetonları yerine kısa ömürlü OIDC kimlik bilgileriyle bir CI iş akışından yayımlanmasını sağlıyor. Help Net Security'nin haberine göre npm, her yayımlama yapılandırmasını GitHub'ın depolara ve hesaplara atadığı kalıcı sayısal kimliklere değil, deponun adına ("slug") bağlıyordu ve bu kimlikleri kontrol etmiyordu.

Bir bakımcı bağlı depoyu yeniden adlandırdığında, devrettiğinde ya da sildiğinde veya depo sahibi hesap yeniden adlandırılıp silindiğinde eski ad herkesin kullanımına açılıyordu. Saldırgan bu adı alıp aynı dosya adına sahip bir iş akışı eklediğinde, sahibi olmadığı bir paket için geçerli bir yayımlama kimlik bilgisi elde edebiliyordu.

Bloom, saldırıyı kendi kontrolündeki paket ve depolarla baştan sona test etti. Zararlı sürüm, saldırganın deposunu gösteren geçerli bir köken (provenance) onayı bile taşıyordu; yani imzalı derleme kaydı sorunu ele vermiyordu. Bloom, npm'in GitLab Trusted Publishing entegrasyonunda da aynı zayıflığın bulunduğunu belirtti.

Bildirim süreci

Bloom sorunu 6 Haziran 2026'da GitHub'ın HackerOne üzerindeki hata ödül programına bildirdi; GitHub raporu 9 Haziran'da doğruladı. Bloom'un aktardığına göre GitHub'dan son yanıt 8 Temmuz'da geldi; HackerOne'dan arabuluculuk talebi dahil sonraki altı takip mesajı yanıtsız kaldı. GitHub düzeltmeyi 2 Ekim'de duyurdu.

Düzeltmeyle birlikte doğrulanmamış Trusted Publishing yapılandırmaları oluşturulduktan 48 saat sonra sona eriyor ve artık yayımlama yetkisi vermiyor. Bir GitHub sözcüsü, bunun sahibi değişen bir depo veya proje adına güvenme riskini sınırladığını söyledi. GitHub, sahibi olan hesap yeniden adlandırılmadan veya silinmeden önceki hafta 100'den fazla klonlanan depoların adlarını zaten kullanımdan kaldırıyordu; bu önlem bazı paketleri koruyor ama hepsini değil.

Kimler etkileniyor?

Bloom araştırmacısı Golan Myers, açığın gerçek saldırılarda kullanılıp kullanılmadığının bilinmediğini söyledi. Bloom etkilenen paketlerin adlarını yayımlamıyor; bu nedenle kullanıcılar bağımlılıklarını bir listeyle karşılaştıramıyor. Araştırmacılar tek bir paketin ele geçirilmesinin bile zarar için yeterli olduğunu vurguluyor: postinstall betiği içeren zararlı bir sürüm, onu kuran her makinede otomatik olarak çalışıyor.

Bloom ayrıca yapay zekâ kodlama ajanlarının riski büyüttüğüne dikkat çekti. Şirketin tahminine göre tipik bir uç noktada ajanlar ayda yaklaşık 70, geliştirici makinelerinde ise 350'ye yakın paket kuruyor ve bu kurulumlar çoğu zaman paket ya da bakımcısı incelenmeden yapılıyor.

Ne yapmalı?

• Bakımcılar: npm trust list komutunu çalıştırıp listelenen her deponun hâlâ kendi kontrolünüzdeki bir depoya karşılık geldiğini doğrulayın. Yeniden adlandırılmış veya devredilmiş bir depoyu gösteren bağlantıları silip yeniden oluşturun; bir depoyu silmeden önce bağlantıyı kaldırın.
• Paket kullanıcıları: Bir paketin köken onayının projenin gelmesi gereken depoyu gösterdiğini kontrol edin; nadiren güncellenen paketlerin beklenmedik yeni sürümlerine temkinli yaklaşın.