LiteLLM 1.107.0 Sisteminize Bulaştı mı? Kontrol ve Rotasyon

İlk 30 dakikada yapılacaklar

21 Ekim 2026'da 11:39 ile 14:20 UTC arasında LiteLLM 1.107.0'ı pip ile kurduysanız ya da latest, main-latest veya main-stable etiketli imajı çektiyseniz, arka planı okumadan önce aşağıdaki adımlarla başlayın. Her maddenin ayrıntısı Tespit, Sınırlama ve Anahtar rotasyonu bölümlerinde.

Çok sayıda sanal ortamı ve konteyneri olan ekiplerde bu adımların hepsi yarım saate sığmaz. İlk yarım saatte en azından üretim gateway'leri ve CI runner'ları için süreci başlatın, geliştirici makinelerini hemen arkasından ele alın.

• Etkilenen makineyi veya konteyneri izole edin: dışarıya çıkışı kesin ama silmeyin, loglar ve /tmp içeriği kanıttır.
• site-packages içinde cook.pth ve cook.py, /tmp altında .pc_once_* ve remote_code_loader.lock dosyalarını arayın.
• DNS ve proxy loglarında www.litellm[.]dev alan adını arayın.
• LLM sağlayıcı anahtarlarını, bulut kimlik bilgilerini ve GitHub token'larını temiz bir makineden yenileyin; sürüm yayınlama yetkisi olan token'ları hemen iptal edin.
• Sistemi temiz bir imajdan yeniden kurun.
• LiteLLM'i 1.106.2 sürümüne sabitleyin.

21 Ekim'de tam olarak ne oldu

LiteLLM, BerriAI'nin geliştirdiği ve yüzden fazla LLM sağlayıcısını OpenAI uyumlu tek bir API arkasında toplayan bir Python SDK'sı ve proxy'si. Birçok şirkette uygulamalar OpenAI, Anthropic ya da Azure ile doğrudan değil, bu katman üzerinden konuşuyor. LiteLLM'in resmi olay raporuna göre 21 Ekim sabahı sürüm hattı ele geçirildi ve içinde derlenmiş zararlı yazılım bulunan v1.107.0 hem PyPI üzerinde hem Docker imaj deposunda yayınlandı. Zararlı paket PyPI üzerinde yaklaşık 11:39 ile 13:23 UTC arasında kaldı.

Docker tarafı daha uzun sürdü. Wiz'in analizine göre truva atlı imaj GHCR ve Docker Hub'da v1.107.0, latest, main-latest ve main-stable etiketleri altında duruyordu; Rescana'nın zaman çizelgesi özeti bu etiketlerin 11:46 ile 14:20 UTC arasında zararlı imajı gösterdiğini belirtiyor. Proje, güvenli son sürümün 1.106.2 olduğunu ve özel kurumsal sürümü kullanan müşterilerin etkilenmediğini açıkladı.

Saldırının nasıl mümkün olduğu öğretici. Cycode'un aktardığına göre BerriAI, saldırganın üç mühendise ait çalınmış GitHub CLI OAuth token'larını kullandığını söylüyor: bir hesap sürüm iş akışını tetiklemiş, bir diğeri onaylamış. The Register'ın haberine göre Wiz, yükü gerçek BerriAI organizasyonunu taklit eden, tireli yazılmış Berri-AI hesabındaki commit'lere kadar izlemiş. İki onaylı bir iş akışı, onaylayan hesaplar çalındığında hiçbir şey korumuyor.

Bu, LiteLLM'in 2026'daki ikinci vakası. Projenin GitHub kaydına göre 24 Mart'ta teampcp adlı saldırgan bir bakımcının PyPI hesabını ele geçirip 1.82.7 ve 1.82.8 sürümlerini yayınlamıştı; kayıt bunu daha önceki Trivy ihlaline bağlıyor ve Cycode Şubat sonunda başlayan bir kampanyanın parçası olarak tanımlıyor. OX Security saldırganın bu kez farklı araçlar ve altyapı kullandığını belirtiyor. Bakımcılar Mart'ta hesaplarını yeniledi, yedi ay sonra başka bir yoldan girildi; kontrolü kendi tarafınızda kurmanız gerektiğini söylemek için daha iyi bir örnek bulmak zor.

Zararlı yük ne çaldı ve nereye gönderdi

SafeDep'in incelemesine göre Linux, macOS ve Windows için yayınlanan yedi wheel dosyasının hepsi site-packages içine, GitHub'daki kaynak kodda bulunmayan üç dosya bırakıyor ve bu dosyalar makinede herhangi bir Python süreci başladığında çalışıyor. OX Security'nin de vurguladığı gibi projeniz litellm'i hiç kullanmasa bile, paket ortamda kuruluysa yük devrede.

Bilgi çalan bileşen cook.py; SSH anahtarlarını, bulut kimlik bilgilerini, CI/CD sırlarını, yapay zekâ araçlarının token'larını, tarayıcıda kayıtlı parolaları ve LiteLLM proxy veritabanındaki LLM sağlayıcı anahtarlarını topluyor. Cycode, proxy'nin sağlayıcı anahtarlarını bir Postgres tablosunda tuttuğunu ve zararlının bu tabloyu sorgulayarak 500'e kadar anahtar çektiğini bildiriyor. Bir gateway'in değeri tüm anahtarları tek yerde toplamasıydı; saldırgan da tam olarak buna oynadı.

JFrog Security Research toplanan verinin AES-256-CBC ile şifrelendiğini, anahtarın gömülü bir RSA-4096 açık anahtarıyla sarıldığını ve arşivin düz HTTP üzerinden www.litellm[.]dev/healthcheck adresine gönderildiğini tespit etti. Bu taklit alan adı 13 Ekim 2026'da kaydedilmiş; gerçek proje litellm.ai kullanıyor.

İkinci bileşen daha sinsi. Bu teknik özete göre bırakılan dosyalar cook.pth, cook.py ve sitecustomize.py; sitecustomize.py her saat bir GitHub dosyasından (dead-drop) sunucu adresini okuyan, bilgi çalan bileşeni yeniden çalıştıran ve o sunucudan kod indirip yürüten bir arka plan süreci başlatıyor. Adresi barındıran GitHub hesabı 13:40 UTC'de 404 dönmeye başlamış, ama yükleyiciyi daha önce çalıştıran makineler ikinci aşama kodu almış olabilir.

Kimler risk altında, kimler değil

Asıl sorun, birçok ekibin LiteLLM'i kullandığını bilmemesi. StepSecurity'nin vurguladığı gibi kütüphane geliştirici dizüstülerinde, CI hatlarında ve OpenAI, Anthropic, Azure, Bedrock ve Vertex anahtarlarını tutan üretim gateway'lerinde çalışıyor. Bir ajan çerçevesi, bir değerlendirme aracı ya da bir iç araç onu bağımlılık olarak çekmiş olabilir; kilit dosyasına bakmadan bunu fark etmezsiniz.

En açık risk, bağımlılıklarını sürüm sabitlemeden kuranlarda ve konteynerlerini değişken etiketlerden (latest gibi) çekenlerde. O pencerede bir CI işi çalıştıysa, bir geliştirici sanal ortamını yeniden kurduysa ya da bir Kubernetes pod'u yeniden başlayıp imajı yeniden çektiyse durum ciddi. LiteLLM'in tavsiyesi açık: 1.107.0'ı kuran ya da etkilenen imajı başlatan her sistem ele geçirilmiş kabul edilmeli.

Etkilenmeyenler: 1.106.2 veya öncesine sabitlenmiş ve o pencerede yeniden kurulum yapmamış ortamlar, imajı 1.107.0 öncesine ait bilinen güvenli bir digest ile sabitleyenler ve özel kurumsal sürümü kullananlar. Emin değilseniz kendinizi bu gruba koymayın, önce tespit adımlarını uygulayın.

Tespit

En doğrudan yerel izler site-packages içindeki dosyalar ve /tmp altındaki iki iz dosyası; ağ ve bulut loglarındaki göstergeler de verinin dışarı çıkıp çıkmadığını gösterir. Socket'in önerdiği gibi kapsamı geniş tutun: kurulumdan sonra Python'un çalıştığı her ortam, proxy konteynerleri ve CI runner'ları dahil. Komutlar Linux ve macOS içindir; Windows'ta site-packages kontrolü yine geçerli.

/tmp yeniden başlatma ya da konteyner yenilemesiyle silinebilir, dolayısıyla iz dosyasının olmaması temiz olduğunuzu kanıtlamaz. Bulut tarafındaki STS GetCallerIdentity çağrıları da dikkatle okunmalı: saldırganın kimlik bilgilerini sınadığına işaret ediyor olabilir, ama tek başına kanıt sayılmaz.

• site-packages içinde cook.pth, cook.py ve sitecustomize.py arayın. Dizini `python -c "import site; print(site.getsitepackages())"` ile bulun ve her sanal ortam ile konteyner için tekrarlayın. sitecustomize.py başka araçlarca da kullanılabildiği için içeriğine bakın.
• `ls -la /tmp/.pc_once_* /tmp/remote_code_loader.lock 2>/dev/null` çalıştırın; konteynerlerde aynı komutu `docker exec` ile verin. Aikido'ya göre ilk dosya sızdırmanın tetiklendiğini, ikincisi komuta kontrol sürecinin çalıştığını gösterir.
• `pip show litellm` ile kurulu sürümü kontrol edin; poetry.lock, uv.lock ve requirements dosyalarında 1.107.0'ı arayın. Paketi hangi bağımlılığın çektiğini `pipdeptree -r -p litellm` gösterir.
• Chainguard'ın önerdiği gibi LiteLLM imajlarını `docker images --digests | grep litellm` ile digest değerine göre listeleyip yayınlanan zararlı digest'lerle karşılaştırın.
• DNS ve proxy loglarında www.litellm[.]dev alan adını ve letters9813/pythonclient-test yolunu arayın.
• Kodem Security'nin göstergelerine göre X-Token: XWiA8gZNa7NcX2XRoAEb başlıklı /healthcheck POST isteklerini, eski bir MSIE 7.0 user agent'ını ve kurulum saatine yakın, LiteLLM makinesinin instance rolünden gelen STS GetCallerIdentity çağrılarını arayın.

Sınırlama (containment)

İlk iş izolasyon, ikinci iş kanıtı korumak. Makineyi ağdan ayırın, gerekirse disk ya da konteyner anlık görüntüsü alın, logları silmeyin; hangi anahtarın ne zaman nereye gittiğini ancak bu kayıtlarla yeniden kurabilirsiniz.

Paketi kaldırmak yetmez, sistemi yeniden kurun. Saatlik yükleyici ikinci aşama kod indirmiş olabilir ve pip uninstall bunu temizlemez; temiz bir imajdan yeniden kurmak tek güvenilir yol. Aynı nedenle yeni anahtarları temizlenmemiş bir makinede üretmeyin, aksi halde onları da teslim edersiniz.

• Makineyi izole edin ve logları, /tmp içeriğini koruyun.
• `lsof /tmp/remote_code_loader.lock` ile kilidi tutan bağımsız Python sürecini bulup durdurun.
• www.litellm[.]dev alan adına ve dead-drop adresine giden çıkış trafiğini engelleyin, bu trafiğe ait logları saklayın.
• 1.107.0 içeren dağıtımları durdurun.
• Sistemi temiz bir imajdan yeniden kurun ve LiteLLM'i 1.106.2 sürümüne sabitleyin.

Anahtar rotasyonu: neyi, hangi sırayla

Aciliyetin nedeni tek bir gözlem: Rescana'nın aktardığına göre Wiz, çalınan kimlik bilgilerinin sızdırmadan yaklaşık 4,5 saat sonra kötüye kullanılmaya başlandığını gördü. Rotasyon günlerle değil saatlerle ölçülmeli ve Sınırlama bölümünde anlattığımız gibi temiz bir makineden yapılmalı.

LLM sağlayıcı anahtarlarını başa koyuyoruz, çünkü zararlı proxy veritabanını doğrudan hedefledi ve bu anahtarlar çalındığı anda harcanabilir. Karşı görüş de haklı: sürüm yetkisi olan bir GitHub token'ı ya da geniş yetkili bir bulut rolü, LLM faturasından çok daha büyük hasar yaratabilir. Bu yüzden kapsamda sürüm yayınlama yetkisi olan herhangi bir GitHub token'ı varsa, onu LLM anahtarlarıyla aynı anda iptal edin; ekibiniz yeterliyse üç kalemi paralel yürütün.

Dürüst olmak gerekirse, yüzlerce sağlayıcı anahtarı tutan bir proxy veritabanınız varsa bu iş bir öğleden sonrada bitmez. Hangi anahtarın hangi ekibe ya da müşteriye ait olduğunu bilmiyorsanız rotasyon bir envanter çalışmasına dönüşür; can sıkıcı, ama bir sonraki olayda en çok işinize yarayacak yatırım bu.

• 1. Proxy veritabanındaki tüm LLM sağlayıcı anahtarları: yeni anahtar üretmek eskisini geçersiz kılmaz, eskisini sağlayıcı panelinden iptal edin ve olaydan bu yana kullanım kayıtlarına bakın.
• 2. Bulut kimlik bilgileri ve instance rolleriyle ilişkili erişim anahtarları (AWS, Azure, GCP), oturum token'larının iptali dahil.
• 3. GitHub, GitLab ve CI/CD token'ları; sürüm yayınlama ve onaylama yetkisi olanlar birinci adımla eş zamanlı.
• 4. SSH anahtarları ve ilgili sunuculardaki authorized_keys girdileri.
• 5. Geliştirici makinelerindeki yapay zekâ aracı token'ları ve tarayıcıda kayıtlı parolalar.

Kalıcı önlemler: envanter, sabitleme, sır izolasyonu

İlk adım yapay zekâ bağımlılıklarının envanteri: hangi servis hangi LLM kütüphanesini, hangi gateway'i, hangi sürümle kullanıyor? Her projede bir kilit dosyası ve tercihen bir SBOM bulunmalı. Ardından sabitleme gelir: Python tarafında sürümü ve tercihen hash değerini kilitleyin, konteynerlerde değişken etiketler yerine digest kullanın. Mart vakasında Proxy Docker imajı kullananlar, bağımlılıklar requirements.txt içinde sabitlendiği için etkilenmemişti.

Yeni sürümler için bekleme süresi de işe yarar. Socket paketi yedi dakikada işaretledi ve paket PyPI deposundan yaklaşık iki saatte kalktı; birkaç günlük bir bekleme kuralı bu sürümü ortamınıza ulaşmadan dışarıda bırakırdı. Docker tarafında ise latest gibi bir etiketi çekerken beklemenin pratik bir yolu yok; bekleme süresi orada ancak digest sabitlemeyle birlikte gerçekten işe yarar. Sınırını da bilin: incelemeden geçirmeden onayladığınız zehirli bir sürümü kilit dosyası da korur.

Son katman sırların yerini daraltmak. Bir kütüphane her Python sürecinde çalışıp makinede erişilebilir olan her şeyi toplayabiliyorsa, tarayıcı parolaları, bulut kimlik bilgileri ve LLM anahtarları aynı dizüstüsünde durmamalı. Bu olayda veri düz HTTP ile bir hafta önce kaydedilmiş bir alan adına gitti; yalnızca bilinen sağlayıcı uç noktalarına izin veren bir çıkış kuralı o isteği durdururdu.

Kimin için ağır gelir? Tek anahtarla birkaç dahili prototip çalıştıran küçük bir ekip için ayrı ağ segmentleri ve sır yöneticisi fazla olabilir; o durumda bile anahtarı geliştirici makinesinden çıkarın, harcama limiti koyun ve gateway sürümünü sabitleyin. Müşteri trafiği taşıyan bir üretim gateway'i için aşağıdaki maddeler artık isteğe bağlı değil.

• Gateway için ayrı ortam, en az yetkili servis hesabı ve sağlayıcı uç noktalarıyla sınırlı çıkış trafiği
• Ekip veya proje başına ayrı LLM anahtarı ve harcama limiti
• Sırları .env dosyaları yerine sır yöneticisinden kısa ömürlü olarak çekmek
• CI runner'larında yalnızca o işin ihtiyaç duyduğu sırları tanımlamak
• Sürüm yayınlama yetkisi olan token'ları kısa ömürlü tutmak ve düzenli gözden geçirmek