LiteLLM tedarik zinciri saldırısına dakika dakika müdahale kaydı

• PyPI üzerinden dağıtılan LiteLLM 1.82.8 kötü amaçlı paket enfeksiyonunun gerçek zamanlı olarak tespit edilip analiz edildiği dakika dakika müdahale günlüğü
• Enfeksiyon Cursor IDE otomatik güncellemesi sırasında meydana geldi ve litellm_init.pth dosyası çalıştırılarak kimlik bilgisi hırsızlığı ve sistem enfeksiyonuna yol açtı
• Kötü amaçlı kod, SSH anahtarları ve bulut kimlik bilgilerinin toplanması, Kubernetes'e yayılma girişimi, fork bomb oluşturma gibi birleşik davranışlar sergiledi
• Olay hemen PyPI güvenlik ekibine ve LiteLLM bakımcılarına bildirildi; bunun sonucunda paket karantinaya alındı ve CVE kaydı oluşturuldu
• Claude Code gibi yapay zeka tabanlı kod analiz araçları saldırının tespitinde kilit rol oynadı ve yapay zeka ekosisteminde tedarik zinciri güvenliğinin güçlendirilmesi gerektiğini ortaya koydu

---

LiteLLM tedarik zinciri saldırısına müdahale kaydı

• LiteLLM 1.82.8 sürümünün PyPI üzerinden dağıtılan kötü amaçlı bir paket olduğu doğrulandı; enfeksiyonun tespitinden karantinaya alınmasına kadar geçen süreç dakika dakika kaydedilmiş bir müdahale günlüğü olarak sunuluyor
• Enfeksiyon, Cursor IDE'nin otomatik güncelleme sürecinde meydana geldi; Claude Code ve uv paket yöneticisi üzerinden kurulan bağımlılıklar arasındaki litellm_init.pth dosyası çalıştırılarak sistem enfeksiyonuna neden oldu
• Saldırı; kimlik bilgisi hırsızlığı, sistemde kalıcılık kurulumu, Kubernetes'e yayılma girişimi ve fork bomb dahil olmak üzere birleşik davranışlardan oluşuyordu
• Olay hemen PyPI güvenlik ekibine ve LiteLLM bakımcılarına bildirildi; bu da paketin karantinaya alınmasına ve CVE atanmasına yol açtı
• Yapay zeka tabanlı kod analiz araçları, gerçek zamanlı kötü amaçlı davranış tespiti ve analizinde kilit rol oynadı

İlk tespit ve sistem anormallik belirtileri

• 11:13 UTC civarında bir macOS dizüstü bilgisayarda 11.000'den fazla Python süreci oluşturuldu ve sistem kilitlenme durumuna girdi
  • exec(base64.b64decode('...')) biçimindeki komutlar tekrar tekrar çalıştırılarak CPU ve bellek tüketildi
  • Zorla kapatma ve yeniden başlatma sonrasında kalıcılık (persistence) ile ilgili iz bulunmadı
• Başlangıçta bunun, Claude Code iç döngüsü ya da uv run betiği hatasından kaynaklanan kötü amaçlı olmayan bir döngü olayı olduğu düşünüldü
• Daha sonra htop ekran görüntüsü ve loglar üzerinden base64 ile kodlanmış bir Python betiğinin tekrar tekrar çalıştırıldığı doğrulandı

Enfeksiyon nedeninin belirlenmesi

• 11:40 civarında kurulu Python araçları içinde litellm_init.pth dosyası bulundu ve olayın kötü amaçlı olduğu anlaşıldı
  • .pth dosyaları Python başlangıcında otomatik çalışır ve tüm Python süreçlerinde devreye girer
  • SSH anahtarları, bulut kimlik bilgileri, veritabanı parolaları, ortam değişkenleri ve shell geçmişi gibi verileri toplar
  • Toplanan veriler RSA ile şifrelenip https://models.litellm.cloud/ adresine gönderildi
  • ~/.config/sysmon/sysmon.py içine kalıcılık kurmaya çalıştı ancak zorunlu yeniden başlatma nedeniyle süreç yarıda kaldı
• Enfeksiyon Cursor IDE'nin otomatik güncellemesi (10:58 UTC) sırasında gerçekleşti
  • futuresearch-mcp-legacy uzantısı uvx aracılığıyla litellm 1.82.8 sürümünü indirdi
  • Bu sürüm yalnızca PyPI üzerinde vardı ve GitHub release etiketi bulunmuyordu
  • PyPI yükleme zamanı 10:52 UTC idi; yani enfeksiyondan hemen önce dağıtıma çıkmıştı

Kötü amaçlı kodun yapısı

• 1. aşama (litellm_init.pth): Python başlangıcında otomatik çalışır, base64 ile kodlanmış yükü çözüp çalıştırır
• 2. aşama: Çalınan verileri şifrelemek için kullanılan RSA açık anahtarını içerir
• 3. aşama (B64_SCRIPT): Gerçek kimlik bilgisi toplama ve gönderme işlemini yürütür
• Kalıcılık kurulumu: sysmon.py dosyasını bir systemd servisi olarak kaydetmeye çalışır
• Kubernetes'e yayılma kodu: alpine:latest imajını kullanarak her düğümde privileged pod oluşturmaya çalışır
• Fork bomb nedeni: subprocess.Popen([sys.executable, "-c", ...]) çağrısı, alt süreçlerde de .pth dosyasını yeniden çalıştırarak sonsuz döngü oluşturdu

Etki kapsamı ve müdahale adımları

• Açığa çıkmış kimlik bilgileri

  • SSH anahtarları, GCloud ve Kubernetes kimlik bilgileri, .env dosyalarındaki API anahtarları, Supabase·ClickHouse·Grafana parolaları vb.
  • Acil eylem önerileri
  1. Tüm SSH ve bulut kimlik bilgilerini döndürün
  2. .env ve .mcp.json içindeki gizli anahtarları yeniden oluşturun
  3. ~/.cache/uv önbelleğini silin
  4. PyPI güvenlik ekibine ([e-mail]) ve LiteLLM bakımcılarına bildirin

• Kubernetes kümesi inceleme sonucu

  • Kötü amaçlı pod'lar (node-setup-*, sysmon) bulunmadı
  • Olay macOS ortamında çalıştığı için küme içine yayılma başarısız oldu
  • Ancak ~/.kube/config açığa çıkmış olabileceğinden kimlik bilgilerinin döndürülmesi gerekiyor

PyPI ve kamuya açık müdahale

• 11:58 UTC'de Docker ile izole edilmiş ortamda PyPI'dan litellm 1.82.8 yeniden indirilerek kötü amaçlı .pth dosyasının varlığı tekrar doğrulandı
• PyPI güvenlik ekibine ve BerriAI/litellm deposuna derhal bildirim yapıldı
  • Sonrasında olay PYSEC-2026-2 (CVE) olarak kaydedildi
• 12:01 UTC'de FutureSearch blogunda tedarik zinciri saldırısını açıklayan bir gönderi yazıldı ve yayımlandı
  • PR hazırlama ve birleştirme işlemi 3 dakika içinde tamamlandı
• 12:04 UTC'de r/Python, r/netsec, r/LocalLLaMA, r/MachineLearning, r/devops topluluklarında paylaşım önerildi
  • Python ve güvenlik topluluklarının hızlı tepki vermesi teşvik edildi

Olayın anlamı

• Yapay zeka tabanlı kod analiz aracı Claude Code, kötü amaçlı davranışı gerçek zamanlı olarak tanımladı ve güvenlik araştırmacısı müdahalesinden önce uyarı üretti
• Bu tedarik zinciri saldırısı, yapay zeka geliştirici ekosistemini doğrudan hedef alan bir örnek olarak PyPI hesap güvenliği ve otomatik güncelleme doğrulamasının güçlendirilmesi gereğini öne çıkardı
• Ayrıca yapay zeka araçlarının yalnızca geliştirme yardımı için değil, siber tehdit tespiti ve müdahale otomasyonu için de kullanılabileceğini gösterdi

[GN⁺]

Hacker News görüşleri

• litellm açığını ilk fark edip bildiren geliştirici benim
  O anda yaşananları olduğu gibi kaydettiğim gerçek zamanlı analiz dökümünü paylaştım
  Claude, kiminle iletişime geçmem gerektiğini ve hangi sırayla aksiyon almam gerektiğini adım adım anlattı; bu da güvenlik uzmanı olmayan biri için bile çok yardımcı bir deneyimdi
  Bu şekilde uzman olmayan kişilerin açık bulup raporlamasının güvenlik topluluğuna fayda mı sağladığını, yoksa kafa karışıklığı mı yarattığını merak ediyorum

  • Güvenlik sektöründe çalışan biri olarak, Claude’un yardımıyla bunun bulunmuş olması etkileyici
    Yine de “Cursor’u yeniden açar açmaz kötü amaçlı paket çalıştı” kısmı biraz riskli görünüyor
    Şüphe oluştuğu anda önce cihazı izole etmek ve güvenlik ekibiyle iletişime geçmek gerekirdi
  • Ben de neredeyse aynı anda, aynı şekilde bu sorunu fark ettim
    .pth dosyası bir fork bomb gibi çalışmasaydı muhtemelen çok daha geç fark edilecekti
    Claude’a iletişim kanalını sormak iyi bir karardı
    PyPI ile ilgili kime ulaşacağımı bilmediğim için bakımcıya e-posta attım ve Hacker News’te de paylaştım
    Güvenlik topluluğunun parçası olmasanız bile, böyle ciddi açıkları raporlayabilmek herkes için mümkün olmalı diye düşünüyorum
  • Birden fazla şirkette açık ifşa programları yönetmiş biri olarak deneyimim var
    Sorunların çoğu, para kazanmak için her şeye açık diyen insanlardan çıkıyor
    Ama senin raporun yüksek kaliteliydi; böyle durumları doğrudan yama önceliği listesine alırdım
    İş kesintisi yaratmadan çözülebiliyorsa hemen müdahale eder, ciddiyse doğrudan CISO veya CTO’ya raporlardım
  • Yazıyı keyifle okudum. Claude’un bu tür durumlarda özellikle faydalı olduğunu düşündüm
    Senin raporun sayesinde daha büyük bir olayın önüne geçilmiş oldu
    Biz de ilgili konuyu iki ayrı blog yazısında topladık
    grith.ai blog yazısı
  • Son dönemde açık kaynak projelerin açık raporları ve PR yağmuru yüzünden zorlandığını duyuyorum
    Ama bu örnek, AI yardımıyla kök neden analizi ve raporlamanın çok daha hızlı yapılabildiğine dair iyi bir vaka bence

• claude-code-transcripts aracımın bir blog yazısına veri olarak gömüldüğünü ilk kez görüyorum
  Normalde Gist’in HTML sayfası üzerinden paylaşıyordum; bu kullanım ilginç geldi

  • Bizim şirkette de bunu aktif olarak kullanıyoruz
    Blog stiline uydurmaya çalışırken başarısız olduk ama temel deneyimin önemini yeniden fark ettik
    Claude, sanki tüm bilgisayarımı tarıyormuş gibi logları çekip alıyor; bu yüzden otomatik log redaksiyon sistemi gerektiğini düşündüm
  • Claude Code oturumları arasında bilgi paylaşımı hâlâ büyük bir sorun
    Özellikle acil hata ayıklama sırasında ekiple işbirliği yaparken çok rahatsız edici

• “Kötü amaçlı script içeriğini çalıştırmadan ekrana basabilir misin?” gibi istekler riskli
  LLM ajanlarında sorumluluk kavramı olmadığı için, yanlışlıkla bir çalıştırma komutu verilirse büyük bir olaya dönüşebilir
  PyPI’den dosya indirirken bunu mutlaka sandbox ortamında yapmak gerekir

  • Ben de o noktadan endişelendim
    “Yapma” denince insanın tam tersine ona takılma eğilimi oluyor

• PyPI’nin “digital attestation” desteği sunduğunu duymuştum; bu paketin imzalanıp imzalanmadığını merak ediyorum
  PyPI Trusted Publishers dokümanı

• GitHub, npm ve PyPI gibi paket kayıtlarının gerçek zamanlı güvenlik analizi için olay akışı (firehose) sağlaması gerektiğini düşünüyorum
  Bu tür saldırılar otomatik tarayıcılar tarafından anında yakalanabilirdi

  • PyPI zaten böyle bir özellik sunuyor
    Güvenlik ortakları paketleri tarayabiliyor ve davet tabanlı API ile rapor gönderebiliyor
    Ayrıntılar için PyPI blog yazısına bakabilirsiniz
  • Ben de bu olaydan sonra dependency cooldown uygulamaya başladım
    İlgili yazı
    Amaç, otomatik tarayıcılara .pth dosyaları gibi anormallikleri tespit etmeleri için zaman kazandırmak
  • npm paket değişiklik akışı sağlıyor, GitHub ise olay firehose’u ve herkese açık BigQuery veri kümeleri sunuyor
  • Bu tür altyapıların sağlanması yasal bir zorunluluk olmalı diye düşünüyorum
    Ekonomik zarar çok büyük olabilir ve yalnızca litellm enfekte kullanıcılarının sayısı 47 bini aşıyor

• “Blog yazısı yazımı, PR ve merge işlemi 3 dakikanın altında” kısmı en sarsıcı olanıydı
  Okuma süresinden bile kısa bir hız olduğu için kaygı verici geldi

• 11 bin süreçlik fork bomb olmasaydı, bu saldırı belki de çok daha uzun süre gizli kalacaktı

  • Ben de paketi kurarken sistem anında kilitlendiği için enfeksiyondan kurtuldum
    Eğer bombanın hızını düşürmüş olsalardı etkisi çok daha büyük olabilirdi
  • Buna bu neslin internet kurdu demek gerekebilir

• Büyük şirketlerin güvenilmeyen açık kaynak kodunu çalıştırmasının iki yolu var

  1. Google tarzı her şeyi doğrudan kaynaktan derlemek
  2. Sadece şirket içi mirror üzerinden çekmek ve tüm paketlerde imza doğrulamak
     Gerçekte en güvenli olan yaklaşım (1)
     Küçük ve orta ölçekli şirketler ya da bireyler için en iyi savunma bağımlılık sabitleme (pinning) ve yeterli bekleme süresi
     Bazel kullanılırsa (1)’e daha çok yaklaşılabilir, ama çoğu kişi dış kaynaklara bağımlı kalmak zorunda

• PyPI’nin bildirimin ardından 30 dakika içinde paketi karantinaya alması gerçekten hızlı bir yanıttı

  • Tedarik zinciri saldırılarına karşı savunmasız olduğuna dair çok endişe var ama bu olayda oldukça iyi yönetilmiş bir örnek gördüğümüzü düşünüyorum

• AI/LLM’nin en iyi yanlarından biri tersine mühendisliğin demokratikleşmesi
  Eskiden öğrenmesi zor ve ödülü az bir beceriydi, şimdi AI yön gösterebiliyor

  • Ama bu olay tersine mühendislikten ziyade temel sistem yönetimi meselesi
    exec(base64.b64decode(...)) kalıbı, Python araçlarının kod aktarmasında sık görülen bir yöntem olsa da
    temelde /tmp, /var/tmp veya /dev/shm üzerinden çalışan kodlara son derece şüpheyle yaklaşmak gerekir
    Eğer Lulu veya LittleSnitch gibi ağ izleme araçları olsaydı anormal trafiği engelleyebilirdi
    Yine de Claude’a ikili dosya yükleyip analiz ettirmek başlı başına başka bir risk
  • Ben de CTF videolarını izlerken ilgilenmiştim ama gerçek iş hayatında bununla doğrudan karşılaşmak neredeyse hiç olmuyor