n8n Token Değişim Güvenlik Açığı: Saldırganlar Başka Bir Sağlayıcının Kullanıcısı Olarak Giriş Yapabiliyor Dünya Geneli

n8n Token Değişim Güvenlik Açığı: Saldırganlar Başka Bir Sağlayıcının Kullanıcısı Olarak Giriş Yapabiliyor

n8n'deki token değişim güvenlik açığı, saldırganların farklı bir ISS'den geçerli bir JWT ile başka bir kullanıcı olarak giriş yapmasına izin veriyor.

n8n iş akışı otomasyon platformunda kritik bir güvenlik açığı keşfedildi. CVE-2026-59208 olarak izlenen bu açık, Enterprise sürümlerinde token değişim özelliğini etkiliyor. Birden fazla harici token sağlayıcısına güvenecek şekilde yapılandırılmış sistemlerde, saldırganlar başka bir sağlayıcıdan geçerli bir JWT tokeni kullanarak farklı bir kullanıcı olarak oturum açabiliyor. n8n, bu sorunu 24 Haziran'da yayınladığı güncellemeyle giderdi.

Güvenlik açığının temelinde, n8n'in token doğrulama sırasında yalnızca 'sub' (konu) alanını kontrol etmesi, 'iss' (sağlayıcı) alanını yok sayması yatıyor. RFC 7519 standardına göre, bir kullanıcıyı benzersiz olarak tanımlamak için hem 'iss' hem de 'sub' alanları birlikte kullanılmalıdır. Ancak n8n, yalnızca 'sub' alanına dayanarak eşleştirme yaptığı için, farklı sağlayıcılardan aynı 'sub' değerine sahip tokenler aynı n8n hesabına yönlendiriliyor.

Bu güvenlik açığı yalnızca token değişim özelliğinin etkin olduğu ve en az iki harici token sağlayıcısının güvenildiği Enterprise kurulumlarını etkiliyor. n8n, token değişim özelliğinin henüz önizleme aşamasında olduğunu ve yalnızca OEM ortaklarına yönelik olduğunu belirtiyor. Bu nedenle, etkilenen sistem sayısı sınırlı olsa da, bu tür kurulumlarda ciddi bir risk oluşturuyor.

Saldırganın geçerli bir token elde etmesi gerekiyor, ancak bunun nasıl yapılabileceği konusunda net bir bilgi bulunmuyor. GitHub tarafından atanan CVSS 4.0 puanı 7.6 (yüksek) iken, NVD tarafından CVSS 3.1'e göre 6.8 (orta) olarak değerlendiriliyor. CISA'nın değerlendirmesinde ise herhangi bir istismar raporu bulunmuyor. Henüz kamuya açık bir istismar kodu da yayınlanmış değil.

Gelecekte Ne Bekleniyor?

n8n, bu güvenlik açığını 2.27.4 ve 2.28.1 sürümlerinde düzeltti. Kullanıcıların en kısa sürede bu sürümlere veya daha yenisine güncelleme yapmaları öneriliyor. Yama yapılamıyorsa, geçici olarak token değişim özelliğinin devre dışı bırakılması veya yalnızca tek bir token sağlayıcısına güvenilmesi tavsiye ediliyor. Ancak bu önlemlerin riski tamamen ortadan kaldırmadığı belirtiliyor.

İlginç bir şekilde, sürüm notlarında bu güvenlik açığından hiç bahsedilmiyor. 2.27.4 ve 2.28.1 değişiklik günlüklerinde Python içe aktarma düzeltmesi, Google Ads düğümü yükseltmesi ve AI iş akışı kontrolü gibi konular yer alırken, kimlik bağlama hatasına dair hiçbir bilgi bulunmuyor. Bu durum, güncellemeleri yalnızca değişiklik günlüklerine dayanarak yapan kullanıcıların bu kritik düzeltmeyi gözden kaçırabileceği anlamına geliyor.

Kaynak: thehackernews.com

Paylaş: