Public GitHub commit’lerinde açıkta kalan n8n API anahtarları, araştırmacıların test ettiği erişilebilir sistemlerin yüzde 36’sında doğrudan yetkili erişim sağladı. İnceleme, 2025 Nisan’dan bu yana paylaşılan commit’lerde 4.576 benzersiz token ve bunlarla eşleşen 1.255 alan adı buldu; test sırasında erişilebilir durumda olan 896 n8n örneğinin 321’i en az bir sızmış anahtarı kabul etti.
Bulgu yalnızca n8n ile sınırlı değil. Platform, şirketlerin veritabanları, kaynak kod depoları, bulut ortamları, yapay zekâ servisleri, müşteri destek sistemleri ve iç iş akışları arasında bağlantı kurmak için kullanılıyor. Bu nedenle yetkili bir n8n anahtarı, iş akışı tanımlarını, yürütme kayıtlarını ve kimi kurulumlarda saklanan diğer kimlik bilgilerini açığa çıkarabiliyor.
Public GitHub commit’lerinden 4.576 token toplandı
Yapılan son analizde araştırmacılar, GitGuardian Public Monitoring’in açık kimlik bilgisi taramalarını kullandı ve public GitHub commit’lerinde yer alan n8n API token’larını tek tek topladı. Elde edilen veri setinde 5.469 commit içinde gömülü token bulundu. Bunlara bağlı 1.255 hostname çıkarıldı ve bunların 896’sına test anında açık internet üzerinden erişilebildi.
Bu 896 örneğin 321’i, gönderilen en az bir sızmış token’ı kabul etti. Araştırmada kullanılan oranlara göre bu, erişilebilen sistemlerin yaklaşık yüzde 36’sına ve commit’lerde bulunan tüm hostname’lerin yaklaşık yüzde 26’sına karşılık geliyor. Aynı tarama, n8n Model Context Protocol için kullanılan anahtarları da kapsadı. Aynı commit kümesinde bulunan 372 MCP token’ından yalnızca yedisi test sırasında hâlâ geçerliydi; bu da yaklaşık yüzde 2’lik bir orana işaret ediyor.
Hostname ile token’ın çoğu zaman aynı commit içinde yer alması, araştırmacıların ayrıca bir altyapı keşif adımı yürütmesini gereksiz kıldı. .env dosyaları, Claude Code yapılandırma dosyaları ve bazı betiklerde hem n8n adresi hem de API anahtarı yan yana duruyordu. Örnekler arasında N8N_URL ile N8N_API_KEY çiftleri, .claude/settings.json içindeki onaylı curl komutları ve N8N_MCP_URL, N8N_WEBHOOK_BASE_URL gibi değişken adları yer aldı.
Claude Code’un izin verdiği komutlar .claude/settings.json ve .claude/settings.local.json içinde saklanabiliyor. Kullanıcılar n8n ile çalışacak şekilde ayar yaptığında, hem instance URL’sini hem de API anahtarını doğrudan onaylı bir curl komutuna yazabiliyor. Bu dosyalar, geliştiricilerin .env dosyaları için uyguladığı .gitignore korumaları olmadan depoya girebiliyor.
Aynı hostname ve token eşleşmesi, process.env.N8N_URL ile os.getenv(“N8N_HOST”, “…”) gibi başka değişken adları altında da görüldü. Araştırmacılar, hostname çoğu zaman anahtarla aynı commit içinde bulunduğu için ayrıca bir altyapı keşfi yapmak zorunda kalmadı.
Eski anahtarlar çoğu zaman son kullanma tarihi taşımıyor
n8n API anahtarları imzalı JSON Web Token olarak çalışıyor ve içinde aud: public-api alanı bulunuyor. Ancak eski anahtarların önemli bir kısmında son kullanım tarihini tanımlayan exp alanı yer almıyor. Token’ın ne zaman üretildiğini ise iat alanı gösteriyor.
n8n, Şubat 2025’te yayımlanan 1.78.0 sürümüyle 30 günlük varsayılan süre sınırı getirdi. Buna karşın araştırma sırasında bulunan birçok anahtarın, son kullanma tarihi belirlenmeden üretildiği görüldü. Bu nedenle aylar önce GitHub’a düşen bir anahtar, sahibi açıkça iptal edene ya da silene kadar kullanılabilir kalabiliyor. Token’ın geçerliliği yalnızca imzaya bakılarak anlaşılmıyor; anahtarın n8n veritabanında hâlâ kayıtlı olması da gerekiyor.
Bir token’ın kabul edilip edilmediğini sınamak için API’ye tek bir okuma isteği göndermek yeterli oluyor. Araştırmacılar bunu X-N8N-API-KEY başlığında token taşıyan bir GET /api/v1/workflows isteğiyle denedi. Sunucudan gelen 200 yanıtı token’ın geçerli olduğunu doğrularken, 401 yanıtı anahtarın geçersiz olduğunu, veritabanından silindiğini ya da imza doğrulamasını geçemediğini gösteriyor. 404 ise bazı kurulumlarda herkese açık API’nin kapalı olabileceğine işaret ediyor.
Araştırmacılar, tehdit yüzeyinin genişliğini değerlendirirken n8n’nin sık maruz kaldığı güvenlik sorunlarını da not etti. Shodan üzerinde 100 binden fazla örnek görünürken, Ocak 2026’dan bu yana 50’den fazla güvenlik uyarısı yayımlandı. 31 Mart 2026 itibarıyla taranan sistemlerin yüzde 58’i, en az bir bilinen güvenlik uyarısından etkilenen bir sürüm çalıştırıyordu. Yakın dönemdeki bazı CVE’ler, yürütme sandbox’ından kaçış ve ana makinedeki dosya sistemine okuma-yazma yetkisi elde etme riski taşıyordu.
Bu açıklardan biri olan CVE-2025-68613, 9.9 CVSS puanlı bir expression injection açığı olarak 11 Mart 2026’da ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı’nın Known Exploited Vulnerabilities kataloğuna eklendi. Bu adım, açığın sahada istismar edildiğini doğruladı.
Sızmış API anahtarları ise ayrı bir risk oluşturuyor. Geçerli bir kimlik bilgisi erişim veriyorsa, saldırganın ayrıca bir n8n açığı işletmesi gerekmiyor. Yalnızca anahtarın kabul edilmesi, instance’a yetkili giriş için yeterli olabiliyor.
Ardından araştırmacılar, commit’lerde bulunan aynı kümeyi n8n Model Context Protocol API anahtarları için de taradı. MCP token’ları, yapay zekâ asistanlarının Model Context Protocol üzerinden n8n iş akışlarını çağırmasına izin veriyor ve REST API’ye göre daha yeni bir sızıntı yüzeyi oluşturuyor. Bulunan 372 MCP token’ından yedisi test sırasında hâlâ geçerliydi.
Yetkili bir token neler açığa çıkarabiliyor
n8n API token’ı, oluşturan kullanıcının yetkileriyle çalışıyor. Araştırmada açıkta görünen anahtarların önemli bir bölümü, kurulumları yapan ve anahtarları commit eden kişiler nedeniyle instance sahibi ya da yönetici hesaplarına ait görünüyordu.
Hesabın rolüne göre kamuya açık REST API farklı veriler döndürebiliyor. GET /api/v1/users kullanıcı adlarını, e-posta adreslerini, hesap oluşturma tarihlerini ve bekleyen davetleri gösterebiliyor. GET /api/v1/workflows ise düğüm yapılandırmalarını, Code düğümlerindeki JavaScript veya Python kodunu, SQL sorgularını ve iş akışı parametrelerine gömülmüş gizli değerleri tam haliyle döndürüyor. GET /api/v1/credentials kimlik bilgilerinin adını, türünü ve paylaşım bilgisini veriyor; ancak değerlerin kendisini göstermiyor. GET /api/v1/executions geçmişi sunuyor, ?includeData=true parametresi ise her çalıştırmanın tam giriş ve çıkış yükünü getirebiliyor. GET /api/v1/data-tables yetkili kullanıcının görebildiği tablolardaki satırları, GET /api/v1/variables ise değişken adlarını ve içeriklerini dönüyor.
İş akışı tanımları, API’nin tam düğüm yapılandırmasını döndürmesi nedeniyle en hızlı sızıntıyı yaratıyor. Bir geliştirici API anahtarını n8n’nin credential deposunu kullanmak yerine doğrudan bir düğüm parametresine yazdıysa, değer açık metin olarak görülebiliyor. Credential uç noktası saklanan gizli değeri döndürmüyor; buna karşın araştırmacıların kontrollü testleri, bir saldırganın workflow oluşturup çalıştırma yetkisi varsa saklanan credential’ı referans gösterebildiğini ortaya koydu.
n8n’nin audit uç noktası da yetkili kullanıcıya instance için bir güvenlik raporu çıkarabiliyor. Araştırmacılar, bu raporun olası SQL injection yüzeylerini, dosya sistemi erişimi olan düğümleri, korunmasız webhook’ları, çalışan n8n sürümünü, kullanılmayan credential’ları, yüksek riskli ya da topluluk tarafından yüklenen düğümleri, etkin güvenlik özelliklerini, allowlist ve blocklist ayarlarını ve telemetri durumunu gösterebildiğini belirtti. Meşru bir yönetici için bunlar güvenlik incelemesini desteklerken, sızmış ayrıcalıklı bir token taşıyan saldırgan için en umut verici saldırı yollarının önceliklendirilmiş haritasına dönüşebiliyor.
Dört teknik, kontrollü ortamda yeniden üretildi
GitGuardian, bu teknikleri açık üçüncü taraf sistemlerde çalıştırmadı. Bunun yerine araştırma için özel olarak kurulan kontrollü bir n8n dağıtımında yeniden üretti. Test iş akışı üç bilinçli zayıflık içeriyordu: bir web formu gönderimleri yetkili iş akışlarının erişebildiği bir data table’a yazıyordu; bir OpenAI düğümü her girdiyi saklanan bir credential nesnesiyle işliyordu; bir HTTP Request düğümü ise çıktıyı doğrudan düğüm parametrelerine yazılmış bir token ile GitHub’a aktarıyordu.
İlk teknik, instance’ı sorgulamakla yetindi. GET /api/v1/users dört hesap döndürdü: instance sahibi, iki aktif kullanıcı ve bir bekleyen kayıt. GET /api/v1/workflows dokuz tam iş akışı tanımı verdi. Hedef iş akışında bir HTTP Request düğümünün parametreleri içinde GitHub token’ı açık metin olarak yer alıyordu.
İkinci teknikte araştırmacılar, saklanan bir OpenAI credential’ını kullandı. GET /api/v1/credentials listesinde “OpenAI account” adlı bir nesne görüldü. Uç nokta yalnızca ad, tür ve kimlik döndürüyor, API anahtarını göstermiyordu. Ardından Schedule trigger ve kimliğine referans veren OpenAI düğümünden oluşan bir workflow kuruldu ve etkinleştirildi. Schedule trigger yaklaşık 10 saniye sonra otomatik çalıştı; hemen ardından GET /api/v1/executions?includeData=true çağrısı yapıldı ve OpenAI yanıtı açık metin olarak alındı. Araştırmacılar, değeri hiç görmeden instance’ın saklı credential’ı üzerinden rastgele OpenAI istemleri çalıştırabildi.
Üçüncü teknik veri tablosunu okudu. Aynı zamanlama hilesiyle kurulan workflow, bir Data Table düğümünü tüm satırları çekmek üzere yapılandırdı. GET /api/v1/executions?includeData=true birkaç saniye sonra yürütme kaydını döndürdü ve her satır açık metin olarak göründü. Dört satır dışarı aktarıldı; bunlar isimleri, e-posta adreslerini, form yanıtlarını ve işlem durumlarını içeriyordu. Workflow daha sonra silindi.
Dördüncü teknik, saklanan OpenAI credential’ının ham değerine ulaştı. Araştırmacılar önce bir HTTP dinleyicisi kurdu, ardından Schedule trigger ve HTTP Request düğümünden oluşan bir workflow oluşturdu. Burada kritik nokta, HTTP Request düğümünün saklanan bir n8n credential’ını kimlik doğrulama yöntemi olarak kullanırken isteği herhangi bir URL’ye gönderebilmesiydi. Düğüm, saklanan OpenAI credential’ını kullanacak şekilde ayarlandı ve dinleyiciye yönlendirildi. Workflow tetiklendiğinde n8n, credential değerini giden Authorization başlığında Bearer token olarak ekledi. Dinleyici, ham API anahtarını etkinleştirmeden saniyeler sonra yakaladı. Workflow yine silindi.
Bu dört teknik birlikte, sızmış bir n8n token’ından meşru platform işlevleri üzerinden daha geniş kimlik bilgisi ve veri sızıntısına nasıl geçilebildiğini gösterdi. Saldırgan önce kullanıcıları, workflow’ları ve güvenlik yapılandırmasını sayabiliyor. Ardından saklanan credential nesnelerini ve açıkta yazılmış sırları ayıklayabiliyor. Saklı kimlik bilgilerini değerlerini görmeden kullanabiliyor. İş akışlarının erişebildiği verileri okuyabiliyor. Son aşamada ise n8n’nin saklı bir credential’ı saldırganın kontrolündeki altyapıya göndermesini sağlayabiliyor.
Malicious workflow silindiğinde, ilgili yürütme kayıtları da arayüzden kayboldu. Bu durum, savunucuların n8n içinde inceleyeceği kanıtları sınırlayabiliyor.
Gerçek iş akışlarında benzer açıklar görüldü
Kontrollü demo yalnızca teorik bir kurulumdan ibaret değildi. Araştırma sırasında gerçek n8n örneklerinde de benzer zayıf noktalar bulundu. Bir iş akışı, kendi tanımlarını otomatik olarak herkese açık bir GitHub deposuna yedekliyordu. SSH dağıtım anahtarı düğümlerden birine doğrudan gömülmüştü.
Depodaki Git geçmişi, her iş akışının önceki sürümlerini de saklıyordu ve SSH anahtarı geçerliliğini koruyordu. Böylece iş akışı, her çalıştığında kendi hassas yapılandırmasını ve kimlik bilgilerini yayınlayan bir mekanizmaya dönüşüyordu.
Araştırmacılar, sorumlu bildirim için yedi kurumla iletişime geçti. Bunların üçü toplamda yaklaşık 100 etkilenen örnekle ilişkili barındırma sağlayıcılarıydı; dördü ise bireysel şirketlerdi. Sağlayıcılardan biri yanıt vermedi. Dört şirketten üçü de dönüş yapmadı. Bir şirket bug bounty programı işletiyordu; raporu aldığını bildirdi, 1.200 dolar ödül verdi ve kimlik bilgisini hemen iptal etti. Araştırmacılar bu hızlı yanıt ve düzeltmeyi istisna olarak aktardı.
GitGuardian, araştırma sırasında n8n’ye de birkaç doğrudan bildirim yaptı. Şirket raporları aldığını, sorunlardan haberdar olduğunu ve bunları ele almayı planladığını söyledi; ardından bildirimleri kapattı. Yayın anında GitGuardian, ilgili düzeltmelerin gerçekten yayımlandığını bağımsız olarak doğrulamadığını belirtti.
Yaklaşık yüzde 30’luk bir kesim, etkilenen 321 örneğin n8n.cloud ya da benzeri yönetilen hizmetlerde barındırıldığını gösterdi. GitGuardian Public Monitoring, açıkta kalan n8n API token’larını zaten tespit ediyor ve şirketin Good Samaritan bildirim programı üzerinden etkilenen geliştiricilere haber veriyor. Çalışmanın ardından şirket, n8n API anahtarı dedektörünü ve geçerlilik kontrollerini de güncelledi.
Bir n8n token’ının sızması tek başına bir kimlik bilgisi sızıntısı olarak kalmıyor. Yetkili bir token, iş akışı tanımlarını, açıkta yazılmış sırları, yürütme verilerini ve iç tabloları açabiliyor. Saklanan kimlik bilgilerini kullandırabiliyor ya da bunları dış bir uç noktaya taşıyan bir workflow ile değerlerini çıkarabiliyor. Kontrollü testlerde bunun için CVE istismarı ya da özel bir araç gerekmedi; birkaç standart HTTP isteği, açıkta bir token’dan hassas veriye ve ardından aşağı yönlü kimlik bilgisi erişimine geçmek için yeterli oldu.
Kuruluşlar, açığa çıkan n8n token’ını iptal etmekle yetinmeyip hesabın erişebildiği workflow’ları, verileri ve bağlı kimlik bilgilerini belirlemeli. Araştırmada, n8n’nin kendi içinde kalan kanıtların workflow ve yürütme kayıtları silindiğinde sınırlı olabildiği de görüldü.
Guillaume Valadon, GitGuardian’da Staff Cybersecurity Researcher olarak çalışıyor. Şirket kendisini, kodların, makinelerin ve yapay zekâ ajanlarının sistemlere güvenilir kimliklerle erişmesini sağlayan secrets visibility and intelligence platform olarak tanımlıyor. GitGuardian, 600.000’den fazla geliştirici ve kurum tarafından kullanıldığını; aralarında Snowflake, ING, BASF, Datadog, Qlik, Euronext ve Orange’ın da bulunduğunu belirtiyor.