Langflow CVE-2026-105740, kayıtlı kullanıcıların stdio MCP sunucuları üzerinden rastgele bash komutu çalıştırmasına izin veriyordu

CVE-2026-105740 olarak takip edilen ve CVSS puanı 9.9 olan kritik bir Langflow açığı, bir örnekte kimliği doğrulanmış herhangi bir kullanıcının komut dizisinin doğrudan bash -c'ye iletildiği bir stdio MCP sunucusu kaydedebilmesine olanak tanıyordu. dev.io'daki teknik bir yazıya göre açığın olağandışı bir tetikleyicisi de vardı: Yapılandırılmış sunucuları sadece listelemek, payload'ı çalıştırmak için yeterliydi.

Açık nasıl çalışıyordu

Yazı, GHSA-7w94-79vh-5mr2 danışma belgesine atıf yaparak, Langflow API'sinin oturum açmış herhangi bir kullanıcından — komut, argümanlar, ortam değişkenleri, URL ve header'lar dahil — eksiksiz bir MCP sunucu yapılandırması kabul ettiğini ve komutların bir izin listesi (allowlist) veya engelleme listesi (blocklist) ile doğrulanmadığını açıklıyor.

Komut, -c bayrağıyla bir shell başlatılarak ve kullanıcının dizesi, bir hata mesajına zincirlenen bir exec çağrısına sarılarak başlatılıyordu. Yazı, bu sarmalayıcının neden yanıltıcı olduğunu adım adım anlatıyor. exec, shell'i hedef programla değiştirdiği için zincirlenen hata işleyicisi hiçbir zaman çalışmıyor. Buna karşılık komut yerine koyma (command substitution), exec devralmadan önce tetiklendiğinden $(...) biçimindeki payload'lar normal şekilde çalışıyor.

Kullanıcı tarafından kontrol edilen ortam sözlüğü, child sürecin ortamıyla birleştiriliyordu; yazar bunu ayrı bir enjeksiyon kanalı olarak değerlendiriyor: sağlanan bir PATH, gerçekte hangi binary'nin çalışacağını belirleyebiliyor ve LD_PRELOAD, Linux'ta dinamik bağlı her programı etkileyebiliyor.

Yazıya göre tüm bunlar ikincil. Asıl kusur, platformun hangi kodu çalıştıracağına sıradan bir kullanıcının karar vermesi. Komut yerine koymayı mükemmel şekilde reddeden bir parser bile, doğrudan komut alanına yazılan bir " indir ve çalıştır" hattını çalıştırmaya devam ederdi.

Tetikleyici de dikkat çekmeyi hak ediyor: çalıştırma, birinin sunucuyu çağırmasını gerektirmiyordu. Sunucu listeleme uç noktası /api/v2/mcp/servers'a action_count parametresiyle yapılan bir GET isteği komutu başlatmak için yeterliydi.

Sürümler ve gözlemlenen istismar

Danışma belgesine göre 1.8.3 sürümü etkileniyor ve düzeltme 1.9.0'da yayınlandı. Yazıda atıf yapılan bir triage notu da 1.10.3'ü listeliyor; bu yüzden yazar, iki kaynağın çelişkisi göz önüne alındığında ve kendi dağıtımınızla doğrulamaya değer olsa da, her iki okumada da güvende olmak için 1.10.3 veya sonraki bir sürümü çalıştırmayı öneriyor.

Honeypot'lar halihazırda faaliyet gördü. Yazı, binlerce düzeyinde istismar denemesi raporlarına atıf yapıyor; bunlardan biri, metodolojisini belgeleyen ve 19 Eylül'den bu yana 2.023 deneme sayan bir sensör.

Kalıcı çözüm: komut dizileri değil, sunucu kimlikleri

Yazıda önerilen desen, MCP başlatmalarını diğer herhangi bir bağımlılık gibi ele alıyor: kullanıcılar bir sunucu kimliği (ID) seçiyor ve asla bir komut iletmiyor. Her kimlik, image derleme zamanında sürümü sabitlenmiş, gözden geçirilmiş kesin bir argv ile eşleşiyor ve shell olmadan çalıştırılıyor. Child ortamı, bir izin listesi ve yönetici tarafından belirlenen değerlerden oluşturuluyor, asla istekten birleştirilmiyor. Yeni bir kimlik kaydetmek, denetim izi olan bir yönetici eylemi haline geliyor.

Yazı, Langflow'da kötü niyetli yapılandırmanın proje ayarlarının içinde kalıcı hale geldiğini — akışların (flow) gözden geçirilmesinin hiç incelemediği bir konum — ekliyor.

Yamalanmış bir makinede aynı risk

Yazar daha sonra Claude Code çalışan temiz bir geliştirme makinesini denetledi ve hiçbir açık olmadan riski buldu: npx @playwrigth/mcp@latest çağıran yerel kapsamlı (local-scope) bir sunucu kaydı — playwright'ın harfleri yer değiştirmiş bir yazım hatası olup 404 ve kapsam bulunamadı hatası dönen bir npm kapsamına işaret ediyordu. Herkes npm'de o organizasyonu oluşturup paketi yayımlayabilir ve kayıt @latest'i çözdüğü için, bir sonraki oturum başlangıcı o isim altında en son yayımlanan her neyse onu çalıştıracaktı.

Kayıt hiç çalışmamıştı ve başarısız bir MCP bağlantısı, engelleyici bir hata olmak yerine yalnızca bir log satırı; yazım hatasının fark edilmeden kalmasının nedeni de buydu. Çözüm, kaydı kaldırıp doğru sunucuyu sürümü sabitlenmiş şekilde yeniden eklemek.

Yazı ayrıca onay istemlerinin tam bir savunma olmadığı konusunda uyarıyor. Claude Code, etkileşimli oturumlarda proje kapsamlı sunucuları kullanmadan önce soruyor; ancak headless claude -p çalıştırmaları, Agent SDK oturumları ve bazı bulut oturumları bunları sormadan yüklüyor — yazım hatasının bulunduğu yerel kapsamlı kayıtlarda ise hiç onay adımı yok.

Neden önemli

Stdio transport üzerindeki bir MCP sunucusu, sonuçta ajanınız tarafından kendi yetkilerinizle çalıştırılan bir komuttur ve bu olay, bu riskin her iki yönünü de gösteriyor. Langflow, kullanıcılar komut dizileri tanımlayabildiği anda bir yapılandırma API'sinin ne kadar hızlı uzaktan kod çalıştırmaya dönüştüğünü; yazım hatası kapsamı bulgusuysa, tamamen yamalanmış ve ele geçirilmemiş bir makinenin bile, bir npm kaydından uzakta, bir sonraki başlangıçta saldırgan kodunu çalıştırabileceğini ortaya koyuyor. Ajanlı araçları benimseyen ekipler için sunucu komutlarını gözden geçirilmiş tanımlara sabitlemek, ajanların okuduğu yapılandırma dosyalarını denetlemek ve referans verilen paketlerin gerçekten var olduğunu doğrulamak artık isteğe bağlı bir sertleştirme değil, temel hijyen.