n8n-mcp Authenticated SSRF: Açıklama ve Azaltım (CVE-2026-39974)
Yayımlandı: 2026-04-09
Giriş
Eresus Security Araştırma Ekibimizden (@ibrahmsql), popüler iş akışı otomasyon aracı n8n'in Model Context Protocol uzantısı olan n8n-mcp üzerinde yetkilendirilmiş (Authenticated) bir SSRF (Server-Side Request Forgery) zafiyeti keşfetmiş ve yetkililere bildirmiştir. Bu güvenlik açığı GitHub Security Advisory üzerinde GHSA-4ggg-h7ph-26qr koduyla takip edilmektedir.
Bu zafiyet, özellikle HTTP tabanlı "multi-tenant" (çoklu kiracı) yapılarda ortaya çıkarak, saldırganlara sunucunun bulunduğu iç ağa erişim sağlama imkanı tanımaktadır.
Zafiyetin Detayları
Multi-tenant HTTP kurulumlarında n8n-mcp, hedef n8n örneğinin (instance) nerede olduğunu belirlemek için x-n8n-url ve x-n8n-key request header'larını (HTTP başlıklarını) kullanır.
Ancak 2.47.3 ve öncesi versiyonlarda x-n8n-url başlığı üzerinde herhangi bir URL doğrulaması yapılmamaktaydı. Geçerli bir AUTH_TOKEN'a sahip bir kullanıcı, bu header'ı manipüle ederek uygulamanın istenilen herhangi bir adrese HTTP isteği atmasını sağlayabilmekteydi.
Sunucu tarafından atılan bu dış (veya iç) isteklerin yanıtları, JSON-RPC aracılığıyla tekrar saldırgana yansıtıldığı için, saldırgan sunucunun erişiminin olduğu herhangi bir adresin veya dosyanın içeriğini okuyabiliyordu.
Severity ve etki kapsamı
GitHub Advisory Database, CVE-2026-39974 için High ve CVSS v3.1 8.5 bildiriyor. Zafiyet n8n-mcp 2.47.3 ve önceki sürümleri etkiliyor; 2.47.4 yamalı sürüm. Bu seviye her kurulumun aynı ölçüde açık olduğu anlamına gelmez: advisory, geçerli AUTH_TOKEN erişimi olan multi-tenant HTTP kurulumlarını başlıca risk olarak tanımlar. Single-tenant stdio kurulumları ve multi-tenant header kullanmayan HTTP kurulumları kapsam dışıdır.
SSRF sunucunun keyfî URL’lere istek göndermesine ve yanıt gövdelerini çağırana döndürmesine yol açabilir. Cloud metadata veya iç verinin açığa çıkıp çıkmaması sunucunun ağ erişimine ve çağıranın kimlik bilgilerine bağlıdır; advisory tüm etkilenen kurulumlarda kimlik bilgilerinin açığa çıktığını kanıtlamaz.
Çözüm ve Azaltım
Araştırma ekibimizin raporlaması üzerine, kütüphanenin geliştiricileri hızlıca aksiyon alarak URL giriş noktalarına doğrulama eklemiş ve URL'leri normalize etmiştir.
1. Hemen Güncelleyin (Önerilen)
Zafiyet n8n-mcp 2.47.4 versiyonunda kalıcı olarak çözülmüştür. Bütün kullanıcıların acilen sistemlerini bu versiyona veya daha üstüne taşımaları gerekmektedir. Güncelleme işlemi hiçbir yapılandırma değişikliği gerektirmemektedir.
2. Ağ Katmanı Engellemesi (Geçici Çözüm)
Hemen güncelleme yapılamayacak durumlarda, konteyner veya sunucu üzerinden yapılacak dış bağlantıları kısıtlayın. N8n-mcp konteynerinden aşağıda belirtilen özel IP bloklarına olan istekleri "egress filtering" ile engelleyin:
169.254.0.0/16(Cloud Metadata)10.0.0.0/8172.16.0.0/12192.168.0.0/16
3. Multi-Tenant Özelliklerini Kapatın
Sisteminizin hiyerarşisi her istek başına instance-URL değişimine izin verecek türden değilse, ENABLE_MULTI_TENANT değişkenini devre dışı bırakın. Ek güvenlik olarak, NGINX / Traefik gibi bir reverse proxy üzerinde x-n8n-url header kullanımını drop/silme işlemlerine tabii tutun.
Sonuç
Bulduğumuz bu zafiyet, karmaşık ve multi-tenant yapılı entegrasyon sistemlerinde gözden kaçabilen dinamik URL okumalarının yarattığı devasa yüzey tehlikelerini açıkça gözler önüne seriyor. Raporumuz üzerine son derece profesyonel bir hızda aksiyon alıp açığı kapatan n8n-mcp geliştirici ekibine teşekkür ederiz.
İlgili Hizmetler