LiteLLM Tedarik Zinciri Saldırısı: Yapay Zekâ Araçlarında Bağımlılık Güvenliği ve İşletmeler İçin Dersler
Popüler yapay zekâ ağ geçidi LiteLLM'in kötü amaçlı bir sürümü 21 Ekim'de yaklaşık iki saat boyunca PyPI ve Docker imajlarında yayında kaldı. Olayın ayrıntılarını, etkilenenlerin atması gereken adımları ve işletmelerin bağımlılık güvenliği için kurması gereken düzeni anlatıyoruz.
Kısaca: 21 Ekim 2026'da yapay zekâ modellerine tek noktadan erişim sağlayan açık kaynak proje LiteLLM'in kötü amaçlı bir sürümü (1.107.0), PyPI'de ve resmî Docker imajlarında yaklaşık iki saat yayında kaldı. Güvenlik şirketi Datadog'un analizine göre sürüm, Python her başladığında çalışan bir kimlik bilgisi hırsızı ve ikinci aşamada uzaktan kod çalıştırabilen bir arka kapı içeriyordu. Hedef: bulut, geliştirici, yapay zekâ aracı ve tarayıcı kimlik bilgileri. Saldırganlar, üç mühendisin çalınmış GitHub CLI OAuth token'larıyla sürüm sürecini tetiklemiş; token'ların ilk nasıl çalındığı yazı hazırlandığında belirsizdi. Etkilenmiş olabileceğinizi düşünüyorsanız sırları temiz bir makineden yenilemeniz gerekir. Bu olay, işletmeler için daha geniş bir dersi gösteriyor: kullandığınız yazılımın bağımlılıkları da sizin güvenlik yüzeyinizdir. Bilgiler 23 Ekim 2026 itibarıyla Datadog Security Labs analizine dayanır.
Son güncelleme: 23 Ekim 2026
LiteLLM nedir, neden önemli?
LiteLLM, uygulamaların farklı yapay zekâ sağlayıcılarının modellerine tek bir arayüzle bağlanmasını sağlayan açık kaynak bir proje; hem Python kütüphanesi hem de proxy sunucusu olarak kullanılıyor. Bu tür bileşenler genellikle birden çok sağlayıcının API anahtarını tutar. Bu yüzden ele geçirilmeleri, saldırgana tek hamlede çok sayıda kapı açabilir.
Ne oldu? (Datadog'un anlatımıyla)
| Ayrıntı | Bilgi |
|---|---|
| Tarih | 21 Ekim 2026; kötü amaçlı sürüm 11:39 UTC'de yayınlandı, 13:20 UTC'de karantinaya alındı |
| Sürüm | litellm 1.107.0 (PyPI ve Docker etiketleri v1.107.0, latest, main-latest, main-stable) |
| Süre | Yaklaşık iki saat |
| Kötü amaçlı yük | Python başlar başlamaz çalışan kimlik bilgisi hırsızı (LiteLLM'i hiç içe aktarmasanız bile); bulut, geliştirici, yapay zekâ aracı, tarayıcı ve LiteLLM proxy kimlik bilgilerini litellm[.]dev adlı benzer görünen alan adına gönderiyor |
| Arka kapı | GitHub'daki saatlik bir “dead-drop” dosyasını kontrol edip oradan alınan alan adından kod çalıştırıyor; yalnızca test değerleri gözlendi, ikinci aşama yük görülmedi |
| Saldırı yolu | Çalınmış GitHub CLI OAuth token'larıyla, resmî depoya bir tire farkıyla benzeyen sahte bir çatalda (Berri-AI/litellm; gerçeği BerriAI/litellm) sürüm iş akışı çalıştırıldı. Token'ların ilk nasıl çalındığı bilinmiyor |
Datadog, aynı yıl içinde daha önce yaşanmış ayrı bir LiteLLM olayından (1.82.7 ve 1.82.8 sürümleri) söz ediyor; iki olay arasında yazı hazırlanırken kanıtlanmış bir bağlantı yok.
Etkilenmiş olabilir misiniz?
Aşağıdakilerden biri geçerliyse kontrol edin:
- 21 Ekim'de iki saatlik pencerede LiteLLM'i PyPI'den kurdunuz/güncellediniz veya
latest/main-latest/main-stableDocker etiketlerini çektiniz. - Yapay zekâ ağ geçidi, ajans veya geliştirme ortamınızda sürüm sabitlemesi (pinning) olmadan otomatik güncelleme var.
- CI/CD hatlarınız
litellm'i her derlemede sıfırdan kuruyor.
Emin değilseniz yazılım ekibinizden/ajansınızdan hangi sürümün, ne zaman kurulduğunu öğrenin.
Etkilendiyseniz: Datadog'un önerdiği adımlar
site-packagesiçindencook.pth,cook.pyvesitecustomize.pydosyalarını elle silin; paketi kaldırmak bunları silmez.litellm1.107.0 ile ilişkili tüm kod ve veriyi kaldırın.- 1.106.2 sürümüne (Datadog'a göre son güvenli sürüm) dönün.
- Temiz bir makineden potansiyel olarak etkilenmiş tüm kimlik bilgilerini yenileyin: LLM API anahtarları, bulut ve SSH anahtarları,
.enviçindeki sırlar, GitHub token'ları. - Açıkta kalma penceresinde bu kimlik bilgilerinin kullanılıp kullanılmadığını günlüklerden denetleyin.
Aynı gün gelen diğer haber: eMudhra
TechCrunch'ın aktardığına göre aynı günlerde eMudhra adlı Hintli bir sertifika otoritesinin özel anahtarları ele geçirildi; bu, saldırganların sahte sertifikalar üretip meşru sitelere öykünmesine yol açabilecek bir durum. Node.js'in güvenlik sürümü, bu nedenle CA sertifika deposunu da güncelledi. Pratik sonuç: çalışma zamanlarınızı ve işletim sistemi sertifika depolarınızı güncel tutun.
İşletmeler için 8 maddelik bağımlılık güvenliği düzeni
Bu olay yapay zekâ projelerine özgü değil; her yazılım projesi onlarca-yüzlerce açık kaynak bileşene dayanır. Yazılım ekibinizden şu düzeni talep edin:
- Sürüm sabitleme: Üretimde “en son sürüm”e otomatik güncelleme yerine, belirli ve test edilmiş sürümler (kilit dosyaları, imaj özetleri/digest).
- Yeni sürümlere bekleme süresi: Yeni yayınlanan bir paketi hemen kullanmayın; kısa bir bekleme süresi, olayların fark edilmesine zaman tanır.
- Bağımlılık envanteri (SBOM) ve tarama: Hangi bileşenin nerede kullanıldığını bilin; zafiyet ve kötü amaçlı paket taraması yapın.
- Sırların ayrılması: API anahtarlarını kodda/
.envdosyalarında dağınık tutmak yerine, kapsamı sınırlı ve kolayca yenilenebilir biçimde yönetin; geliştirici makinelerindeki uzun ömürlü token'ları azaltın. - En az yetki: Her anahtara yalnızca gereken yetkiyi verin; harcama limitleri koyun.
- Sürüm ve yayın sürecini koruma: Yayın iş akışlarını çok faktörlü doğrulama, kısa ömürlü token'lar ve inceleme zorunluluğuyla koruyun.
- Olay planı: “Bir bileşen ele geçirilirse hangi sırları, kim, ne kadar sürede yeniler?” sorusunun yazılı cevabı olsun.
- Yapay zekâ araçlarını da kapsama alın: Kod asistanları, ajanlar, ağ geçitleri de bağımlılıktır; bkz. yapay zekâ kullanım politikası rehberimiz ve yapay zekâ destekli geliştirme yazımız.
Genel güvenlik çerçevesi için web uygulaması güvenliği rehberimize bakabilirsiniz.
Aktaş Digital ile yapay zekâ projelerinde güvenlik
Yapay zekâ sohbet botu, doküman analizi ve otomasyon projelerinde API anahtarlarının yönetimi, bileşen seçimi ve bakım planı projenin en baştan ele alınması gereken başlıklar. Mevcut bir yapay zekâ entegrasyonunuzun güvenlik ve bağımlılık durumunu konuşmak isterseniz teklif formumuzu kullanabilirsiniz. İlgili hizmetlerimiz: yapay zekâ çözümleri.
Sık Sorulan Sorular
LiteLLM kullanmıyoruz; bu bizi ilgilendirir mi?
Doğrudan etkilenmezsiniz; ancak bağımlılıklarınızda benzer bir olay yaşanabilir. Bu yüzden yukarıdaki düzen (sürüm sabitleme, envanter, sır yönetimi) her proje için geçerlidir.
Paketi kaldırmak yeterli mi?
Datadog'a göre hayır: kötü amaçlı sürüm site-packages içine ek dosyalar bırakıyor ve bunların elle silinmesi gerekiyor. Ayrıca sırların yenilenmesi gerekir.
Hangi sürüm güvenli?
Datadog, 1.106.2'yi son güvenli sürüm olarak belirtiyor. Güncel durumu LiteLLM'in kendi güvenlik duyurusundan doğrulayın.
Yapay zekâ API anahtarlarım çalındıysa ne olur?
Saldırgan anahtarlarınızla yapay zekâ servislerini kullanıp faturanızı şişirebilir veya veri erişimi sağlayabilir. Anahtarları yenileyin, kullanım günlüklerini ve fatura hareketlerini inceleyin, harcama limitleri tanımlayın.
Sonuç
LiteLLM olayı, bir yazılım projesinin güvenliğinin yalnızca kendi kodunuza değil kullandığınız her pakete bağlı olduğunu gösteriyor. Bugün yapabileceğiniz ilk iş: yazılım ekibinizden, yapay zekâ ve diğer kritik bileşenlerin hangi sürümlerde sabitlendiğini ve olay halinde hangi sırların nasıl yenileneceğini yazılı olarak öğrenmek.
