n8n iş akışı otomasyon platformunda keşfedilen kritik bir güvenlik açığı, Enterprise kullanıcılarını tehdit ediyor. CVE-2026-59208 olarak izlenen bu zafiyet, token exchange özelliğinde kimlik bağlama (identity binding) hatasından kaynaklanıyor. Saldırganlar, farklı bir token sağlayıcısından (issuer) aldıkları geçerli bir JWT token ile, hedef kullanıcının şifresini bilmeden onun hesabına giriş yapabiliyor. n8n, 24 Haziran'da yayınladığı güncelleme ile bu açığı kapattı.
Token exchange, n8n'in OEM ortakları için sunduğu bir Enterprise özelliği. RFC 8693 standardını uygulayan bu mekanizma, ürünü kendi sistemlerine gömen ortakların kullanıcılarına ikinci bir giriş ekranı göstermeden oturum açma imkanı sağlıyor. Ortak, kısa ömürlü bir JWT token'ı kendi anahtarıyla imzalıyor, n8n bu token'ı yapılandırılmış genel anahtarla doğruluyor ve token'daki iddiaları (claims) yerel bir kullanıcı hesabına eşliyor. Güvenilen anahtarlar N8N_TOKEN_EXCHANGE_TRUSTED_KEYS ortam değişkeninde tutuluyor ve özellik hala önizleme aşamasında.
Açığın temelinde, n8n'in JWT token'ı doğrularken yalnızca 'sub' (subject) alanına bakması, 'iss' (issuer) alanını yok sayması yatıyor. RFC 7519'a göre 'sub' değeri, issuer içinde benzersiz olmalıdır; ancak farklı issuer'lar aynı 'sub' değerini kullanabilir. n8n, token'ı sadece 'sub' ile eşleştirdiği için, A issuer'ından gelen ve B issuer'ındaki bir kullanıcıya ait 'sub' değerine sahip bir token, A'daki kullanıcıyı B'deki hesaba giriş yapmış gibi gösteriyor. Bu, iki farklı issuer'ın aynı kullanıcı tanımlayıcısını kullanması durumunda ciddi bir güvenlik ihlaline yol açıyor.
Bu güvenlik açığı yalnızca token exchange özelliği etkinleştirilmiş ve en az iki harici issuer güvenilen anahtarlar listesine eklenmiş Enterprise kurulumlarını etkiliyor. n8n, diğer özelliklerin etkilenmediğini belirtiyor. Token exchange yalnızca Enterprise sürümünde ve önizleme aşamasında olduğundan, risk altındaki kitle sınırlı: OEM dağıtımları ve ikinci bir issuer'ı destekleyen yapılandırmalar. Ancak, saldırganın geçerli bir token'ı nasıl elde edeceği konusunda belirsizlik var. GitHub'ın CVSS 4.0 vektörü saldırı gereksinimlerini 'mevcut' olarak işaretliyor ve 7.6 puan veriyor (yüksek). NVD ise CVSS 3.1 üzerinden 6.8 puanla (orta) değerlendiriyor.
n8n, bu açığı 24 Haziran'da 2.27.4 ve 2.28.1 sürümleriyle kapattı. Tüm 2.27.4 öncesi sürümler ve 2.28.0 etkileniyor. Şu anki kararlı sürüm 2.30.6 olduğu için, kullanıcıların en son kararlı sürüme güncelleme yapmaları öneriliyor. Yama yapılamıyorsa, geçici önlem olarak token exchange özelliğinin kapatılması veya güvenilen issuer sayısının tek bir taneye düşürülmesi öneriliyor. Ancak n8n, bu önlemlerin riski tamamen ortadan kaldırmadığını belirtiyor.
İlginç bir şekilde, sürüm notlarında bu güvenlik düzeltmesinden bahsedilmiyor. 2.27.4 ve 2.28.1 changelog'larında Python import düzeltmesi, Google Ads node yükseltmesi, AI iş akışı kontrolü ve node oluşturma değişikliği yer alırken, kimlik bağlama hatasına dair hiçbir ifade bulunmuyor. Bu, güvenlik güncellemelerinin bazen gözden kaçabileceğini gösteriyor. Kullanıcıların, changelog'ların yanı sıra güvenlik bültenlerini de takip etmeleri önemli.
Bu açık, n8n'de kısa süre önce düzeltilen bir başka Enterprise zafiyetini (CVE-2026-54305) akıllara getiriyor. O açıkta, kimliği doğrulanmış herhangi bir kullanıcı, Dynamic Credentials uç noktaları üzerinden başka bir kullanıcının OAuth token'larını değiştirebiliyor veya iptal edebiliyordu. Her iki açık da Enterprise yüzeyinde yer alıyor, ancak farklı güvenlik sorunlarından kaynaklanıyor. n8n kullanıcıları, özellikle OEM entegrasyonları yapanlar, bu tür kimlik bağlama hatalarına karşı dikkatli olmalı ve sistemlerini güncel tutmalıdır.
Kaynak: thehackernews.com
