CVE-2026-27577 n8n'de: Yamanın kendisi atlatıldığında

n8n'i kendi barındıranlar rutini tanıyor: güvenlik uyarısını oku, sürümü yükselt, tik koy. CVE-2026-27577 söz konusu olduğunda bu rutin yeterli değildi. Açık 25 Şubat 2026'da yamalandı ve Temmuz 2026'da güvenlik araştırmacıları tam olarak bu yamada bir atlatma keşfettiler.

Bu bir kazıkışı değil, sekiz ay içinde aynı bileşene yönelik belgelenmiş dördüncü girişim. Kendi barındırılan örnekler için bu soruyu değiştirir: Belirli bir güncellemeyi uyguladığınız değil, aynı noktaya yapılan takip girişimlerini yakalayan bir işleminiz olup olmadığıdır. Genel durumu n8n Güvenlik Açıkları 2026 bölümünde açıkladık. Bu yazı atlatmanın kendisine girer.

CVE-2026-27577 tam olarak nedir?

CVE-2026-27577, n8n'nin ifade değerlendirmesinde, oturum açmış bir kullanıcı tarafından, iş akışı oluşturma ve değiştirme haklarıyla, iş akışı parametrelerindeki hazırlanmış ifadeler aracılığıyla ana bilgisayarda sistem komutları yürütülmesine izin veren kritik bir açıktır.

NVD açığı CVSS 3.1 9,9 (kritik) ve CWE-94, Kod Enjeksiyonu zafiyeti sınıfıyla listelenir. GitHub Security Advisory GHSA-vpcf-gvg4-6qwr bunu ek olarak CVSS 4.0 ile 9,4 olarak değerlendirir. 1.123.22 öncesindeki tüm sürümler, 2.0.0'dan 2.9.3 öncesi 2.x serisi ve 2.10.0 etkilenmiştir. 1.123.22, 2.9.3 ve 2.10.1'de yamalanmıştır, üçü de 25 Şubat 2026'da npm'de yayınlanmıştır.

Sınıflandırma için önemli: n8n, CVE-2026-27577'yi kendi danışmanlığında CVE-2025-68613'e, Aralık 2025'ten gelen ifade değerlendirmesindeki orijinal açığa açık bir ek olarak tanımlar. Aradaki CVE-2026-25049 4 Şubat 2026'dan gelmektedir, aynı şekilde CVSS 3.1 9,9, aynı şekilde aynı koruma mekanizmasını atlatmanın bir yoludur.

CVE-2026-27577'ye yönelik yama neden Temmuz 2026'da atlatıldı?

CVE-2026-27577'ye yönelik düzeltme, somut olarak bildirilen saldırı yolunu kapattı, ancak ifadelerin yeniden yazıcısındaki temel açığı değil. Güvenlik şirketi Security Joes, Temmuz 2026'da aynı Node.js çalışma zamanı erişiminin farklı bir dil yapısı aracılığıyla elde edilebileceğini gösterdi.

Teknik olarak Security Joes, bireysel olarak zararsız ancak birlikte çalışan iki kör noktayı tanımlar: Özgür tanımlayıcıların yeniden yazımı ok işlevlerini atlar, böylece 'işlem nesnesi döndüren ok işlevi' biçimindeki bir ifade korumanın yanından geçer ve tehlikeli özelliklerin engel listesi yalnızca statik olarak yazılan adları kontrol eder, bu nedenle aynı ad bir string olarak geçirildiğinde çalışmaz. Buna göre yayına verilene, n8n 2.30.4'te doğrulanmıştır, yani CVE-2026-27577'ye yönelik yama hattının ardından bir sürümde (Kaynak: Security Joes, "Breaking the Sandbox Again", 27 Temmuz 2026).

İş akışı üretici için konuşuyor: Security Joes bulguyu 15 Temmuz 2026'de n8n'nin Vulnerability-Disclosure-Programı aracılığıyla bildirdi, 22 Temmuz 2026'da düzeltme yayınlandı ve GHSA-gv7g-jm28-cr3m danışmanı yayınlandı, CVSS 4.0 8,7 ile değerlendirildi. Bu yol 2.31.5 ve 2.32.1'de yamalanmıştır. Aynı gün n8n, CVE-2026-65591 (CVSS 4.0 8,9) ile eski ifade değerlendirticisinde aynı türden ikinci bir atlatmayı yayınladı, 1.123.64, 2.29.8 ve 2.30.1'de yamalanmıştır.

Şimdi hangi n8n sürümü güvenli?

Burada adı geçen tüm atlatmalara karşı güvenli olan ilk sürüm 1.123.67, 2.31.5 veya 2.32.1'dir, çünkü Temmuz yamaları CVE-2026-27577'ye yönelik yama hattının ardındadır. Şubat 2026'da 1.123.22 veya 2.10.1'e güncelleyen ve o zamandan beri hiçbir şey yapmayan kişi saldırıya açıktır.

• İfade açığı CVE-2025-68613 (Aralık 2025): 1.120.4, 1.121.1 ve 1.122.0'da düzeltilmiştir.
• Atlatma CVE-2026-25049 (4 Şubat 2026): 1.123.17 ve 2.5.2'de düzeltilmiştir.
• Atlatma CVE-2026-27577 (25 Şubat 2026): 1.123.22, 2.9.3 ve 2.10.1'de düzeltilmiştir.
• Atlatma CVE-2026-65591 (22 Temmuz 2026): 1.123.64, 2.29.8 ve 2.30.1'de düzeltilmiştir.
• Ok işlevleri aracılığıyla atlatma, GHSA-gv7g-jm28-cr3m (22 Temmuz 2026): 2.31.5 ve 2.32.1'de düzeltilmiştir.

Bu yazının yayın kapatılması zamanında 31 Temmuz 2026'den 2.32.7 npm'deki geçerli kararlı sürümdür. Örneğinizin sürüm numarasını arayüzün ayarlarında bulabilirsiniz.

Kimin aslında iş akışlarını düzenlemesine izin verilir?

Bu serinin tüm açıkları, iş akışları oluşturma veya değiştirme haklarıyla oturum açan bir hesap gerektirir. Bu nedenle n8n'de hak verme bir rahatlık ayarı değil, bir güvenlik sınırıdır: İş akışlarını düzenlemeye izin verilenleri, açık bir atlatmada sunucuya kabuk erişimi olan bir kullanıcıyla aynı seviyede durur.

Üstlendiğimiz birçok kurulumda, tüm katılımcılar basitçe düzenleme haklarına sahiptir, çünkü kurulum sırasında en hızlı olan budur ve kimse geri dönmemiştir. Yönetilen örneklerde, bu nedenle sürüm durumunun yanı sıra, kimin düzenleme haklarına sahip olduğunu ve arayüzün genel internetten erişilebilir olması gerekip gerekmediğini kontrol ederiz. Her ikisi de n8n örneğinin devam eden işletimlerine aittir ve bir sonraki manşetin ardından özel bir eyleme değil.

Kendi barındıranlar şimdi ne yapmalı?

Tek tam koruma güncelleme, n8n danışmanları kendileri bunu söylüyor. Orada adı geçen geçiş önlemleri durumu hafifletir, ancak açıkça çözmez.

• Sürümü kontrol edin ve güncelleyin: en az 1.123.67, 2.31.5 veya 2.32.1'e, tercihen mevcut kararlı sürüme.
• Düzenleme haklarını kısıtlayın: iş akışlarını oluşturmak ve değiştirmek yalnızca işi için buna gerçekten ihtiyaç duyan kişiye izin verilir. Bu n8n tarafından önerilen geçiş ölçüsüdür.
• Erişimi izleyin, eğer uzun süredir savunmasız bir sürümde olduysa: Security Joes bu durumda, başarılı bir saldırı tam bunlara ulaştığı için örneğin şifreleme anahtarını ve kaydedilen erişim kimlik bilgilerini değiştirmeyi önerir.
• Arayüzü açıkça internete bağlamayın: VPN veya güvenli bir ters proxy aracılığıyla erişim, n8n belgelerindeki sertleştirme ipuçlarına bakın.
• Meldileri kalıcı olarak izleyin: n8n'nin GitHub-Security-Advisories'ne abone olun ve çağrı üzerine tepki vermek yerine sabit bir güncelleme penceresi planlayın.

Bu CVE serisi, neden banal tavsiye çok önemli olduğunu gösterir: 25 Şubat ve 22 Temmuz yamaları arasında yaklaşık beş ay vardı, bu süre içinde doğru şekilde güncellenen bir örnek bile birisi sonraki yolu bulduğunda saldırıya açıktı. Detaylı sertleştirme ipuçları n8n tarafından docs.n8n.io'da sağlanır.

Sık Sorulan Sorular

n8n Cloud CVE-2026-27577'den etkileniyor mu?

n8n kendi bulut ortamını kendisi günceller, yama yönetimi orada sağlayıcı tarafında yer alır. Bu CVE serisinin pratik tehlikesi, özellikle zamanında güncellenmemiş kendi barındırılan örnekleri etkiler. Hak sorunu her iki işletme modelinde de devam eder, çünkü iş akışı düzenleme haklarına sahip bir hesap saldırının ön koşuludur.

1.123.22 veya 2.10.1'e güncellemek yeterli mi?

Hayır, bu yalnızca CVE-2026-27577'nin kendisini kapatır. Temmuz 2026'da yayınlanan aynı koruma mekanizmasının atlatmaları 1.123.67, 2.31.5 sırasıyla 2.32.1'den başlayarak düzeltilir, eski değerlendiricide atlatma 1.123.64, 2.29.8 ve 2.30.1'den başlayarak düzeltilir.

Örneğimin kötüye kullanılıp kullanılmadığını nasıl anlarım?

Uzaktan güvenilir bir tanımlama yöntemi yoktur. İş akışlarının yürütme geçmişine bakan, düğüm parametrelerinde olağandışı ifadelerle, ve sunucunun giden bağlantılarını kontrol etme mantıklıdır. Şüphede, Security Joes'un yayınından ilke uygulanır: erişim kimlik bilgilerini tehlikeye düşmüş olarak ele alın ve değiştirin.

Neden aynı bileşen dört kez vuruldu?

Çünkü n8n'nin ifade değerlendirmesi, JavaScript'i kullanıcılar tarafından çalıştırılabilir hale getirmesi ve aynı zamanda sunucunun çalışma zamanından koruma altına alması gerekir. Her yama önce bildirilen yolu kapatır. Security Joes bunu tam olarak bir desen olarak formüle eder: CVE-2026-27577'ye yönelik düzeltme bildirilen durum için doğru idi, ancak diğer atlatılan dil yapılarıyla ilgili daha genel soruyu sormadı.

NordFlux mevcut n8n örneklerini güvence altına almada yardımcı olur mu?

Evet. Mevcut kurulumların sürüm durumunu, hak vergisini ve erişim korumasını kontrol ederiz ve istenirse devam eden güncelleme yönetimini üstleniriz. n8n ile ilgili çalışmamıza genel bir bakış, n8n hizmet sayfamızdabulabilirsiniz.