Axios, 31 Mart 2026’da npm üzerinde tehlikeye girdi. Laravel ekiplerinin kontrol etmesi gereken noktalar, kimlerin gerçekten risk altında olduğu ve nasıl tepki verilmesi gerektiği buradadır.
Tehlikeye giren bir npm sürümü olan Axios, modern frontend araçları kullanan Laravel uygulamaları için gerçek bir risk oluşturdu. Bu, bir Laravel güvenlik açığı değildi. Bir Composer olayı da değildi. Bu, JavaScript tedarik zinciri sorunuydu ve eğer o ortam 31 Mart 2026’da zehirli paketleri çözümlediyse, yerel makinenizi, CI koşucusunu, önizleme ortamınızı veya dağıtım sürecinizi etkileyebiliyordu.
Şu ana kadar bildirilen etkilenen sürümler [email protected] ve [email protected]‘tür. Bu sürümler, güvenlik yazılarında, kurulum sırasında çalışacak şekilde tasarlanmış ve çoklu platform uzaktan erişim trojanı davranışı sergileyen bir kötü amaçlı bağımlılık olan [email protected]‘i çekmiştir. Bu ayrım önemlidir çünkü bu hikaye paket sürümleri ile ilgilidir, Laravel sürümleri ile değil.
Ne Oldu
Ne Oldu
Socket ve StepSecurity’den gelen ilk olay raporları, kötü amaçlı npm sürümlerini yayımlamak için kullanılan bir Axios bakımcı hesabının tehlikeye girdiğini göstermektedir. Bu sürümler, kurulum sırasında çalışacak şekilde var olan [email protected]‘i tanıtmıştır; bu da, gerçek Axios işlevselliği sağlamak amacıyla değil, kötü niyetli eylemler için tasarlanmıştır.
Kötü sürümler, 31 Mart 2026’da npm üzerinde bildirildi ve daha sonra kaldırıldı. Bu yardımcıdır, ancak gerçek sorunu ortadan kaldırmaz. Eğer bir geliştirici dizüstü bilgisayarı, CI görevi veya Docker yapısı bu sürümleri canlıyken çözümledi ise, risk o ortamda bulunan makinededir.
Hangi Sürümler Etkilendi
Hangi Sürümler Etkilendi
Açık olun: şu ana kadar bildirilen sürümler [email protected], [email protected] ve geçiş bağımlılığı [email protected]‘dir.
Bunlar Axios paket sürümleri, Laravel çerçevesi sürümleri değildir.
Hangi Laravel Uygulamaları Bu Durumdan Etkilenmeli
Hangi Laravel Uygulamaları Bu Durumdan Etkilenmeli
Laravel ekipleri, modern Laravel uygulamalarının genellikle npm saldırı yüzeyine sahip olduğunu bilmelidir. Laravel’in kendi CSRF belgeleri, varsayılan resources/js/bootstrap.js dosyasının Axios’ı içerdiğini ve aynı kökenli taleplerde otomatik olarak X-XSRF-TOKEN başlığını gönderdiğini belirtmektedir. Bu, özellikle ekipler Laravel’in standart frontend iskeletinden başladığında, Axios’ın birçok Laravel projesinde hâlâ normal bir bağımlılık olduğunu gösterir.
En yüksek risk altındaki durumlar, kötü amaçlı sürümler canlıyken yeni bağımlılık çözümleri gerçekleştiren ortamlardır:
- Vite ile bir JavaScript frontend kullanan Laravel uygulamaları, Inertia, Vue ve React kurulumları dahil.
- Varsayılan Axios örneğini koruyan başlangıç-bantı projeleri, aynı kökenli veya Sanctum tarzı AJAX akışları için.
- 31 Mart 2026’da
npm install,pnpm install,yarn installya da benzeri komutları çalıştıran CI boru hatları, geçici önizleme ortamları ve yapı sunucuları. - Görüntü oluşturma sırasında frontend bağımlılıklarını çözümleyen Docker yapıları, bilinen iyi bir lockfile’a güvenmek yerine.
Bağlı ve güvenli sürümlerle sabitlenmiş ekipler çok daha iyi bir durumda. Pratik risk, kurulumların taze, otomatik ve buluşma penceresi sırasında yeni sürümleri çözmesine izin verilen yerlerde en yüksektir.
Bir Laravel Projesini Nasıl Kontrol Edebilirsiniz
Bir Laravel Projesini Nasıl Kontrol Edebilirsiniz
Öncelikle lockfile ile başlayın, tahmin yürütmekle değil. Eğer lockfile’ınız veya kurulu ağaç asla zehirli sürümleri çözümlemediyse, yalnızca bilinen iyi sürümler üzerinde kalındığını doğrulamaktan başka yapacak pek bir şeyiniz olmayabilir.
# npm lock dosyaları
grep -RInE 'axios@1\.14\.1|axios@0\.30\.4|plain-crypto-js' package-lock.json npm-shrinkwrap.json 2>/dev/null
# npm
grep -RInE package-lock.json
# yarn
grep 'axios@|plain-crypto-js' yarn.lock
# pnpm
grep 'axios|plain-crypto-js' pnpm-lock.yaml
# bun
grep 'axios|plain-crypto-js' bun.lock bun.lockb 2>/dev/null
Aranacak tam dizeler şu şekildedir:
Eğer node_modules hâlâ varsa, kurulu ağacı doğrudan inceleyin:
npm ls axios
npm ls plain-crypto-js
find node_modules -name
ls axios ls plain-crypto-js # Bilinen kötü sürümlere daraltın
npm ls axios grep '1\.14\.1|0\.30\.4'
npm --all 2>/dev/null
grep 'axios@1\.14\.1|axios@0\.30\.4|plain-crypto-js|sfrclak\.com'
Eğer Bulursanız Ne Yapmalısınız
Eğer maruz kalmayı doğruladıysanız, bir yükleyici-yolu tehlikesi gibi yanıt verin, sıradan bir bağımlılık güncellemesi gibi değil.
- Etkin makineyi, koşucuyu veya görüntü yapı ortamını potansiyel olarak tehlikeye girmiş olarak değerlendirin.
- Sadece Axios’ı güncellemeyin ve geçmeyin. Bu bağımlılık ağacını düzeltebilir, ancak kurulum sırasında gizli bilgilerinin açığa çıkıp çıkmadığını sorgulamaz.
- O ortamda mevcut olabilecek her şeyi,
.env değerleri, bulut kimlik bilgileri, dağıtım token’ları, npm token’ları, GitHub token’ları, veritabanı kimlik bilgileri ve üçüncü parti API anahtarları dahil olmak üzere, döndürün.
- Bilinen temiz bir ortamdan, sabitlenmiş güvenli sürümlerle ve yenilenmiş bir lockfile ile yeniden oluşturun.
- Son kurulum faaliyetlerini, CI günlüklerini, yapı günlüklerini ve görüntü geçmişini gözden geçirerek bu sürümlerin nerelerde çözümleyebileceğini kontrol edin.
- Eğer güvenlik ekibiniz derinlemesine inceleme yapmak isterse, olay yanıtlayıcılar tarafından yayımlanan mevcut tehlike göstergelerini ve ev sahibi düzeyindeki bulguları gözden geçirin.
Burası birçok ekibin yanlış yaptığı yerdir. Frontend paketinin şimdi güvenli olup olmadığını soruyorlar. Daha zor soru, kurulum işlemini gerçekleştiren makinenin hâlâ güvenilir olup olmadığıdır.
Laravel Ekiplerinin Şimdi Nasıl Güçlendirilmesi Gerektiği
Axios’ı bilinen güvenli bir sürüme sabitleyin, lockfile’ı taahhüt edin ve CI içerisinde bağımlılık ağacını zaten gözden geçirdiğiniz için yapıların taze bir ağacı çözümlemesini önlemek için npm ci‘yi tercih edin. Üretimde paket çözümlemesi yapan her adıma yönelik Dockerfile’ları ve CI iş akışlarını gözden geçirin çünkü üretim dağıtımları, bağımlılık seçimlerini herkese açık kayıt defterine bıraktığınızda kötü bir zamandır.
Ayrıca, CI’niz yoksa bağımlılık izleme veya kötü amaçlı yazılım taraması eklemek için iyi bir zamandır. Sabitlenmiş bağımlılıklar ve taahhüt edilmiş lockfile’lar gösterişli olmayabilir, ancak işte tam da bu yüzden bunlar önemlidir.
Bu Olgunun Laravel İçin Neden Önemli Olduğu
Laravel geliştiricileri, önce Composer riskine odaklanma alışkanlığına sahiptir. Bu anlaşılabilir bir durum, ancak eksiktir. Modern bir Laravel uygulaması genellikle iki tedarik zincirine sahiptir: PHP paketleri ve JavaScript paketleri. JavaScript tarafı tehlikeye girdiğinde, etkisinin genellikle beklenenden daha büyük olduğu görülmektedir çünkü kurulum yolu, bir tarayıcı bu paketi yüklemeden çok önce .env, bulut kimlik bilgileri, dağıtım token’ları, depo token’ları ve yapı önbelleklerine ulaşabilmektedir.
Laravel ekipleri için gerçek tehlike, kurulum işlemini gerçekleştiren makinedir. Bu nedenle gizli erişimleri açık, belirgin ve denetlenebilir tutmak çok önemlidir. Eğer o sınırın mimari versiyonunu istiyorsanız, Ghostable’nın sıfır bilgi güvenlik genel bakışı, yapı sistemleri veya paylaşımlı ortamlar sorunsuz çalışmadığında yerel şifreleme ve şifre çözmenin neden önemli olduğunu açıklar.
Nihai Çıkarım
Eğer Laravel uygulamanız veya boru hattınız [email protected] veya [email protected] sürümünü çözümlediyse, bunu “frontend bağımlılığı kısa bir süre kötüydü” olarak çerçevelendirmeyin. Bunu “bir yapı veya geliştirici ortamı, 31 Mart 2026’da kötü niyetli kurulum zamanı kodunu çalıştırmış olabilir” şeklinde çerçevelendirin.
Bu, ciddiyetin doğru seviyesidir. Bu bir Laravel hatası değildi. Ancak Laravel ekipleri kesinlikle tesir alanındaydı.
Kaynak: Orijinal Makale
