Axios, npm’de ele geçirilerek uzaktan erişim truva atı dağıttı

• Yaygın olarak kullanılan axios HTTP istemcisinin iki kötü amaçlı sürümü npm’e yayımlandı ve kurulum sırasında uzaktan erişim truva atı (RAT) dağıttı
• Saldırgan, bakımcı hesap kimlik bilgilerinin çalınması yoluyla GitHub Actions’ı atlatıp kötü amaçlı paketi manuel olarak yükledi
• Kötü amaçlı sürümler, sahte bağımlılık plain-crypto-js@4.2.1 içeriyor; bu paket postinstall betiğiyle RAT kuruyor ve izleri siliyor
• RAT, macOS, Windows ve Linux sistemlerinin tümünü enfekte ediyor; C2 sunucusuyla (sfrclak.com:8000) iletişim kurup ek yükler indiriyor
• npm ve GitHub kötü amaçlı sürümleri hızla kaldırdı, ancak tedarik zinciri güvenliğini güçlendirmenin ve kimlik bilgilerini korumanın önemi bir kez daha öne çıktı

---

axios npm tedarik zinciri saldırısına genel bakış

• 31 Mart 2026’da, yaygın kullanılan axios HTTP istemci kütüphanesinin iki kötü amaçlı sürümü (axios@1.14.1, axios@0.30.4) npm’e yayımlandı
• Saldırgan, axios’un ana bakımcısına ait npm kimlik bilgilerini çalarak GitHub Actions CI/CD hattını atladı ve kötü amaçlı paketi manuel olarak yayımladı
• Her iki sürüme de plain-crypto-js@4.2.1 adlı sahte bir bağımlılık eklendi; bu paket postinstall betiği üzerinden uzaktan erişim truva atı (RAT) kuruyor
• RAT, macOS, Windows ve Linux’u hedef alıyor; C2 (Command and Control) sunucusuyla (sfrclak.com:8000) iletişim kurarak ikinci aşama yükü indiriyor
• Kurulumdan sonra kötü amaçlı kodu ve izlerini silip temiz bir package.json ile değiştirerek adli analizle tespitten kaçıyor

Saldırı zaman çizelgesi

• 30 Mart 05:57 UTC: plain-crypto-js@4.2.0 (meşru sürüm) yayımlandı
• 30 Mart 23:59 UTC: plain-crypto-js@4.2.1 (kötü amaçlı sürüm) yayımlandı, postinstall kancası eklendi
• 31 Mart 00:21 UTC: axios@1.14.1 yayımlandı, kötü amaçlı bağımlılık eklendi
• 31 Mart 01:00 UTC: axios@0.30.4 yayımlandı, aynı kötü amaçlı bağımlılık eklendi
• 31 Mart 03:15 UTC: npm iki kötü amaçlı sürümü sildi
• 31 Mart 04:26 UTC: npm, plain-crypto-js paketini güvenlik tutucu stub’ıyla (0.0.1-security.0) değiştirdi

axios hakkında

• axios, JavaScript ekosisteminde en yaygın kullanılan HTTP istemcilerinden biri olup hem Node.js hem de tarayıcı tarafında kullanılıyor
• Haftalık 300 milyondan fazla indirme sayısı nedeniyle, tek bir kötü amaçlı sürüm bile çok geniş çaplı zarara yol açma potansiyeline sahip
• Sıradan geliştiricilerin npm install sırasında kötü amaçlı kodun kurulduğunu fark etmesi zor

Saldırı aşamaları

• 1. aşama — bakımcı hesabının ele geçirilmesi

  • Saldırgan, jasonsaayman npm hesabını ele geçirip e-postayı [e-mail] olarak değiştirdi
  • Ardından hem 1.x hem de 0.x sürüm dallarına kötü amaçlı derlemeleri yayımladı
  • Meşru sürümler GitHub Actions’ın OIDC Trusted Publisher mekanizmasıyla yayımlanırken, axios@1.14.1 manuel yayımlandığı için gitHead ve OIDC imzası içermiyor
  • Saldırganın uzun ömürlü bir npm erişim belirteci kullanmış olduğu tahmin ediliyor

• 2. aşama — kötü amaçlı bağımlılığın önceden dağıtılması

  • plain-crypto-js@4.2.1, [e-mail] hesabından yayımlandı
  • crypto-js paketini taklit ediyor ve aynı açıklama ile depo URL’sini kullanıyor
  • "postinstall": "node setup.js" kancasını içerdiği için kurulum sırasında otomatik çalışıyor
  • Saldırıdan sonra package.md, package.json ile değiştirilerek kanıtları silmeye hazırlık yapılıyor

• 3. aşama — bağımlılığın axios içine enjekte edilmesi

  • plain-crypto-js@^4.2.1, çalışma zamanı bağımlılığı olarak eklendi
  • Kod içinde hiçbir yerde import edilmiyor → hayalet bağımlılık (phantom dependency)
  • npm install sırasında otomatik kurulup postinstall betiğini çalıştırıyor

RAT dropper’ı (setup.js) analizi

• Obfuscation teknikleri

  • Dizeler stq[] dizisinde şifreli tutuluyor ve _trans_1 (XOR) ile _trans_2 (Base64+ters çevirme) kullanılarak çözülüyor
  • C2 URL’si http://sfrclak.com:8000/6202033
  • Çözülen dizelerde OS tanımlayıcıları (win32, darwin), dosya yolları ve kabuk komutları yer alıyor

• Platforma göre yükler

  • macOS

    • AppleScript, /tmp altına yazılıp osascript ile çalıştırılıyor
    • C2’den RAT ikilisi alınıp /Library/Caches/com.apple.act.mond yoluna kaydediliyor ve çalıştırılıyor
    • Dosya adı Apple sistem daemon’u gibi görünmesi için kamufle ediliyor

  • Windows

    • PowerShell yolu bulunup %PROGRAMDATA%\\wt.exe konumuna kopyalanıyor
    • VBScript aracılığıyla C2’den PowerShell RAT indiriliyor ve çalıştırılıyor
    • Geçici dosyalar (.vbs, .ps1) çalıştırıldıktan sonra siliniyor

  • Linux

    • curl ile /tmp/ld.py indiriliyor, ardından nohup python3 ile çalıştırılıyor
    • /tmp/ld.py dosyası sistemde kalıyor
    • Üç platformun tamamı da normal npm trafiği gibi görünmek için packages.npm.org/product0~2 POST gövdelerini kullanıyor

• Kendi kendini silme ve gizlenme

  • setup.js ve package.json siliniyor
  • package.md, package.json ile değiştirilerek meşru paket gibi gösteriliyor
  • Sonrasında npm audit ya da manuel incelemeyle tespit edilemiyor
  • Ancak node_modules/plain-crypto-js/ dizininin varlığı tek başına bulaşma kanıtı

StepSecurity Harden-Runner ile yürütme doğrulaması

• Harden-Runner, GitHub Actions içinde ağ, süreç ve dosya olaylarını gerçek zamanlı olarak kaydediyor
• axios@1.14.1 kurulurken C2’ye iki bağlantı (curl, nohup) tespit edildi
  • İlk bağlantı, npm install başladıktan 2 saniye sonra oluştu
  • İkinci bağlantı ise 36 saniye sonra arka plan süreci olarak kalıcı biçimde çalıştı
• Süreç ağacı analizi, nohup sürecinin PID 1 (init) altında yetim süreç olarak kaldığını ve çalışmaya devam ettiğini doğruladı
• Dosya olay günlüklerinde package.json dosyasının iki kez üzerine yazıldığı görüldü
  • İlkinde: kurulum sırasında kötü amaçlı sürüm yazıldı
  • İkincisinde: 36 saniye sonra temiz bir stub ile değiştirildi

Ele geçirilme göstergeleri (IOC)

• Kötü amaçlı npm paketleri

  • axios@1.14.1 · shasum: 2553649f232204966871cea80a5d0d6adc700ca
  • axios@0.30.4 · shasum: d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71
  • plain-crypto-js@4.2.1 · shasum: 07d889e2dadce6f3910dcbc253317d28ca61c766

• Ağ

  • C2 alan adı: sfrclak.com
  • IP: 142.11.206.73
  • URL: http://sfrclak.com:8000/6202033

• Dosya yolları

  • macOS: /Library/Caches/com.apple.act.mond
  • Windows: %PROGRAMDATA%\\wt.exe
  • Linux: /tmp/ld.py

• Saldırgan hesapları

  • jasonsaayman (ele geçirilmiş bakımcı)
  • nrwise (saldırgan tarafından oluşturulan hesap)

• Güvenli sürüm

  • axios@1.14.0 (meşru)

Etki kontrolü ve müdahale adımları

• npm list axios veya package-lock.json içinde 1.14.1 / 0.30.4 sürümlerini kontrol edin
• node_modules/plain-crypto-js dizininin varlığını kontrol edin
• İşletim sistemine özgü RAT dosyaları mevcutsa sistemin tamamen ele geçirilmiş olduğu varsayılmalı
• CI/CD günlüklerinde ilgili sürümlerin kurulum geçmişi tespit edilirse tüm gizli anahtar ve belirteçlerin değiştirilmesi gerekir

Kurtarma adımları

1. axios’u güvenli sürüme (1.14.0 veya 0.30.3) sabitleyin
2. plain-crypto-js klasörünü silin ve npm install --ignore-scripts ile yeniden kurun
3. RAT izleri bulunursa sistemi yeniden inşa edin
4. Tüm kimlik bilgilerini (AWS, SSH, CI/CD vb.) döndürün
5. CI/CD hattını denetleyin ve gizli anahtarları değiştirin
6. Otomatik derlemelerde --ignore-scripts seçeneğini kullanın
7. C2 alan adını/IP’sini güvenlik duvarı veya /etc/hosts ile engelleyin

StepSecurity Enterprise özellikleri

• Harden-Runner

  • GitHub Actions içinde giden ağ trafiği beyaz listesi uygular
  • Anormal trafiği engeller ve günlükler
  • sfrclak.com:8000 bağlantısını önceden engelleyebilir

• Dev Machine Guard

  • Geliştirici bilgisayarlarında kurulan npm paketlerini gerçek zamanlı izler
  • axios@1.14.1 ve 0.30.4 kurulu cihazları anında tespit eder

• npm Package Cooldown Check

  • Yeni yayımlanan paketlere geçici kurulum engelleme süresi uygular
  • plain-crypto-js@4.2.1 gibi hızla yayılan kötü amaçlı paketleri tespit edebilir

• Compromised Updates Check

  • Gerçek zamanlı kötü amaçlı paket veritabanına dayanarak PR birleştirmelerini engeller
  • axios@1.14.1 ve plain-crypto-js@4.2.1 anında kaydedilir

• Package Search

  • Kurum genelindeki PR’larda ve depolarda belirli bir paketin nerede kullanıldığını arar
  • Etki alanını (repo, ekip, PR) anında ortaya koyar

• AI Package Analyst

  • npm kayıtlarını gerçek zamanlı izler ve davranış tabanlı kötü amaçlı tespit yapar
  • Her iki kötü amaçlı sürümü de yayımlandıktan dakikalar içinde tespit etti

• Threat Center Alert

  • Saldırı özeti, IOC ve müdahale adımlarını içeren tehdit istihbaratı uyarıları sağlar
  • SIEM entegrasyonu ile gerçek zamanlı görünürlük kazandırır

Teşekkür

• axios bakımcıları ve topluluk, GitHub issue #10604 üzerinden hızla yanıt verdi
• GitHub ele geçirilen hesabı askıya aldı, npm ise kötü amaçlı sürümleri sildi ve güvenlik tutucu uyguladı
• Bakımcılar, GitHub ve npm arasındaki koordineli müdahale, dünya çapındaki geliştiricilere verilecek zararı en aza indirdi

[chanapple]

Bu ölçekte bir paketin ele geçirilebileceğini hiç düşünmemiştim; axios gerçekten tahminlerimin ötesinde.

[GN⁺]

Hacker News yorumları

• npm, bun, pnpm ve uv artık paketler için minimum yayın süresi ayarını destekliyor
  Ben ~/.npmrc dosyama ignore-scripts=true eklemiştim; bu ayar tek başına bile açığı hafifletmeye yetebilirdi
  bun ve pnpm varsayılan olarak lifecycle script'lerini çalıştırmıyor
  Her paket yöneticisi için ayar örnekleri şöyle:

  • uv: exclude-newer = "7 days"
  • npm: min-release-age=7
  • pnpm: minimum-release-age=10080
  • bun: minimumReleaseAge = 604800
    İlginç olan, her birinin farklı zaman birimleri kullanması
    LLM ajanları kullanıyorsanız, bu ayar yüzünden hatalar oluşabileceği için AGENTS.md ya da CLAUDE.md içine ilgili talimatları eklemek gerekiyor
  • “Zaman birimleri neden farklı?” yorumuna “JavaScript'i ilk gün mü kullanıyorsun?” diye şaka yapılmış
  • pnpm bu özelliği ilk ekleyen taraf olmuş. npm ise yalnızca 11.10.0 ve sonrasında destekliyor; özellik 11 Şubat 2026 tarihli sürümle gelmiş
  • Ayar dosyalarında birimin açıkça yazılması gerektiğini savunanlar da vardı; örneğin timeout yerine timeoutMinutes gibi
  • npm yorum satırlarını desteklemiyor olabilir. min-release-age=7 # days ayarının gerçekte uygulanmama ihtimali var
  • yarn berry tarafında bu ayar ~/.yarnrc.yml içinde npmMinimalAgeGate: "3d" olarak yapılabiliyor

• Axios'un bir tedarik zinciri saldırısına maruz kalmış olması insanları şaşırttı
  Axios'un kendi içinde kötü amaçlı kod yoktu, ancak plain-crypto-js@4.2.1 adlı sahte bir bağımlılık enjekte edilerek RAT (uzaktan erişim truva atı) kuran bir postinstall script'i çalıştırıldı
  pnpm ya da bun gibi postinstall script'leri için elle onay isteyen kullanıcılar açısından bu iyi haber

  • Node.js'te fetch'in yerleşik gelmesi v18 sonrasında oldu; kararlı hale gelmesi ise v21 ile. Axios ise çok daha eski ve birçok framework ile eğitim içeriğinde yer aldığı için hâlâ yaygın kullanılıyor
  • “pnpm/bun kullanıcıları güvende” sözüne karşılık, “Peki eski sürümlerde bunu önceden onaylamış olma ihtimalleri yüksek değil mi?” sorusu soruldu
  • pnpm'in alt bağımlılıkların postinstall script'lerini de engelleyip engellemediği merak edildi

• Paket yöneticilerinin başarısız bir deney olduğu da öne sürüldü
  SQLite gibi tek bir .c dosyası halinde dağıtılan yüksek kaliteli C kütüphaneleri var; böyle bir yaklaşım transitive dependency sorununu önleyebilir
  Saldırı yüzeyinin büyük kısmı bu dolaylı bağımlılıklardan geliyor

  • Buna karşılık, paket yöneticilerinin artık dil benimsenmesinin vazgeçilmez bir parçası olduğu söylendi. Asıl sorunun kalite denetimi eksikliği ve teşvik yapısı olduğu vurgulandı
    OpenSSL bile kod kalitesi sorunları nedeniyle yeniden yazılıyor; JavaScript tarafında ise standart kütüphaneyi genişletmek zor olduğu için polyfill karmaşası yaşanıyor
  • “Biraz daha fazla emek gerektiren çözümler topluluk tarafından benimsenmez” görüşü de paylaşıldı
    Bunun yerine npm gibi depolarda kalite çıtasının yükseltilmesi ve yalnızca sorumlu bakımcıların kayıt olabilmesi gerektiği önerildi
  • Web geliştirmede saldırı yüzeyi çok daha geniş. Elle kopyalama yöntemi güncellemeleri izlemeyi zorlaştırdığı için paket yöneticilerinin bildirim özellikleri hâlâ faydalı bulunuyor
  • NPM'in özellikle tedarik zinciri saldırılarının ağır yaşandığı bir ekosistem olduğu da belirtildi
  • Rust'ın C'den daha güvenli olduğu ve çoğu crate'in yüksek kaliteli olduğu söylenerek C kütüphaneleri merkezli yaklaşımın abartılı olduğu savunuldu

• Günün “Bugün hangi npm paketi ele geçirildi acaba?” diye başlayan alaycı bir selamla açıldığına dair espriler yapıldı

• Linux kullanıcılarının npm, pip, cargo, gradle gibi tüm build mantığını bwrap ile sandbox içine alması önerildi
  bwrap, Docker benzeri bir izolasyon sağlıyor ama imaj gerektirmiyor. Flatpak da aynı teknoloji temelinde çalışıyor
  Sunucu dağıtımlarında container hardening önemli görülüyor; kritik nokta CI/CD ortamlarını güvenilmeyen alanlar olarak ele almak
  Aynı sandbox yaklaşımının yapay zeka çalıştırırken de kullanılabileceği söylendi

  • Ancak bunun yalnızca postinstall saldırılarına karşı etkili olduğu da belirtildi. Kod içinde sadece require çağrısı bile çalıştırma için yeterli olabilir
  • Docker tabanlı kişisel bir sandbox olan amazing-sandbox'ı geliştiren biri de vardı
  • drop adlı, bwrap'tan daha yüksek seviyeli bir araç da önerildi
  • firejail'in daha esnek bir güvenlik sandbox'ı olduğu görüşü de paylaşıldı
  • SSH socket forwarding'in kişisel anahtarlara erişim sağladığı için gerçek bir güvenlik avantajı sunmadığı, parola korumalı anahtar kullanmanın daha iyi olduğu da söylendi

• Bağımlılık sorunları tekrar tekrar görülünce, Rust ekosisteminin de bir gün benzer şeyler yaşayıp yaşamayacağı konusunda endişe dile getirildi
  Standart kütüphaneyi şişirmek zor olsa da, güvenilir paket kalitesi güvencesi sağlayan bir sisteme ihtiyaç olduğu söylendi

  • Axios gibi büyük paketlerde yayını onaylamak için birden fazla MFA onaylayıcısı gerekmesi önerildi
  • Doğrulanmış bağımlılıkları ticari olarak sunan hizmetlerin ortaya çıkacağı da tahmin edildi
  • Bir başka öneri de bağımlılıkların testlerini doğrudan kopyalayıp kod tabanına almak ve kendi kod inceleme sürecinden geçirmek oldu
    Yapay zeka sayesinde bu ek işin artık yapılabilir olduğu, hatta aslında bunun eskiden beri yapılması gerektiği de dile getirildi

• NPM tedarik zinciri saldırılarına maruz kalmayı azaltmak için öne çıkan temel kurallar

  • Yarn'ın zero-installs modunu kullanmak
  • postinstall script'lerini devre dışı bırakmak veya çalıştırmadan önce kontrol etmek
  • Geliştirme sırasında üçüncü taraf kod çalışacaksa bunu yalnızca VM/container içinde yapmak
  • Paket eklerken popülerliği artı, son commit'leri ise eksi işaret olarak görmek ve kod ile değişiklik geçmişini bizzat incelemek
  • Tüm bağımlılık ağacını doğrulamak ve her yeni geliştirici eklendiğinde güven durumunu yeniden değerlendirmek
  • Sadece lockfile ve --frozen-lockfile seçeneğinin bile yeterli koruma sağladığını düşünenler de vardı
  • “Ben sadece sorunlu stack'lerden uzak duruyorum” diyen, basit ama güçlü bir yaklaşımı benimseyenler de vardı

• “Bu tür saldırılardan tamamen kaçınmak için ne yapmak gerekir?” sorusuna karşılık,
  Qubes OS'ye geçip parola yöneticisi ile build ortamını tamamen ayırmak istediğini söyleyenler oldu

  • Bazı ekipler NPM ile ilgili işleri yalnızca Apple container içinde yapıyor ve Python ile Rust tarafını da aynı modele taşımayı planlıyor
    Bu yaklaşım, tıpkı kimya laboratuvarındaki koruyucu ekipmanlar (PPE) gibi, geliştirme ortamında da izolasyon ve korumaya ihtiyaç olduğunu anlatan bir benzetmeyle açıklandı
    pip de artık virtualenv dışına kurulumları engellemeye başladı; ileride paket yöneticilerinin sandbox dışında çalışmayı reddeden bir seçenek sunması umuluyor
  • Hatta bazıları Node.js/npm'i sistemine hiç kurmadığını söyledi; bugüne kadar gerçekten zorunlu olduğu bir durum görmediğini belirtti

• pnpm ve bun artık varsayılan olarak postinstall script'lerini yok sayıyor, npm ise hâlâ çalıştırıyor
  ~/.npmrc içine ignore-scripts=true eklenmesi öneriliyor
  npm hâlâ haftalık 80 milyon indirme seviyesinde

• Bu olaydaki kimlik bilgisi sızıntısının büyük olasılıkla önceki LiteLLM olayından kaynaklandığı tahmin edildi
  Python ya da Node.js kullanmak tedirgin edici gelse de, bunun aslında genel bir sorun olduğu hissi paylaşıldı

  • Minimum yayın süresi ayarının yardımcı olduğu ama buna rağmen bağımlılık güncellemelerinin hâlâ korkutucu bulunduğu sıkça söylendi
  • Asıl kök nedenin LiteLLM değil, Trivy olayı olduğunu savunanlar da vardı
  • Zarar alanını sınırlamak için rootless geçici container içinde çalıştırma önerisi de yapıldı