LiteLLM 1.107.0'daki kötücül yazılım, git'ten sililen ama hiç iptal edilmeyen bir anahtara dayanıyor

LiteLLM ekibinin yayımladığı olay incelemelerine göre, 21 Ekim 2026'da PyPI'ya yayınlanan LiteLLM 1.107.0 sürümü, kimlik bilgileri çalmak ve uzaktan kod çalıştırma araçlarını çekmek için tasarlanmış derlenmiş kötücül yazılım içeriyordu. Sızıntı, aylar önce Mayıs'ta herkese açık bir depoya commit'lenen ve dosya saatler içinde silinmesine rağmen hiç iptal edilmeyen bir yönetici anahtarıyla başladı. Güvenlik firması Wiz, ClickPy verilerine dayanarak, kötücül derlemenin yayında olduğu yaklaşık iki saat içinde kabaca 49.000 kez indirildiğini tahmin ediyor. Gabriel Anhaia'nın dev.to üzerinde LiteLLM'in olay bildirimlerine dayanarak hazırladığı ayrıntılı zaman çizelgesi, sızan tek bir anahtarın nasıl zehirli bir sürüme dönüştüğünü yeniden yapılandırıyor.

Saldırı nasıl gelişti

27 Mayıs 2026'da, herkese açık LiteLLM-Labs/lite-harness deposunda, dahili bir LiteLLM Agent Platform dağıtımının yönetici anahtarını içeren opencode.json adlı bir dosya belirdi. Ardından gelen bir commit dosyayı yaklaşık üç saat sonra kaldırdı, ancak anahtar geçerli kaldı ve commit, 22 Ekim'e kadar herkese açık geçmişte erişilebilir durumda kaldı.

10 Ekim'de bir saldırgan, bu anahtarı kullanarak Agent Platform API'sine kimlik doğrulamalı çağrılar yapmaya başladı. İsteklerden biri, yönetilen her agent'ın yapılandırmasını döndürdü ve bu yapılandırmlardan biri, LiteLLM'in GitHub organizasyonunun iki sahibinden birinin GitHub CLI OAuth token'ını içeriyordu. Token, platformun pull request açmak için GitHub erişimine ihiyaç duyması nedeniyle oradaydı; dar kapsamlı bir personal access token yerine, hiçbir kapsam taşımayan bir sahibin CLI girişi verilmişti. Dakikalar sonra, iki tek kullanımlık branch, depo secret'larını harici bir webhook uç noktasına gönderen CI workflow'ları çalıştırarak iki maintainer'a ait token'ları topladı. Her iki workflow çalışması da yaklaşık üç dakika içinde silindi.

Ana olay 21 Ekim'de gerçekleşti. Branch koruması başlangıçta LiteLLM'in özel sürüm deposuna yapılan bir push'u reddetti; beş saniye sonra aynı değişiklik owner token'ıyla geçti. Değişiklik, release workflow'suna bir source_owner girdisi ekleyerek herhangi bir organizasyondan derleme yapabilmesini sağladı. Staging daha sonra BerriAI/litellm yerine benzer isimli Berri-AI/litellm deposuna karşı çalıştı ve ikinci bir çalınmış token, LiteLLM'in yakın zamanda herhangi iki mühendisin bir sürümü tetikleyip onaylayabileceği şekilde gevşettiği üretim kapısını onayladı. 11:39 ile 11:47 UTC arasında yedi kötücül wheel PyPI'ya yüklendi ve Docker Hub ile GHCR'a v1.107.0, latest, main-latest ve main-stable etiketleriyle container image'ları push edildi. Ardından üçüncü bir çalınmış token, workflow çalışma kayıtlarını sildi. PyPI sürümü 13:23 UTC'ye kadar kaldırdı ve Docker etiketleri 14:20'ye kadar temiz image'lara yönlendirildi. LiteLLM, GitHub'daki resmi v1.107.0 source tag'inin hiçbir zaman kötücül dosyaları içermediğini belirtiyor.

LiteLLM'in ilk olay incelemesi çalınan token'ların kaynağını yanlış tanımlayıp dahili dağıtım günlüklerinden şüphelendi; 23 Ekim'deki düzeltme, ilk token'ı Agent Platform'a bağladı.

Dosyayı silmek neden hiçbir şeyi değiştirmedi

dev.to analizinde açıklandığı gibi, bir dosyayı silen commit yalnızca yeni bir snapshot ekler. Anahtar dahil eski snapshot, aradaki her clone ve fork'tan hash ile erişilebilir kalır. GitHub'ın açığa çıkan secret'ların ele alınmasına ilişkin kendi rehberi de bu yüzden iptali ilk sıraya koyar: herkese açık geçmişte duran ölü bir anahtar zararsızdır, silinmiş bir dosyadaki canlı bir anahtar ise hâlâ canlı bir anahtardır. Bu anahtar dört aydan uzun süre canlı kaldı.

Yazıda ayrıca bir coding-agent sorununa dikkat çekiliyor. Bir agent oturumu bir config dosyasını bir turda ekleyip sonraki bir turda kaldırabildiği için, yalnızca son pull request diff'ini okuyan bir inceleyici iki değişikliği de göremez. LiteLLM Mayıs commit'ini kimin veya neyin yaptığını söylemiyor ve analiz bir agent'ın yaptığını varsaymıyor; asıl nokta, son diff incelemesinin her iki durumda da bunu gözden kaçıracağıdır.

Sağlamlaştırma adımları

dev.to yazısı, tam olarak bu hata biçimini hedefleyen uygulamalarla sona eriyor. Literal secret'ları agent config dosyalarından uzak tutun: Config dosyası opencode.json olan OpenCode, ortam değişkeni ve dosya yolu değiştirmeyi destekliyor, böylece anahtarlar deponun dışında duruyor. Bir secret'ın yok olduğundan emin olmadan önce geçmişi arayın; git log --all -S 'sk-' gibi komutlar hem bir dizgeyi ekleyen hem de kaldıran commit'i yakalar. Bir şey ortaya çıktığında önce sağlayıcıda iptal edin, sağlayıcının günlüklerinde commit tarihinden bu yana kullanımı kontrol edin ve ancak sonra geçmişi yeniden yazmayı düşünün. Son olarak, bir agent oturumunun erişebileceği GitHub kimlik bilgilerini kapsamlandırın: yalnızca pull request açması gereken bir hizmet asla owner düzeyinde bir CLI girişi taşımamalıdır.

LiteLLM'in 30 Ekim'deki takip yazısı iptali bir sürece dönüştürüyor: secret scanning artık otomatik olarak ticket açıyor ve ticket'lar yalnızca iptal onaylandığında kapanıyor.

Neden önemli

Bu, doğrudan AI geliştirme araçlarını hedefleyen bir tedarik zinciri saldırısı ve maruziyet penceresindeki kabaca 49.000 indirim, kısa ömürlü bir zehirli sürümün bile ne kadar geniş bir etki alanına sahip olduğunu gösteriyor. Zincir, yaygın hata biçimlerinin bir kontrol listesi: iptal edilmemiş bir anahtar, kapsamlı bir token'ın yerine geçmiş aşırı yetkili bir token, gevşetilmiş sürüm kapıları, benzer isimli bir organizasyon adı ve silinmiş denetim izleri. Buradaki her ders, üretim kimlik bilgilerine yakın herhangi bir yerde coding agent ve CI pipeline çalıştıran her ekip için genellenir ve olay, git'te bir dosyayı silmenin secret'ı çalışma ağacından gizlediği ama geçmişi okumaya istekli herkesten gizlemediğinin somut bir hatırlatıcısıdır.