Kötü amaçlı PyPI ve npm paket olayları hash sabitlemeli kurulum ve CLI sandbox çağrılarını yeniden gündeme getirdi

Bu hafta geliştiriciler arasında iki tedarik zinciri olayı dolaşıyor: kurulum sırasında kimlik bilgileri çalan ve arka kapı yerleştiren kötü amaçlı bir LiteLLM paketi (PyPI) ve npm'e yayınlanan truva atlı bir Bitwarden CLI. İki dev.to yazısı ne olduğunu ve ekiplerin bunun hakkında neler yapabileceğini ele alıyor.

Dakikalar süren maruziyet, uzun süren temizlik

Gap Hunter Labs'tan Joel Díaz'ın bir dev.to yazısına göre, Bitwarden CLI'nın kötü amaçlı bir sürümü Nisan 2026'da npm'e ulaştı ve yaklaşık doksan dakika yayında kaldı — onu kuran herkesin SSH anahtarlarını, .env dosyalarını ve AWS, Azure ile GCP kimlik bilgilerini okumaya yetecek kadar zaman. Ekim'de resmi OVHcloud CLI'nın arkasındaki repository aynı şekilde kısa süreliğine ele geçirildi; kötü build 94 dakika sonra engellendi, ama ancak bir müşteri fark ettiğinde. Díaz'ın savunusuyla ikisi de imza tabanlı antivirüs tarafından yakalanmazdı, çünkü bilinen kötü dosyalar değil, saygın araçların zehirli tek bir güncelleme yayınlamasıydı.

İkinci, Vietnamca bir dev.to yazısı ise Hacker News'te fark edilen, kimlik bilgisi çalıcları ve bir arka kapı yükleyen kötü amaçlı bir LiteLLM sürümünü anlatıyor. Yazarın ana noktası: Bir Dockerfile'a pip install -U litellm yazmak veya requirements.txt'yi sabitlememiş bırakmak, bakımcının hesabını ele geçiren herkese dizüstü bilgisayarınızda, CI runner'larınızda ve üretim sunucularınızda kod çalıştırma yetkisi vermek demek.

Kod, import etmeden önce çalışır

PyPI yazısı, birçok geliştiricinin beklediğinden daha erken tetiklenen üç çalıştırma yolunu ayrıntılandırıyor. Kaynak dağıtımındaki (source distribution) bir setup.py, herhangi bir kodu okumadan önce build zamanında çalışır. Site-packages içindeki bir .pth dosyası, Python yorumlayıcısı her başladığında — python -c "print(1)" için bile — import ile başlayan her satırı çalıştırır; yakın dönemin kötü amaçlı yazılımlarının tercih ettiği bir kalıcılık tekniği. Geçişli bağımlılıklar (transitive dependency), hiç doğrudan kurmadığınız bir kütüphanenin bulaşmış bir sürümünü içeri çekebilir.

Bir kez çalışmaya başlayınca payload tipik olarak OPENAI_API_KEY ve AWS_SECRET_ACCESS_KEY gibi ortam değişkenlerini tarar, ~/.aws/credentials, ~/.ssh/ ve ~/.kube/config dosyalarını okur ve HTTPS üzerinden veri sızdırır. CI runner'ları, deploy secret'ları zaten orada durduğu için en zengin hedefler, diye belirtiyor yazı.

Kilitle, hash'le ve bekle

Kötü amaçlı sürümler genellikle birkaç saat ile birkaç gün içinde tespit edilip PyPI'dan çekildiği için, kurbanların çoğu o pencere içinde kurulum yapanlardır. Bu yüzden yazının en ucuz iki savunması katı sabitleme ve bilinçli gecikme: uv pip compile --generate-hashes ile bir lockfile oluşturun, pip install --require-hashes --no-deps ile kurun ve --only-binary=:all: ile kaynak dağıtımları tamamen reddedin; böylece hiçbir setup.py çalışmaz.

Bir bekleme süresi uv'ın --exclude-newer bayrağından gelir; yalnızca bir kesim tarihinden önce yayınlanmış paketleri kabul eder — yazar yedi gün öneriyor, gerekçesi araştırmacıların kötü paketleri genellikle 24 ila 72 saat içinde ortaya çıkarması. CI'a pip-audit eklemek ve bilinen uyarılar durumunda build'leri başarısız kılmak döngüyü kapatır.

Denetle ve izole et

Halihazırda bulaşmış olabilecek makineler için yazı, site-packages içindeki her .pth dosyasını tarayan ve base64, exec, subprocess veya ağ çağrıları içeren import satırlarını işaretleyen bir script paylaşıyor — olağandışı derecede uzun satırlar bulaşmış kabul ediliyor. İzolasyon önerileri assume-breach (ihlal varsayımı) desenini izliyor: secret'ları iş genelindeki ortamlara değil yalnızca deploy adımlarına enjekte edin, uzun ömürlü bulut anahtarlarının yerine kısa ömürlü OIDC token'ları kullanın, build sırasında ağ çıkışını --network=none veya devpi ya da Artifactory gibi dahili bir proxy ile engelleyin ve üretim anahtarlarını proje bazlı direnv kullanarak shell profillerinin dışında tutun. Bakımcılar, diye ekliyor yazı, PyPI Trusted Publishing ve donanım anahtarlı 2FA'yı benimsemeli.

Kötü bir sürüm sızarsa, önerilen sıra şudur: makineyi karantinaya alın, o ortamın dokunduğu her kimlik bilgisini döndürün, virtualenv'i doğrulanmış bir lockfile'dan yeniden oluşturun ve çıkış (egress) loglarını inceleyin — paketi silmek tek başına .pth arka kapısını yerinde bırakır.

Güvenilmeyen CLI'ların etrafında bir çit

Aynı haftada Díaz'ın yazısı soruna diğer taraftan yaklaşıyor: CLI'nın kendisini sandbox'layın. Çalıştırdığınız her komut — bir paket yöneticisi, bir release binary'si, bir takım arkadaşının script'i — sizin kimliğinizle, ev dizininize tam okuma erişimiyle çalışır. Yazarın aracı ghl-jail, yönetici hakları gerektirmeyen yalnızca Windows'ta çalışan bir Python script'i; tek bir komutu yalnızca tek bir proje klasörüne erişimle, başka hiçbir şeye erişim olmadan çalıştırır ve ağ erişimi varsayılan olarak kapalıdır. Díaz sınırlar hakkında açık sözlü: bir hatanın maliyetini ciddi şekilde artırıyor ama o sandbox'ı hedefleyen aktif bir saldırganı durdurmuyor.

Neden önemli

Paket kurulumu, başka bir adla uzaktan kod çalıştırmadır ve itibar tabanlı tarama, meşru bir aracın tek bir zehirli sürüm yayınlayamayacağını varsayamaz. npm olaylarının her biri yaklaşık 90 dakika yaşadı ve yine de kurban buldu. Hash sabitlemeli lockfile'lar, geciktirilmiş güncellemeler, secret izolasyonu ve sandbox'lama, bir şeyin er ya da geç sızacağını varsayan ucuz, katmanlı önlemlerdir — çünkü bu haftanın yeniden gösterdiği gibi, sızıyor.