Langflow CVE-2026-105740: MCP Stdio Komut Enjeksiyonu Aktif Olarak Sömürülüyor

Selam arkadaşlar,

Yapay zeka ajanı ve iş akışı geliştirmek için kullanılan açık kaynak platform Langflow'da geçen ay kapatılan kritik bir açık, şu anda internete açık sunuculara karşı aktif olarak kullanılıyor. CVE-2026-105740 numaralı açık, Langflow'un MCP (Model Context Protocol) sunucu yapılandırmasındaki "stdio" taşıma yönteminden kaynaklanıyor ve herhangi bir oturum açmış kullanıcının sunucuda işletim sistemi komutu çalıştırmasına izin veriyor. Exploit girişimlerini tespit eden Previdian'ın verileri, saldırganların bu açığı varsayılan ya da zayıf parolalarla birleştirdiğini gösteriyor.

Konuda Anlatılacaklar

1. Langflow nedir, neden hedefte?
   
2. Açığın teknik özeti
   
3. İkinci açık: CVE-2026-105697 ve neden 1.9.0 yetmiyor?
   
4. Sahada neler görülüyor?
   
5. Sunucunuzu nasıl kontrol edersiniz?
   
6. Yama, geçici önlem ve sıkılaştırma
   
7. Kaynaklar
   

Langflow Nedir, Neden Hedefte?

The Hacker News'in aktardığına göre Langflow, geliştiricilerin yapay zeka uygulamaları ve ajan tabanlı iş akışları kurmasını sağlayan açık kaynak bir platform. Langflow'un ana şirketi DataStax, Şubat 2025'te IBM tarafından satın alındı.

Bu tür platformlar saldırganlar için cazip; çünkü genellikle LLM sağlayıcılarının API anahtarlarını, veritabanı bağlantı bilgilerini ve bulut kimlik bilgilerini ortam değişkenlerinde tutuyorlar. Bir Langflow sunucusunu ele geçiren saldırgan, sadece o sunucuya değil, bağlı olduğu tüm servislere de uzanabiliyor.

Açığın Teknik Özeti

• CVE: CVE-2026-105740
  
• CVSS 3.1: 9.9 (Kritik), vektör AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
  
• Zafiyet türü: CWE-78, işletim sistemi komut enjeksiyonu
  
• Etkilenen: Langflow 1.10.3 öncesi (CVE-2026-105740 1.9.0 öncesini, kardeş kayıt CVE-2026-105697 ise 1.10.2 dahil tüm sürümleri etkiliyor)
  
• Danışma notu: GHSA-7w94-79vh-5mr2 (Eylül 2026); CVE kaydı 5 Ekim 2026'da yayımlandı
  

Langflow'un güvenlik bildirimindeki açıklama özetle şöyle: Oturum açmış herhangi bir Langflow kullanıcısı, "Stdio" taşıma yöntemiyle bir MCP sunucusu eklediğinde, kullanıcının girdiği "command" alanı hiçbir doğrulama, izin listesi ya da sandbox olmadan doğrudan bir bash kabuğuna aktarılıyor. Komut, MCP sunucu listesi her yüklendiğinde çalışıyor. Ayrıca "env" alanı üzerinden LD_PRELOAD veya PATH gibi ortam değişkenleri de enjekte edilebiliyor.

Bildirim, açığın sonuçlarını da sıralıyor:

• Tam sunucu ele geçirme: Langflow sürecinin yetkileriyle dosya okuma/yazma ve komut çalıştırma.
  
• Kalıcılık: Zararlı MCP yapılandırması kaydediliyor ve sunucu listesi her yüklendiğinde (başka kullanıcılar ya da yöneticiler MCP ayarları sayfasına girdiğinde bile) yeniden çalışıyor.
  
• Gizlilik: Akış düzenleyicide görünen özel bileşen kodlarının aksine MCP sunucu yapılandırmaları proje ayarlarında saklanıyor ve normal akış incelemesinde görünmüyor.
  
• Yanal hareket: İç ağa, bulut meta veri uç noktalarına ve ortam değişkenlerindeki veritabanı kimlik bilgilerine erişim.
  

Önemli bir not: Açığın yönetici yetkisi gerektirmemesi. Yönetici olmayan sıradan bir hesap da yeterli.



İkinci Açık: CVE-2026-105697 ve Neden 1.9.0 Yetmiyor?

Burada dikkat edilmesi gereken bir incelik var. Langflow'un 28 Eylül tarihli ikinci güvenlik bildirimi (GHSA-w794-rj3p-xv45), aynı MCP stdio mekanizmasındaki sorunun iki adımda kapatıldığını anlatıyor:

• 1.9.0: REST API'deki "MCP sunucusu ekle" yoluna bir komut izin listesi ve argüman/ortam değişkeni doğrulaması eklendi. Bu, CVE-2026-105740'ı kapatıyor.
  
• 1.9.0 - 1.10.2 arası: Komutun nihayet çalıştırıldığı noktada hâlâ doğrulama yoktu ve bash sarmalayıcısı kullanılıyordu. Bu yüzden API'den geçmeyen yapılandırmalar (örneğin bir akışın içine gömülü MCP Tools bileşeni değeri) hâlâ keyfi komut çalıştırabiliyordu.
  
• 1.10.3: Aynı politika API'de, akış çalıştırmada ve süreç başlatılmadan hemen önce uygulanıyor; kabuk kullanımı tamamen kaldırıldı. Sorun burada tamamen kapandı.
  

The Hacker News'e göre bu ikinci kritik açık CVE-2026-105697 (CVSS 9.9) olarak izleniyor ve 1.10.3'te düzeltildi. Kısacası: 1.9.0'a yükseltmek yeterli değil, hedef 1.10.3 veya üstü olmalı.

Bildirimdeki bir diğer kritik ayrıntı: Varsayılan LANGFLOW_AUTO_LOGIN=true ayarında, auto_login uç noktası kimlik bilgisi istemeden token veriyor. Yani varsayılan yapılandırmayla internete açık bir sunucuda bu açık hesap bile gerektirmeden kullanılabiliyor. Langflow, AUTO_LOGIN'in yalnızca geliştirme ortamı için olduğunu belirtiyor.

Sahada Neler Görülüyor?

The Hacker News'in 15 Ekim tarihli haberine göre Previdian'ın tuzak (honeypot) sensörleri, 19 Eylül 2026'dan bu yana 27 farklı IP adresinden 1.423 sömürü girişimi kaydetti; haberin güncellemesinde bu sayı 28 IP'den 1.706'ya çıktı. Previdian'ın 17 Ekim'de güncellenen sayfasında ise toplam 2.065 girişim, 28 benzersiz IP ve 16 ülke görünüyor. Girişimler 11 Ekim'den itibaren belirgin şekilde arttı; o gün 333 girişim kaydedildi.

Previdian'ın kurucusu Ryan Dewhurst'ün The Hacker News'e anlattığı bir saldırı sırası çok öğretici: Saldırganlar önce Langflow sürümünü kontrol etmiş, auto_login uç noktasını denemiş (tuzak sistemde kapalı olduğu için 403 almış), ardından yaygın bir kullanıcı adı ve parolayla başarıyla oturum açmış ve aldıkları token'ı hemen zafiyetli MCP yapılandırma uç noktasına karşı kullanmış.

Yakalanan yüklerden bazıları:

• LANGFLOW_SECRET_KEY ve LANGFLOW_SUPERUSER_PASSWORD dahil ortam değişkenlerini ve Langflow yapılandırmasını çekip dışarıya gönderme girişimleri
  
• Host dosya sistemine erişmeye çalışan Docker komutları
  
• id, whoami gibi basit komut çalıştırma denemeleri
  

The Hacker News'e göre aktivitenin önemli bir kısmı tek bir IP adresinden geliyor ve bu adres Flowise ile Langflow'daki başka açıkları da hedeflemiş. Bu da açıkta kalan yapay zeka platformlarını sistematik olarak tarayan bir aktöre işaret ediyor; amacı şimdilik belirsiz. Açık, Previdian'ın 17 Ekim tarihli sayfasına göre henüz CISA KEV kataloğunda değil.

Haberde paylaşılan göstergeler (log ve güvenlik duvarı aramaları için):

Sunucunuzu Nasıl Kontrol Edersiniz?

Kurulu sürümü kontrol edin (pip ile kurulduysa):

Docker ile çalıştırıyorsanız imaj etiketini kontrol edin:

AUTO_LOGIN ayarını kontrol edin:

Ters proxy veya erişim loglarında MCP sunucu uç noktasına yapılan istekleri ve auto_login denemelerini arayın (yolu kendi ortamınıza göre değiştirin):

Langflow arayüzünde Settings > MCP Servers bölümünü açıp sizin eklemediğiniz bir stdio sunucusu olup olmadığına bakın. Ancak dikkat: Zafiyetli sürümde bu sayfayı açmak, kaydedilmiş zararlı bir yapılandırmayı tetikleyebilir. Şüpheniz varsa önce yükseltin ya da sunucuyu ağdan izole edip yapılandırmayı veritabanından inceleyin.



Yama, Geçici Önlem ve Sıkılaştırma

1. Yükseltin: langflow 1.10.3, langflow-base 0.10.3 ve lfx 1.10.3 veya üstü.

2. Hemen yükseltemiyorsanız: Langflow'un önerdiği geçici önlemler:

• LANGFLOW_AUTO_LOGIN=false ayarlayın.
  
• Langflow'u güvenilmeyen ağlara doğrudan açmayın; VPN ya da kimlik doğrulamalı bir ters proxy arkasına alın.
  
• Langflow hesaplarını yalnızca güvendiğiniz kullanıcılara verin.
  

Previdian ayrıca güçlü ve benzersiz parolalar kullanılmasını, kimlik doğrulama loglarının ve MCP uç noktasına yapılan isteklerin gözden geçirilmesini öneriyor.

3. 1.10.3 sonrası sıkılaştırma: Bildirime göre izin listesi npx ve uvx'in varsayılan olarak herhangi bir paketi çalıştırmasına hâlâ izin veriyor. Çok kullanıcılı ortamlarda şu ayarlar öneriliyor:
1.11.1 ve sonrasında özel kod çalıştırmayı kısıtlayan ayarlar (LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false gibi) MCP stdio sunucularını da yalnızca süper kullanıcılara sınırlıyor.

4. Ele geçirilme şüphesi varsa: Sunucuyu izole edin, logları ve veritabanını koruyun, ortam değişkenlerinde ve yapılandırmada bulunan tüm sırları (LLM API anahtarları, veritabanı parolaları, bulut kimlik bilgileri, LANGFLOW_SECRET_KEY) güvenilir bir ortamdan döndürün ve sunucuyu temiz bir imajdan yeniden kurun.

Yapay zeka platformları hızla üretime alınıyor ama güvenlik yapılandırması çoğu zaman geliştirme ortamındaki haliyle kalıyor. Varsayılan AUTO_LOGIN açık bir Langflow'un internete açılması, bu olayın özeti gibi. Sizin ortamınızda Langflow, Flowise ya da benzeri araçlar kimin sorumluluğunda ve nereden erişilebilir? Yorumlarda tartışalım.

Kaynaklar

• The Hacker News - Langflow's Critical Authenticated RCE Flaw Targeted in 1,423 Honeypot Exploit Attempts (15 Ekim 2026): https://thehackernews.com/2026/10/langfl...d-rce.html
  
• Previdian - CVE-2026-105740 Exploitation Observed: https://previdian.com/CVE-2026-105740
  
• Langflow GitHub Security Advisory - GHSA-w794-rj3p-xv45: https://github.com/langflow-ai/langflow/...-rj3p-xv45
  
• Langflow GitHub Security Advisory - GHSA-7w94-79vh-5mr2: https://github.com/langflow-ai/langflow/...-79vh-5mr2
  

Alıntı:Yasal Uyarı: Bu konu yalnızca bilgilendirme ve savunma amaçlıdır. Paylaşılan kontrol ve tespit adımlarını yalnızca sahibi olduğunuz veya yazılı izinle yönettiğiniz sistemlerde uygulayın. İzinsiz erişim, tarama ve sistemlere müdahale, 5237 sayılı Türk Ceza Kanunu'nun 243-245. maddeleri kapsamında suçtur.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).