JavaScript ekosisteminde bazı olaylar bir güvenlik açığından daha fazlasını anlatır. Son Axios vakası da bunlardan biri. Çünkü burada tartıştığımız şey, klasik anlamda bir "bug" ya da uygulama geliştiricisinin yanlış kullandığı bir API değil. Asıl mesele, çok yaygın kullanılan bir paketin resmi dağıtım kanalının kısa süreliğine ele geçirilmiş olması.
Kısacası: Axios'ın belirli npm sürümleri zararlı bir bağımlılıkla yayımlandı ve bu durum, yalnızca projeye axios eklemiş olmayı değil, o zararlı sürümü gerçekten çözümleyip kurmuş olmayı kritik hale getirdi. Bu ayrım önemli. Çünkü bu olay, "uygulamam çalışırken hata alır mıyım?" sorusundan çok, "build pipeline'ım ya da geliştirici makinem risk altında mı?" sorusunu gündeme getiriyor.
Tam olarak ne oldu?
31 Mart 2026'da Axios'ın npm üzerindeki iki sürümünün kötü niyetli şekilde yayımlandığı ortaya çıktı: axios@1.14.1 ve axios@0.30.4. Güvenlik araştırmacılarının yayımladığı analizler, bu sürümlere plain-crypto-js@4.2.1 adlı zararlı bir bağımlılığın eklendiğini gösteriyor. İlk bakışta küçük bir sürüm güncellemesi gibi duran bu yayınlar, gerçekte kurulum sırasında çalışan kötü amaçlı bir zinciri tetikliyordu.
Buradaki kritik nokta şu: saldırganlar Axios kaynak kodunu baştan aşağı değiştirmedi. Daha sinsi bir yol izlediler. Paket manifestine eklenen tek bir bağımlılık üzerinden, npm install sırasında çalışan bir postinstall akışı devreye girdi. Yani risk, uygulamanın Axios'ı runtime'da nasıl kullandığından önce, kurulum anında oluştu.
Bu yüzden bu olayı klasik bir kütüphane açığı gibi okumak hatalı olur. Buradaki problem "Axios ile bir isteği yanlış attığınızda ne olur?" değil; "bağımlılık çözümleme süreciniz, saldırganın zincirine dokundu mu?" sorusudur.
Neden bu kadar ciddiye alınmalı?
Çünkü modern yazılım ekiplerinde tehlike yalnızca production sunucularında ortaya çıkmaz. Geliştirici laptop'ları, CI runner'ları, preview ortamları ve otomatik build süreçleri de en az production kadar kritik. Hatta bazı durumlarda daha da kritik. Çünkü oralarda çoğu zaman:
.envdosyaları bulunur,- cloud erişim anahtarları tanımlıdır,
- deployment token'ları mevcuttur,
- GitHub, npm veya özel registry kimlik bilgileri kullanılmaktadır,
- SSH anahtarları ya da servis hesapları aktif durumdadır.
Bir paket supply-chain saldırısıyla ele geçirildiğinde saldırganın hedefi çoğu zaman uygulamanın içinde oturan iş mantığı değil, o uygulamayı inşa eden ve dağıtan sistemlerdir. Axios vakasının bu kadar yankı uyandırmasının nedeni de tam olarak bu: etki alanı yalnızca bir JavaScript dependency ağacından ibaret değil.
Bu olay bize ne söylüyor?
Açık kaynak ekosisteminde uzun süredir konuşulan ama pratikte yeterince ciddiye alınmayan bir gerçeği yeniden hatırlatıyor: Güven, çoğu zaman kodun kendisinden değil, yayın zincirinden kırılıyor.
Bir takımın "Biz bağımlılıklarımızı güncel tutuyoruz" demesi tek başına iyi bir güvenlik pratiği sayılmaz. Çünkü bazı durumlarda en yeni sürüm, en güvenli sürüm olmayabilir. Hatta tam tersine, riskin bizzat kendisi olabilir.
Bu olaydan çıkarılacak birkaç net ders var:
1) "Minor" ya da "patch" güncelleme otomatik olarak güvenli değildir
Geliştirici refleksi çoğu zaman küçük sürüm geçişlerini zararsız kabul eder. Oysa saldırganlar da tam olarak bu alışkanlığı hedef alır. Büyük ve dikkat çeken kırıcı değişiklikler yerine, sessizce akan sürümlerin arasına karışırlar.
2) Lockfile disiplini hâlâ en temel savunmalardan biri
Birçok ekipte lockfile ya önemsenmiyor ya da CI tarafında tam olarak uygulanmıyor. Oysa deterministic kurulum, özellikle bu tarz saldırılarda etki alanını dramatik biçimde daraltabilir. npm ci gibi daha öngörülebilir kurulum pratikleri burada yalnızca "düzen" değil, doğrudan güvenlik katmanıdır.
3) Yeni yayımlanmış paketlere karşı bekleme süresi mantıklı bir güvenlik önlemidir
Ekosistemde kötü niyetli yayınların önemli bir bölümü, yayımlandıktan kısa süre sonra araştırmacılar tarafından tespit ediliyor. Bu yüzden özellikle kritik bağımlılıklarda "çıkar çıkmaz al" yaklaşımı yerine kısa bir bekleme penceresi tanımlamak, teorik değil pratik bir savunmadır.
4) CI/CD artık doğrudan saldırı yüzeyi
Eskiden güvenlik konuşmaları çoğunlukla uygulama kodu etrafında dönerdi. Bugün ise pipeline'ların kendisi saldırgan için daha değerli olabilir. Çünkü pipeline ele geçirilirse sadece bir uygulama değil, organizasyonun teslimat hattı etkilenir.
Kimler gerçekten risk altında?
Bu sorunun dürüst cevabı şu: Her Axios kullanıcısı değil, ama etkilenen sürümleri çözümleyip kuran ekipler dikkatli olmalı.
Özellikle şu senaryolar daha yüksek risk taşıyor:
- 31 Mart 2026'daki olay penceresinde temiz kurulum yapan CI/CD sistemleri
- lockfile güncellemesiyle birlikte yeni dependency çözümlemesi yapan geliştiriciler
- feature branch veya preview build sırasında
axios@1.14.1ya daaxios@0.30.4çeken projeler plain-crypto-js@4.2.1izine dependency tree'sinde rastlayan ortamlar
Buna karşılık, eski ve sabit lockfile ile çalışan, yeni paket çözümlemesi yapmayan bazı ekipler fiilen etkilenmemiş olabilir. Ama burada güvenli tarafta kalmak gerekir: eğer şüpheli sürüm gerçekten install edildiyse, konu sadece versiyon düşürmekle kapanmaz.
Şimdi ne yapılmalı?
Bu tür bir olayda yapılacak ilk hata, konuyu yalnızca "Axios'ı geri alalım, tamamdır" seviyesinde ele almaktır. Eğer zararlı sürüm bir makinede kurulmuşsa, artık mesele package.json temizliği değil; olay müdahalesidir.
Pratik olarak atılması gereken adımlar şunlar:
1) Hızlı görünürlük sağlayın
Lockfile'larda ve dependency ağaçlarında şu isimleri arayın:
axios@1.14.1axios@0.30.4plain-crypto-js@4.2.1
Yalnızca ana branch'e bakmak yetmez. Açık PR'lar, feature branch'ler, preview deployment'lar ve self-hosted runner'lar da kontrol edilmelidir.
2) Etkilenen makineleri temiz kabul etmeyin
Şüpheli sürüm gerçekten kurulmuşsa, ilgili geliştirici makinesi ya da CI ortamı kompromize olmuş kabul edilmelidir. Burada "umarız bir şey olmamıştır" yaklaşımı doğru değildir.
3) Secret rotasyonu yapın
npm token'ları, GitHub token'ları, bulut erişim anahtarları, deployment secret'ları, SSH anahtarları ve build sırasında erişilebilen diğer tüm kimlik bilgileri gözden geçirilmeli; risk görülenler döndürülmelidir.
4) Güvenli sürüme açık sabitleme yapın
Axios kullanmaya devam etmek sorun değil; sorun belirli zararlı sürümlerdi. Ancak kısa vadede sürüm aralıklarını gevşek bırakmak yerine, bilinen güvenli sürüme açık şekilde pinlemek daha sağlıklı bir yaklaşım olur.
5) Paket alım politikasını yeniden düşünün
Özellikle kritik bağımlılıklar için şu sorular artık standart hale gelmeli:
- Yeni sürümü aynı gün almak zorunda mıyız?
- CI tarafında yeni yayımlanmış paketler için bekleme süresi tanımlayabilir miyiz?
- Dependency değişikliklerinde otomatik güvenlik kontrollerini zorunlu hale getirebilir miyiz?
Daha büyük resim
Axios olayı yalnızca Axios'la ilgili değil. Son bir yıl içinde farklı ekosistemlerde benzer zincir saldırılarının arttığını görüyoruz. Bu da bize şunu söylüyor: açık kaynak kullanımı artık sadece verimlilik meselesi değil; tedarik zinciri yönetimi meselesi.
Günümüzde iyi mühendislik, sadece doğru paketi seçmekten ibaret değil. O paketin nasıl yayımlandığını, ne zaman güncellendiğini, hangi süreçten geçtiğini ve ekosistemdeki davranışını da izlemeyi gerektiriyor.
Bu yüzden modern güvenlik yaklaşımı şu basit cümleye dayanmalı: Kodunuza güvendiğiniz kadar, onu size getiren zincire de güvenebiliyor musunuz?
Axios vakası bu soruyu yeniden, üstelik oldukça sert biçimde önümüze koydu.
Son söz
Bu olayın en öğretici yanı şu: bazen en büyük risk, kodun içinde değil; kodun size ulaşma yolunda saklıdır.
Eğer ekibiniz JavaScript, Node.js ya da frontend/backend servisleri geliştiriyorsa, bu tür olayları "güvenlik ekibi ilgilensin" diye kenara koymak artık gerçekçi değil. Supply-chain güvenliği, doğrudan ürün geliştirme disiplininin bir parçası haline geldi.
Bugün Axios, yarın başka bir paket. Değişmeyen şey ise şu: hızlı teslimat ile güvenli teslimat arasında yeni bir denge kurmak zorundayız.
Kaynaklar
- Axios GitHub issue:
axios@1.14.1veaxios@0.30.4compromise bildirimi - StepSecurity teknik analizi
- Snyk analizi ve remediation notları
- Socket araştırması
