Zero-Day Analizi: n8n-mcp Authenticated SSRF Zafiyeti (GHSA-4ggg-h7ph-26qr)

Giriş

Eresus Security Araştırma Ekibinden Yiğit İbrahim Sağlam (@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.254 adresine 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/8
172.16.0.0/12
192.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.

Eresus Security'nin Zero-Day bulguları, DevSecOps süreçleri ve gelişmiş Sızma Testi yetenekleri hakkında bilgilenmeye devam etmek için blogumuzu takipte kalın.

Saha Kontrol Notları

Bu başlık pratikte yalnızca teorik risk olarak ele alınmamalıdır. AI sistemlerinde zafiyetin etkisi, modelin bulunduğu ortam ve bağlı olduğu veri kaynaklarıyla birlikte değişir.

İnceleme sırasında şu kanıtlar toplanmalıdır:

Model veya agent hangi ortamda çalışıyor?
Hangi kullanıcı veya servis hesabı kullanılıyor?
Hassas veri kaynakları ayrı etiketlenmiş mi?
Model dosyası veya artefact kaynağı doğrulanmış mı?
Yükleme anında kod çalıştırma riski var mı?
Retrieval sonuçları kullanıcı yetkisine göre filtreleniyor mu?
Tool çağrıları ayrı loglanıyor mu?
Kritik aksiyonlarda onay mekanizması var mı?
Test ortamı production verisinden ayrılmış mı?
Olay halinde hangi loglardan geri dönüş yapılacak?

Uygulama Kontrol Listesi

Güvenilmeyen model dosyaları izole ortamda açılmalı.
Model registry erişimi minimum yetkiyle çalışmalı.
Hash, imza veya provenance bilgisi tutulmalı.
Agent tool izinleri görev bazlı ayrılmalı.
Memory ve retrieval kaynakları ayrı güven sınırı olarak ele alınmalı.
Prompt testleri runtime aksiyon testleriyle desteklenmeli.
Her bulgu iş etkisiyle birlikte raporlanmalı.

Karar Noktası

Bu risk müşteri verisine, üretim API’sine, geliştirici ortamına veya model yükleme hattına dokunuyorsa bekletilmemelidir. Eresus Security bu tip incelemelerde dosya, runtime, tool ve veri sınırını birlikte test ederek gerçek saldırı yolunu kanıtlar.

Operasyonel İnceleme Checklisti

Model veya agent kaynağı doğrulandı mı?
Tool izinleri minimum yetkiyle mi tanımlandı?
Retrieval sonucu kullanıcı yetkisine göre filtreleniyor mu?
Memory kalıcı talimat riskine karşı incelendi mi?
Model artefact hash veya imza ile takip ediliyor mu?
Yükleme işlemi sandbox içinde test edildi mi?
Prompt testi runtime aksiyon testiyle desteklendi mi?
MCP veya plugin server listesi çıkarıldı mı?
Agent production API çağırıyorsa onay var mı?
Veri sızıntısı senaryosu kontrollü denendi mi?
Kapsam net yazıldı mı?
Etkilenen varlık sahibi belli mi?
Test ortamı production etkisinden ayrıldı mı?
Kullanıcı rolleri doğru temsil ediliyor mu?
Hassas veri sınıfı tanımlandı mı?
Yetki sınırı teknik olarak doğrulandı mı?
Log kaynağı ve saklama süresi belli mi?
Bulgu tekrar üretilebilir kanıtla destekleniyor mu?
İş etkisi teknik etkiden ayrı açıklandı mı?
Düzeltme sahibi belirlendi mi?
Retest kriteri yazıldı mı?
Benzer risklerin nerelerde tekrar edebileceği kontrol edildi mi?
Monitoring veya alert tarafında görünürlük var mı?
Olay müdahale adımı gerekiyorsa planlandı mı?
Yönetim özeti teknik jargona boğulmadan hazırlanabilir mi?

Sonraki Teknik Adım

Bu checklist tamamlandıktan sonra bulgular önem sırasına göre backlog’a taşınmalı, kritik riskler için retest planı çıkarılmalı ve ilgili servis/hub sayfasına iç bağlantı verilmelidir. Eresus Security bu aşamada kapsam netleştirme, kanıt üretme ve remediation önceliklendirme konusunda teknik ekiplerle birlikte çalışır.

Ek Kontrol Soruları

Bu risk hangi varlıkları etkiliyor?
Hangi kullanıcı rolleri bu akışa erişebiliyor?
Aynı sorun başka endpoint veya entegrasyonda tekrar ediyor mu?
Bulgunun müşteri verisine etkisi var mı?
Loglardan olayın izi sürülebiliyor mu?
Düzeltme sonrası retest nasıl yapılacak?
Geçici önlem ile kalıcı çözüm ayrıldı mı?
İş etkisi teknik ekibin dışında da anlaşılır mı?
Benzer hata için önleyici kontrol eklenebilir mi?
Ekip bu kontrolü release sürecine bağlayabilir mi?
Gerekirse bağımsız doğrulama için hangi kanıtlar hazırlanmalı?
Sonraki sprintte hangi iç bağlantı ve servis sayfası desteklemeli?