Zero-Day Analizi: n8n-mcp Authenticated SSRF Zafiyeti (GHSA-4ggg-h7ph-26qr)
Disclosed: 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.
Etki Alanı ve Saldırı Senaryoları
Bulut ortamlarında (Cloud) veya kurumsal ağlarda bu tip bir SSRF açığı son derece kritiktir:
- Cloud Metadata Sızıntısı: Saldırgan, URL'i manipüle ederek
169.254.169.254adresine istekte bulunabilir ve AWS (IMDS), GCP, Azure, Alibaba gibi bulut sunucularına ait geçici token ve kimlik bilgilerini ele geçirebilir. - İç Ağ Taraması: Zafiyet kullanılarak gizli kalması gereken yerel ağdaki (RFC1918) servisler, API uç noktaları ve veritabanı portları taranabilir.
- Veri İfşası: Zafiyetli sunucunun yetkili olduğu iç kaynaklardaki özel müşteri verilerine veya kaynak kodlara doğrudan okuma işlemi uygulanabilir.
Not: Single-tenant stdio yapılandırmaları veya multi-tenant özellikleri kapalı olan HTTP sunucuları bu açıktan etkilenmemektedir.
Çözüm Önerileri ve İyileştirme (Remediation)
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.