CISA, LiteLLM ve Kestra’daki iki güvenlik açığını aktif istismar kanıtıyla KEV kataloğuna ekledi. Bulgular, AI gateway ve workflow platformlarının kimlik, araç erişimi ve kod çalıştırma yetkilerini bir araya getiren kritik bileşenlere dönüştüğünü gösteriyor.

CISA, yapay zekâ altyapılarında kullanılan LiteLLM ve Kestra platformlarını etkileyen iki güvenlik açığını Known Exploited Vulnerabilities (KEV) kataloğuna ekledi. CVE-2026-59822, LiteLLM’in Model Context Protocol (MCP) kimlik doğrulama mekanizmasını etkilerken, CVE-2026-49869 Kestra’da kimlik doğrulamanın atlatılmasından uzaktan kod çalıştırmaya kadar ilerleyebilen bir saldırı yolu oluşturuyor.

Gelişme yalnızca iki açık kaynak projedeki güvenlik problemi olarak değerlendirilmemeli. AI gateway, MCP ve workflow orchestration bileşenleri, API anahtarları, model erişimi, kurumsal veriler ve işlem çalıştırma yetkilerinin aynı güven sınırında toplandığı kritik altyapı bileşenlerine dönüşüyor.

LiteLLM’de CVE-2026-59822 nasıl çalışıyor?

LiteLLM, uygulamalar ile farklı büyük dil modeli sağlayıcıları arasında merkezi bir AI gateway görevi üstlenebilen bir platform. CVE-2026-59822, 1.84.0 öncesindeki LiteLLM sürümlerinde MCP Streamable HTTP endpoint’inin kimlik doğrulama sürecini etkiliyor.

Güvenlik advisory’sine göre saldırgan, hazırlanmış bir Bearer token ile OAuth2 passthrough fallback davranışını tetikleyebiliyor. LiteLLM anahtar doğrulamasının başarısız olması sonrasında oluşan hata, isteğin geçerli bir LiteLLM anahtarı olmadan MCP araçlarına ulaşmasına izin verebiliyor.

Bu durumun etkisi her ortamda aynı seviyede değil. Gerçek risk, LiteLLM üzerinden hangi MCP araçlarının erişilebilir olduğuna ve bu araçların dosya sistemleri, API’ler, veritabanları veya diğer kurumsal servisler üzerinde hangi yetkilere sahip olduğuna bağlı.

CVE-2026-59822, CVSS v4.0 kapsamında 8.8 puanla yüksek önem seviyesinde değerlendiriliyor. Açığın ağ üzerinden istismar edilebilmesi için önceden ayrıcalık veya kullanıcı etkileşimi gerekmiyor. Sorun LiteLLM 1.84.0 sürümünde giderildi.

Kestra açığı workflow motorunu RCE yoluna dönüştürüyor

Kestra tarafındaki CVE-2026-49869 ise daha ağır bir teknik etkiye sahip. Güvenlik açığı, AuthenticationFilter içerisindeki yol eşleştirme kontrolünün belirli bir endpoint’i tam olarak doğrulamak yerine URL’nin /configs ifadesiyle bitip bitmediğine bakmasından kaynaklanıyor.

Bu hata, hazırlanmış belirli API yollarında kimlik doğrulama kontrolünün atlatılmasına neden olabiliyor. Saldırgan böylece geçerli kullanıcı bilgilerine sahip olmadan workflow oluşturma ve çalıştırma yeteneği elde edebiliyor.

Kestra’nın script ve komut çalıştırabilen görev eklentileriyle birleştiğinde bu yetki, worker container içerisinde uzaktan kod çalıştırmaya kadar ilerleyebiliyor. Üretici advisory’si açığı CVSS v3.1 kapsamında 10.0 puanla kritik olarak değerlendiriyor.

Kestra, sorunun 1.0.45 ve 1.3.21 sürümlerinde giderildiğini belirtiyor. Etkilenen kurulumların kullandıkları sürüm dalına uygun yamalı sürüme geçmesi gerekiyor.

Açıklar CISA KEV kataloğuna girdi

CISA, 2 Eylül 2026’da CVE-2026-59822 ile CVE-2026-49869’u Known Exploited Vulnerabilities kataloğuna ekledi. KEV kaydı, güvenlik açıklarının yalnızca teorik olarak istismar edilebilir veya PoC seviyesinde olduğu anlamına gelmiyor. CISA bu listeye, gerçek dünyada istismar edildiğine ilişkin güvenilir kanıt bulunan açıkları ekliyor.

Microsoft’un yayımladığı ayrı tehdit araştırması da AI altyapılarının saldırganlar açısından neden değerli hale geldiğini gösteriyor. Araştırmacılar LiteLLM, RAGFlow ve Kestra gibi bileşenlere yönelik olaylarda kimlik bilgisi toplama, kalıcılık oluşturma, container ortamlarını keşfetme ve kripto madenciliği gibi saldırı sonrası faaliyetler gözlemledi.

Burada önemli bir teknik ayrım bulunuyor. Microsoft’un incelediği LiteLLM kompromisi CVE-2026-59822’ye bağlanmıyor. Araştırma, söz konusu olayda CVE-2026-42271 ile Starlette’deki CVE-2026-48710’un bulunduğu farklı bir saldırı zincirine işaret ediyor. CVE-2026-59822’nin aktif istismar edildiğine ilişkin doğrulama ise CISA KEV kaydına dayanıyor.

Kestra tarafında Microsoft, gözlemlediği ilk erişimin CVE-2026-49869 üzerinden gerçekleşmiş olmasını yüksek güvenle değerlendiriyor. Saldırı sonrasında workflow üzerinden shell çalıştırılması, container ortamının keşfedilmesi ve XMRig madencisinin devreye alınması gibi faaliyetler raporlandı.

Kurumlar hangi önlemleri almalı?

LiteLLM kullanan kurumların öncelikle mevcut sürümlerini kontrol ederek 1.84.0 veya daha yeni bir sürüme geçmesi gerekiyor. MCP endpoint’lerinin doğrudan internete açılmaması, erişimin ağ ve kimlik kontrolleriyle sınırlandırılması ve MCP araçlarına yalnızca ihtiyaç duyulan minimum yetkilerin verilmesi önem taşıyor.

Kestra ortamlarında ise kullanılan sürüm dalına uygun şekilde 1.0.45 veya 1.3.21 ve üzerindeki yamalı sürümlere geçilmeli. Workflow yönetim arabirimleri gereksiz dış erişime kapatılmalı ve worker container’larına ihtiyaç dışı ayrıcalıklar verilmemeli.

Savunma yalnızca yama yönetimiyle sınırlı kalmamalı. AI gateway veya orchestration servislerinden beklenmedik shell ve Python süreçlerinin başlaması, dış kaynaklardan dosya indirme girişimleri, environment değişkenlerine erişim, secret sorgulamaları, Docker socket kullanımı ve olağandışı dış bağlantılar SOC ekipleri için değerli telemetry sinyalleri oluşturabilir.

Bu nedenle AI altyapısının log, process, network ve identity verileri mevcut SIEM ve izleme süreçlerine dahil edilmeli. Böylece yalnızca bilinen CVE’lere değil, saldırı sonrası davranışlara karşı da görünürlük sağlanabilir.

AI güvenliğinde yeni güven sınırı

LiteLLM ve Kestra olayları, AI güvenliğinin yalnızca prompt injection veya model çıktılarının kontrol edilmesinden ibaret olmadığını gösteriyor. Modelin çevresindeki gateway, MCP, retrieval ve orchestration bileşenleri artık klasik kurumsal uygulamalar kadar kritik hale geliyor.

Bu servisler aynı anda API anahtarlarına, secret bilgilerine, workflow’lara ve kod çalıştırma yetkilerine erişebildiğinde tek bir zafiyet geniş bir saldırı zincirinin başlangıç noktasına dönüşebiliyor.

Kurumların AI altyapısını ayrı bir teknoloji adası olarak değil; IAM, segmentasyon, zafiyet yönetimi, loglama, telemetry ve SOC görünürlüğüyle birlikte yönetilmesi gereken yeni bir kontrol düzlemi olarak değerlendirmesi gerekiyor.