В платформе автоматизации рабочих процессов n8n обнаружена уязвимость CVE-2026-59208, позволяющая злоумышленнику аутентифицироваться под чужой учётной записью без знания пароля. Проблема затрагивает Enterprise-инстансы с включённой функцией обмена токенами (token exchange) и как минимум двумя доверенными внешними издателями JWT. Система сопоставляла входящий токен с локальным пользователем исключительно по значению claim sub, игнорируя iss — издателя токена. Патч выпущен 24 июня в версиях 2.27.4 и 2.28.1; администраторам затронутых конфигураций необходимо обновиться или ограничить число доверенных издателей до одного.
Суть уязвимости: половина идентификатора вместо целого
Функция token exchange в n8n реализует спецификацию RFC 8693 и предназначена для OEM-партнёров, встраивающих n8n в свои продукты. Партнёр подписывает короткоживущий JWT своим ключом, n8n проверяет подпись по заранее сконфигурированному публичному ключу из переменной окружения N8N_TOKEN_EXCHANGE_TRUSTED_KEYS, сопоставляет claims с локальной учётной записью и пропускает пользователя без повторной аутентификации.
Проблема заключалась в логике сопоставления. Согласно RFC 7519, значение claim sub гарантированно уникально только в контексте конкретного издателя (iss). Корректный идентификатор пользователя — это пара iss + sub. Однако n8n использовал для привязки только sub, фактически опираясь на половину идентификатора.
Практическое следствие: если два доверенных издателя (A и B) выпускают токены с одинаковым значением sub для разных пользователей, валидный токен от издателя A позволяет аутентифицироваться как пользователь, зарегистрированный под издателем B. Пароль жертвы при этом не задействуется — система полностью доверяет привязке по sub.
Оценки серьёзности и статус эксплуатации
Оценки серьёзности от разных источников расходятся. GitHub как CNA присвоил уязвимости CVSS 4.0 — 7.6 (High). NVD оценил её по CVSS 3.1 на уровне 6.8 (Medium) и связал с классами слабостей CWE-287 (некорректная аутентификация) и CWE-346 (недостаточная проверка источника). Расхождение объясняется как разницей в методологиях CVSS 4.0 и 3.1, так и различной интерпретацией условий атаки.
Уязвимость не внесена в каталог CISA Known Exploited Vulnerabilities. По имеющимся данным, публичных доказательств концепции (PoC) и подтверждённых случаев эксплуатации не зафиксировано.
Кто под угрозой
Область воздействия узкая, но для затронутых конфигураций последствия серьёзны. Уязвимость проявляется только при одновременном выполнении трёх условий:
- Enterprise-лицензия n8n;
- активированная функция token exchange (по данным документации, всё ещё в статусе preview);
- конфигурация с двумя или более доверенными внешними издателями токенов.
Это типичный сценарий OEM-развёртываний, где несколько партнёров интегрируют n8n в свои платформы. Для таких инстансов уязвимость фактически означает возможность кросс-тенантного захвата аккаунтов — пользователь одного партнёра может получить доступ к данным и рабочим процессам пользователя другого партнёра.
Открытым остаётся вопрос о практической реализуемости атаки: адвизори не уточняет, может ли рядовой пользователь доверенного издателя влиять на значение sub в своём токене. Вектор CVSS от GitHub указывает на наличие дополнительных требований к атаке, но не раскрывает их.
Контекст: вторая Enterprise-уязвимость за две недели
За две недели до выпуска патча для CVE-2026-59208 разработчики n8n исправили CVE-2026-54305 — ещё одну уязвимость, ограниченную Enterprise-функциональностью. Она позволяла любому аутентифицированному пользователю перезаписывать или отзывать OAuth-токены других пользователей через эндпоинты Dynamic Credentials из-за отсутствия проверки владельца ресурса. Две разные уязвимости — привязка идентичности и контроль доступа к ресурсам — но обе указывают на недостаточную зрелость проверок авторизации в Enterprise-компонентах платформы.
Рекомендации по устранению
Затронуты все версии n8n ниже 2.27.4, а также версия 2.28.0. Исправление доступно начиная с версий 2.27.4 и 2.28.1.
- Обновление — приоритетная мера. Установите как минимум версию 2.27.4 или 2.28.1, а лучше — последнюю стабильную сборку.
- Если обновление невозможно немедленно — сократите список доверенных издателей в
N8N_TOKEN_EXCHANGE_TRUSTED_KEYSдо одного или полностью отключите функцию token exchange. По заявлению n8n, инстансы с выключенным token exchange не подвержены уязвимости. - Проверьте журналы аутентификации на предмет аномальных входов — сессий, где пользователь аутентифицировался через токен одного издателя, но получил доступ к ресурсам, принадлежащим учётной записи другого.
Важный нюанс: ни в changelog версии 2.27.4, ни в changelog версии 2.28.1, по имеющимся данным, исправление не упоминается. Информация содержится только в адвизори. Организации, принимающие решения об обновлении исключительно на основе release notes, рискуют пропустить этот патч.
Администраторам n8n Enterprise с активной функцией token exchange и несколькими доверенными издателями следует рассматривать обновление как срочное. Даже при узком охвате уязвимости последствия её эксплуатации — полный захват учётной записи без взаимодействия с жертвой — делают промедление неоправданным. Проверьте текущую версию, содержимое N8N_TOKEN_EXCHANGE_TRUSTED_KEYS и примите решение: обновить или ограничить конфигурацию.
