Платформата за автоматизация на работни процеси n8n е предоставяла достъп до грешни акаунти при вписване. При Enterprise инстанции, конфигурирани да се доверяват на повече от един външен издател на токени, системата е съпоставяла входящия JWT токен с локален потребител единствено по твърдението (claim) sub, пренебрегвайки iss.
Валиден токен от издател A, съдържащ sub, който принадлежи на потребител под издател B, е позволявал вписване от негово име, без изобщо да се изисква парола. n8n пусна корекция за сигурност на 24 юни.
Уязвимостта се проследява под идентификатор CVE-2026-59208. Записът за CVE стана публичен едва на 9 юли. n8n приписва откритието на GitHub профила bearsyankees, чийто профил сочи към Strix – компания, разработваща AI агент за penetration testing.
От Strix посочват, че техният агент е бил насочен към процеса на обмен на токени и е открил грешка при обвързването на идентичността.
Обменът на токени е Enterprise функционалност на n8n за OEM партньори, които вграждат продукта (имплементация на RFC 8693), спестявайки на своите потребители втори екран за вписване. Партньорът подписва краткосрочен JWT със собствения си ключ, n8n го верифицира спрямо конфигуриран публичен ключ, съпоставя твърденията с локален акаунт и потребителят влиза в системата. Доверените ключове се описват в N8N_TOKEN_EXCHANGE_TRUSTED_KEYS, като в документацията функцията все още е маркирана като предварителна версия (preview).
Самият токен се проверява успешно – дефектът е в съпоставянето. Стойността на sub е гарантирано уникална само в контекста на издателя, който я е генерирал. RFC 7519 изисква тя да бъде локално уникална за издателя или глобално уникална. Поради това идентификаторът на даден потребител е двойката iss плюс sub. n8n е използвала само половината от тази двойка. Нищо не пречи на двама издатели да емитират един и същ субект и когато това се случи, и двата достъпа се насочват към един и същ акаунт в n8n.
Уязвимостта засяга дадена инстанция само ако обменът на токени е активиран и конфигурацията се доверява на поне два външни издателя. n8n твърди, че нищо друго не е засегнато. Тъй като функцията е налична само в Enterprise версията и е в тестов режим, броят на изложените системи е малък и специфичен – предимно OEM внедрявания с повече от един доверен издател.
В официалното съобщение не се уточнява как точно атакуващият се сдобива с токена. Остава въпросът дали обикновен потребител при доверен издател може да влияе на стойността на sub, която получава. Оценката на GitHub по CVSS 4.0 определя ниво на застрашеност 7.6 (високо), докато NVD дава оценка 6.8 по CVSS 3.1 (средно) с класификации CWE-287 и CWE-346. CISA отчита нулева активност на експлоатация към 13 юли.
Две седмици преди тази корекция, разработчиците отстраниха друга Enterprise уязвимост – CVE-2026-54305, която позволяваше на всеки автентифициран потребител да презаписва или отменя OAuth токени на други потребители. Това беше проблем с липсваща проверка на собствеността, а не с обвързване на идентичността.
Засегнати са версиите на n8n преди 2.27.4 и версия 2.28.0. Проблемът е отстранен в 2.27.4 и 2.28.1. Препоръчва се преминаване към най-новата стабилна версия.
Ако инсталирането на корекции за сигурност трябва да се отложи, временно решение е да се ограничи конфигурацията до един доверен издател или изцяло да се изключи обменът на токени чрез премахване на съответния флаг.