LiteLLM 1.82.7 ve 1.82.8 PyPI paketlerinin ele geçirilmesi olayı

 (github.com/BerriAI)
2 puan yazan GN⁺ 2026-03-25 | 1 yorum | WhatsApp'ta paylaş
  • Yaygın kullanılan LLM entegrasyon kütüphanesi LiteLLM'in iki PyPI paket sürümüne (1.82.7, 1.82.8) zararlı yük eklendi ve dağıtıldı; kurulum sırasında sistem kimlik bilgilerinin çalınmasına yol açan bir saldırı gerçekleşti
  • Saldırının nedeni, CI/CD güvenlik tarama aracı Trivy'nin tedarik zinciri ihlalinden kaynaklandı; CircleCI kimlik bilgileri sızdırıldı ve bunun sonucunda PyPI yayınlama token'ı ile GitHub PAT ele geçirildi
  • Resmî LiteLLM Proxy Docker imajı kullanıcıları requirements.txt içinde sürüm sabitlemesi olduğu için etkilenmedi; ancak PyPI üzerinden doğrudan pip install yapılan ortamların derhal kontrol edilmesi gerekiyor
  • GitHub issue başlığında yüzlerce bot spam yorumu gerçek tartışmayı engelledi; bunun saldırganın müdahale iletişimini kasıtlı olarak bozma girişimi olduğu doğrulandı
  • DSPy, CrewAI gibi LiteLLM'i bağımlılık olarak kullanan çok sayıda projeye de etkisi yayıldı; bu durum yazılım tedarik zinciri güvenliğinin temel kırılganlığını bir kez daha öne çıkardı

Olayın özeti ve nasıl fark edildiği

  • Yeni bir proje kurulumu sırasında sistem anormal davranmaya başladı, RAM tükendi ve fork bomb benzeri süreçler çalıştı
  • İnceleme sonucunda proxy_server.py dosyasına base64 ile kodlanmış zararlı bir blob eklendiği ve bunun çözümlenip ayrı bir dosya oluşturulduktan sonra çalıştırıldığı görüldü
  • 1.82.7 sürümünde yük, litellm/proxy/proxy_server.py içine eklenmişti ve import litellm.proxy sırasında çalışıyordu
  • 1.82.8 sürümü ayrıca litellm_init.pth dosyasını içeriyordu; böylece paket yalnızca kurulu olduğunda bile Python başlatılırken zararlı kod otomatik çalışıyordu
    • .pth dosyaları, Python site modülünün başlangıçta otomatik çalıştırdığı bir mekanizmadır ve import anahtar sözcüğünden sonra keyfi kod çalıştırabilir
    • Bu mekanizma Python 2.1'den beri var ve ayrı bir PEP olmadan eklenmiş
  • İlk mağduriyet raporu FutureSearch ekibinden geldi: uvx, en yeni litellm sürümünü otomatik kurdu (sürüm sabitlenmemişti), ardından Cursor yerel MCP sunucusunu otomatik yükleyince bulaşma gerçekleşti

Saldırı zinciri ve TeamPCP bağlantısı

  • Saldırının, kısa süre önce Trivy'yi ihlal eden TeamPCP grubuyla aynı aktör tarafından yapıldığı doğrulandı
  • İhlal zinciri: Trivy'nin hacklenmesi → CircleCI kimlik bilgilerinin tamamının sızması → PyPI yayınlama token'ı + GitHub PAT ele geçirilmesi → zararlı paketin dağıtılması
  • LiteLLM CEO/CTO'sunun GitHub hesapları da tamamen ele geçirildi; kişisel depo açıklamalarının tamamı "teampcp owns BerriAI" olarak değiştirildi ve issue'lar kapatıldı
  • PYPI_PUBLISH token'ı GitHub projesinin ortam değişkeni olarak saklanıyordu ve bu bilgi Trivy üzerinden sızdı
    • Hesapta 2FA etkin olmasına rağmen token'ın kendisi çalındığı için bu koruma aşıldı
  • Saldırgan, GitHub issue'larında yüzlerce bot hesap üzerinden aynı ifadeleri tekrar tekrar paylaşarak gerçek tartışmayı engelledi
    • Trivy deposunda da aynı örüntüyle 700'den fazla spam yorum tespit edildi
    • Bu spam hesaplardan bazıları, gerçekten katkı geçmişi olan GitHub kullanıcılarıydı; şubat ayından beri "Update workflow configuration" commit'leriyle CI iş akışına kimlik bilgisi hırsızı ekledikleri görüldü
  • Trivy ihlalinin en az 5 gün önce gerçekleştiği, son saldırı duyurusunun ise bir gün önce geldiği belirtiliyor; bu nedenle maintainer'lar durumun farkında olmadan etkilenmiş olabilir
  • Saldırganlar, yük iletimi için Internet Computer Protocol (ICP) Canisters da kullandı; bu yüzden yalnızca DNS engellemesiyle savunma mümkün değil

Zararlı yükün çalışma şekli

  • Arka planda bir Python süreci oluşturuyor ve gömülü aşamayı çözüp çalıştırıyor
  • Kimlik bilgisi toplayıcı çalışıyor; veri toplama başarılı olursa AES anahtarını saldırganın RSA açık anahtarıyla şifreliyor ve çalınan veriyi uzak bir ana makineye gönderiyor
  • Zararlı kodda bulunan URL'ler: checkmarx.zone/raw ve models.litellm.cloud
  • Özellikle ~/.git-credentials içeriği, SSH anahtarları ve kripto cüzdan bilgileri hedef alınıyor
  • CPU yoğun işlemler nedeniyle sistem aşırı yüklendiğinden, durumun fark edilmesi aslında kolaylaştı; fan sesindeki anormallikle şüphelenen örnekler de raporlandı
  • Harbor kurulumu sırasında da aynı belirtiler görüldü: grep -r rpcuser\rpcpassword süreci fork bomb benzeri şekilde çalışarak kripto cüzdanı aramaya çalıştı

LiteLLM ekibinin müdahalesi

  • Etkilenen sürümler (v1.82.7, v1.82.8) PyPI'dan kaldırıldı
  • Tüm maintainer hesaplarının şifreleri değiştirildi, GitHub/Docker/CircleCI/pip üzerindeki tüm anahtarlar silinip yenilendi
  • Yeni maintainer hesapları @krrish-berri-2 ve @ishaan-berri olarak değiştirildi
  • Tüm paket PyPI üzerinde geçici olarak karantinaya alındı, ardından enfekte sürümler kaldırılınca kısıtlama kaldırıldı
  • Tüm yeni sürümler durduruldu ve tedarik zincirinin tamamı incelenene kadar yayınlar donduruldu
  • Google'ın Mandiant güvenlik ekibiyle birlikte inceleme ve toparlanma çalışmaları yürütülüyor
  • Trivy, son güvenli sürüm olan v0.35.0'a sabitlendi (ilk başta v0.69.3'e sabitlenmişti, sonra topluluk geri bildirimiyle değiştirildi)
  • Gelecekte Trusted Publishing (JWT tabanlı OIDC) geçişi ve ayrı PyPI hesabı kullanımı gibi güvenlik güçlendirmeleri değerlendiriliyor
  • Zararlı sürümlerin ilk yayın zamanı yaklaşık UTC 8:30, PyPI karantinaya alma zamanı ise yaklaşık UTC 11:25

Etki alanı ve aşağı akış projeler

  • LiteLLM, DSPy için tek LLM provider çağrı kütüphanesi ve CrewAI tarafından da yedek seçenek olarak kullanılıyor
  • Airflow, Dagster, Unsloth.ai, Polar, nanobot gibi projeler de LiteLLM'e bağımlı
  • GitHub aramasına göre requirements.txt içinde LiteLLM'i sürüm sabitlemeden kullanan 628'den fazla proje bulundu
  • Resmî Proxy Docker dağıtım yolunu kullananlar requirements.txt içinde sürüm sabitlemesi yaptığı için etkilenmedi
  • Docker dağıtımında ana makine dosya sistemi ve ortam değişkenlerine erişim daha kısıtlı olduğu için görece daha güvenli; ancak bağlanmış kimlik bilgileri yine de risk altında
    • Saldırganın ana hedefi kişisel SSH anahtarları; LLM anahtarlarına erişim ikincil önemde
  • Harbor, browser-use gibi LiteLLM'i bağımlılık olarak otomatik kuran araçların kullanıcılarında da dolaylı etkiler raporlandı
  • CrewAI, litellm'i 1.82.6'ya (son güvenli sürüm) sabitledi ancak commit mesajında ihlale dair bir ifade yer almadı
  • DSPy, açık şekilde bir issue oluşturarak müdahale yürütüyor
  • LangChain, kendi LLM provider çağrı katmanına sahip olduğu için bu tedarik zinciri ihlalinden doğrudan etkilenmedi (langchain-litellm adlı isteğe bağlı paket kullanımı hariç)

Topluluk tartışması: tedarik zinciri güvenliği ve sandboxing

  • Bağımlılıklar ve geliştirme ortamları artık güvenilir varsayılamaz; VM izolasyonu + container primitive'leri + izin listesi + egress filtresi + seccomp + gVisor gibi çok katmanlı savunma gerekli
  • Son 50 yıldaki güvenlik uğruna kolaycılık geri tepmeye başladı ve tüm güvenlik modelinin yeniden tasarlanması gerektiği savunuluyor
  • Programlama dili seviyesinde modül bazlı sandboxing ihtiyacını savunan görüşler var
    • Java'da bu özellik 1990'larda v1.2'den itibaren vardı ancak kullanılabilirlik sorunları nedeniyle kaldırıldı
    • Capability tabanlı dillerin geliştirilmesi için doğru zaman olduğu ifade ediliyor
    • Cloudflare'ın workerd çalışma zamanı, modül izolasyonu yapabilen mevcut bir çözüm olarak anıldı
  • OpenBSD'nin pledge/unveil, Linux'un chroot/namespace/cgroup, FreeBSD'nin Capsicum gibi işletim sistemi seviyesinde izolasyon araçları zaten mevcut
  • Guix, birkaç saniye içinde izole container'lar oluşturup $HOME dizinine erişmeden bağımlılık kurabiliyor
  • Firejail ve bwrap gibi kullanıcı alanı izolasyon araçlarının daha aktif kullanılması gerektiği vurgulandı
  • Mobil uygulamalardaki sandboxing + izin modeli (Intents) zaten var, ancak masaüstü ortamlarında genel işlem kısıtlamalarına güçlü bir direnç bulunuyor
    • Buna karşılık, Apple/Meta gibi şirketlerin uygulama mağazası kapalılığı ile güvenlik sandboxing'inin ayrı meseleler olduğu ve kullanıcıya kontrol vererek de güvenliğin sağlanabileceği savunuluyor
  • macOS için bir canary/honeypot aracı paylaşıldı (github.com/dweinstein/canary): sahte sırları WebDAV/NFS üzerine mount edip anormal erişimi algılıyor
  • Paket yayını ile herkese açık depo arasına duvar örülmesi gerektiği yönünde görüşler var: herkese açık depoyu doğrudan Trusted Publisher yapmak saldırı yüzeyini genişletiyor
    • Karşı görüş ise, Trusted Publishing'in asıl amacının kaynak ile yayınlanan artefakt arasında denetlenebilir bağ kurmak olduğu ve özel depo üzerinden geçmenin bir geri adım sayılacağı yönünde

Pratik güvenlik önerileri

  • Bağımlılıklar SHA256 checksum ile birlikte sürüm sabitlenerek kullanılmalı
  • En yeni sürümü doğrudan çekmeyi önlemek için şirket içinde paket aynası işletilmeli
  • Dağıtımda anlık kurulum yerine build artefaktları kullanılmalı ve uv run gibi komutlarla canlı ortamda kurulum yapılmamalı
    • Böylece PyPI kesintisinin sistemi durdurması gibi yapısal riskler de ortadan kalkar
    • Dağıtılabilir artefaktların avantajları: denetlenebilirlik, hızlı rollback, dışa giden ağ için riskli uç noktaların engellenebilmesi
  • uv'nin exclude-newer ayarıyla belirli bir süre içindeki yeni paketler hariç tutulabilir
    • pyproject.toml içinde [tool.uv] exclude-newer = "5 days" olarak ayarlanabilir
  • CI/CD tarafında yayınlama token'ları OIDC tabanlı iş akışlarına taşınmalı; böylece token'ı tamamen ortadan kaldırmak mümkün olur
    • Hem GitHub hem PyPI OIDC destekliyor: yalnızca yayın job'una OIDC endpoint erişimi verildiğinde Trivy işinden çalınacak bir token kalmıyor
  • Trivy gibi güvenlik tarama araçları, yayın yetkisi olmayan ayrı worker'larda çalıştırılmalı
  • lockfile yönetimi ve haftalık güncelleme döngüsüyle en yeni sürümü anında benimsemekten kaçınılmalı
  • Python .pth dosyaları otomatik kod çalıştırabildiği için -S seçeneğiyle site import'u engellenebilir, ancak uyumluluk sorunları olabilir
  • osv-scanner gibi araçlarla projenin tüm bağımlılıklarının taranması öneriliyor
  • Bulaşma kontrolü için komutlar:
    • find / -name "litellm_init.pth" -type f 2>/dev/null
    • find / -path '*/litellm-1.82.*.dist-info/METADATA' -exec grep -l 'Version: 1.82.[78]' {} \; 2>/dev/null
  • Paket yöneticisi ekosisteminin tamamında kimlik bilgilerini topluca yenileme (credential rotation) ihtiyacı da gündeme geldi

SOC2 denetimi ve güvenilirlik sorunu

  • LiteLLM'in SOC2 denetimini yapan firmanın, yakın dönemde tartışma konusu olan Delve olduğu belirtildi
  • SOC2 yalnızca "belgelenmiş süreçlerin gerçekten uygulanıp uygulanmadığını" doğrular; güvenlik seviyesinin kendisini garanti etmez
  • Uygun bir SOC2 denetimi olsa bile bunun bu tedarik zinciri saldırısını önleyip önleyemeyeceği belirsiz

LiteLLM'e alternatif projeler

  • Bifrost (github.com/maximhq/bifrost): Rust tabanlı alternatif; ücretsiz açık kaynak örnekte bile sanal anahtar yapılandırabiliyor
  • Portkey (portkey.ai): proxy hizmeti; ücretsiz plan sunuyor, LiteLLM'den daha hızlı olduğu söyleniyor
  • pydantic-ai: Python tabanlı alternatif
  • any-llm (github.com/mozilla-ai/any-llm): Mozilla projesi
  • LLM Gateway (llmgateway.io): LiteLLM geçiş rehberi sunuyor
  • InferXgate (github.com/jasmedia/InferXgate): yeni bir proje, desteklediği provider sayısı sınırlı
  • Bazı geliştiriciler, LLM provider API'lerinin pratikte yalnızca OpenAI ve Anthropic olmak üzere iki tür olduğunu, bu yüzden doğrudan requests.post() çağrısı yapmanın daha güvenli olduğunu savunuyor
    • Buna karşılık, Anthropic'in OpenAI uyumlu API'sinin uzun vadeli/production çözümü olarak önerilmediği ve provider'a özgü yerel API'lerde OpenAI API'sine eşlenmeyen benzersiz özellikler bulunduğu belirtiliyor

İlgili okumalar

1 yorum

 
GN⁺ 2026-03-25
Hacker News görüşleri

  • LiteLLM’in maintainer’ıyım. Mevcut durum hâlâ inceleniyor, ancak şu ana kadar tespit edilenler şöyle:

    1. Sorun, CI/CD’de kullanılan trivy’den kaynaklanmış gibi görünüyor (ilgili arama bağlantısı, analiz yazısı)
    2. Proxy docker kullananlar etkilenmedi. Çünkü sürüm requirements.txt içinde sabitlenmişti
    3. Söz konusu paket PyPI’de karantinaya alındı ve indirilmesi engellendi
      Şu anda kök neden analizi ve güvenlik güçlendirme önlemleri gözden geçiriliyor; verdiğimiz rahatsızlık için üzgünüz
    • Etkilenen sürümler (v1.82.7, v1.82.8) PyPI’den kaldırıldı. Tüm maintainer hesapları ve anahtarları (GitHub, Docker, CircleCI, pip) değiştirildi. Hâlâ tüm projeyi tarıyoruz ve güvenlik uzmanlarının yardımını memnuniyetle karşılıyoruz (iletişim: krrish@berri.ai)
    • Birisi kişisel GitHub hesabımın da ele geçirilmiş gibi göründüğünü söyledi. Arama sonuçlarında ilgili izler göründüğü söyleniyor
    • “Üzgünüm” dememin insani bir ifade olduğunu söyleyenlere teşekkürler. Resmî bir özür metni yerine samimi bir yaklaşımın daha iyi olduğu yönündeki geri bildirim güç veriyor
    • Credential rotation’ın neden hemen yapılmadığı soruldu. Kısa sürede bunun neden fark edilmediğini açıklamam gerekecek gibi görünüyor
    • Birisi kendi sisteminde kurulu litellm sürümünü bulmak için basit bir betik hazırlayıp paylaştı (betik bağlantısı). Mükemmel değil ama conda, .venv, uv ve sistem ortamını hızlıca tarayabildiği söyleniyor

  • Hâlâ bağımlılıklara ve geliştirme ortamlarına güvenemiyoruz. Dev container’lar yeterince izole değil ve kullanılabilirlikleri de düşük. Artık sandbox tabanlı geliştirme ortamlarına geçmemiz gerekiyor. VM düzeyinde izolasyon, egress filtreleri, seccomp, gVisor gibi savunma katmanlarına sahip ortamlar gerekli. Böyle bir ortamda ihlal yaşansa bile container hemen sonlandırılabilir ve sorun kolayca tespit edilebilir

    • Son 50 yıldaki güvenlik kestirmeleri sonunda bumerang gibi geri dönmüş gibi görünüyor. Güvene dayalı geliştirme kültürünün sonuna geliyoruz. Basit sandboxing’in ötesinde, güvenlik modelinin kendisinin yeniden tasarlanması gerekiyor
    • Artık “eskiden olduğu gibi” yaklaşımı işlemiyor. Kriptografik olarak doğrulanabilir güvenlik şart. Red Hat’in DISA STIG yaklaşımında olduğu gibi harici depoların kullanımını yasaklayan bir yöne gitmeliyiz
    • Credential’ları container’dan izole etmeye yönelik projelerim hakkında görüş istendi (tightbeam, airlock)
    • smolvm adında bir açık kaynak proje geliştiriyorum (bağlantı). VM düzeyinde izolasyon ile container desteğini birleştiren bir teknoloji; hedefi tam anlamıyla sanal makine birimi dağıtımı yapmak. Birlikte çalışacak kişiler arıyorum
    • Son dönemdeki tedarik zinciri saldırılarında gerçekten dev container escape vakaları yaşanıp yaşanmadığı soruldu

  • macOS için yaptığım canary aracını tanıttım (bağlantı). Paketlerin erişmemesi gereken dosyaları tespit eden basit bir Go ikilisi. WebDAV veya NFS üzerinden sahte gizli bilgiler açığa çıkarıyor ve erişim olduğunda uyarı gönderiyor. Honeypot yaklaşımıyla anormal davranışlar tespit edilebiliyor

  • Bu olay, son birkaç haftadaki TeamPCP faaliyetleriyle bağlantılı. Hazırladığım zaman çizelgesi faydalı olabilir

    • Bunun harika bir derleme olduğu söylendi. Ama “çalma listesi”nin özellikle etkileyici olduğuna dair bir şaka da yapıldı
    • TeamPCP adını birçok yerde görmüştüm ama böyle tek bakışta anlaşılır biçimde derlenmiş hâlini ilk kez gördüm diyenler oldu
    • Bu güncellemeleri bu kadar hızlı nasıl güncel tuttuğum da soruldu

  • GitHub’ın spam tespit sisteminin çok zayıf olduğuna dikkat çekildi. litellm issue’suna 170’ten fazla spam yorum yazıldığı söylendi

    • Birkaç gün önce trivy deposunda da aynı şey yaşandı. Hack ile ilgili tartışma kapatılınca 700’den fazla spam yorum geldi. Bazıları gerçekten geçmiş etkinliği olan hesaplardan geliyordu. Credential theft odaklı saldırıların geniş çapta yayılmış olduğu anlaşılıyor. Birçok hesapta şubatta “Update workflow configuration” commit’iyle CI içine credential stealer yerleştirildiğine dair izler var
    • GitHub’da spam bildirmek için birçok adımdan geçmek gerektiği ve bunun verimsiz olduğu yönünde şikâyetler vardı
    • Bazılarının sadece bot hesaplar olabileceği de söylendi

  • Bunun bir gün olacağı bekleniyordu. Bağımlılık sürümlerini sabitleyerek savunmaya çalıştık ama bu da kusursuz değil. Açık kaynağın tedarik zinciri karmaşıklığı yüzünden tüm kodu doğrulamak imkânsız. LLM’ler sayesinde kötü amaçlı kodun kitlesel biçimde yayılma riski 100 kat arttı

    • Rust ekosisteminde bağımlılık ağacı çok derin olduğu için doğrulamanın zor olduğu söylendi. Rust, Node ve Python benzer sorunlar yaşıyor. Buna karşılık C/C++ sistem paket yöneticileri kullandığından bağımlılık ekleme maliyeti daha yüksek ve bu yüzden görece daha güvenli

  • Eğer AI tarafından yazılmış kod LLVM veya Linux içine sızarsa, gerçekten “trusting trust” sorunuyla karşı karşıya kalırız

    • “Trusting Trust” problemi için zaten Diverse Double-Compiling yöntemiyle bir çözüm önerilmişti. Ama tedarik zinciri saldırıları hâlâ zor bir problem. AI sadece saldırının ölçeğini büyüten bir araç
    • Artık her şey tedirgin edici geliyor. Belki sadece airgap ortamları güvenlidir. Ama verilerin çoğu bulutta ve yedekleri üzerinde bile kontrolümüz yok
    • Deterministik build zincirleri ile tamamen doğrulanabilir yazılım üretmeye yönelik çalışmalar sürüyor. Debian paketlerinin %93’ü yeniden üretilebilir build’e sahip. Ama hâlâ birçok geliştirici rahatça curl | bash çalıştırıyor. XZ backdoor olayı bunun ne kadar ciddi olduğunu gösteren bir örnekti
    • LLM’lerin kernel kodunu öğrenmesini engellemek için iç API’leri sık sık değiştirmek tek savunma olabilir diyenler de vardı
    • Böyle bir saldırı gerçeğe dönüşürse, devlet sunucuları veya bulut altyapıları büyük çaplı zarar görebilir. Özellikle devlet destekli hack faaliyetleriyle birleşirse zararın boyutu trilyonlarca dolara ulaşabilir. Yine de Linux’un görece daha güvenli olduğunu düşünenler vardı

  • LiteLLM’in SOC2 denetim kuruluşunun Delve olduğu da belirtildi.

    • Ama SOC2 sertifikasının böyle bir saldırıyı önleyip önleyemeyeceği tartışmalı. Uygulamada SOC2’nin tam bir kalkan olmadığını gösteren deneyimler paylaşıldı

  • Harbor kurduğumda CPU %100’e fırladı ve sistem kilitlendi. grep -r rpcuser\rpcpassword süreci kripto para cüzdanı araması yapmaya çalışıyor gibi görünüyordu. Neyse ki bir backdoor kurulmadı

    • browser-use tarafında da aynı şeyi yaşadığını söyleyen biri vardı. litellm bağımlılık olarak kurulmuş ve sistem kilitlenmişti. GitHub ve HuggingFace token’larını geçersiz kıldığını ama işletim sistemini yeniden kurması gerekip gerekmediğini sordu
    • “Süreci bunu kadar hızlı nasıl fark ettin?” diye soranlar oldu. Activity Monitor’ü sürekli açık tutup tutmadığı merak edildi
    • “Harness nedir?” diye soranlar da vardı

  • Bu olayın, Trivy’yi hackleyen TeamPCP ile aynı saldırı grubunun işi olduğu düşünülüyor. Issue’ların bot yorumlarla dolması da aynı örüntüye uyuyor. LLM kullanan otomatik saldırılar olma ihtimali yüksek

    • Saldırganların neden issue’ları bot yorumlarla doldurduğu soruldu. Muhtemelen amaç kaos yaratmak ve müdahaleyi geciktirmek