Как один токен от чужого сервиса мог впустить злоумышленника в чужой аккаунт n8n?

В платформе автоматизации рабочих процессов n8n нашли брешь, которая касается только корпоративных инсталляций с определённой настройкой — доверием сразу к нескольким внешним поставщикам токенов. Суть проста до неприличия: система опознавала пользователя по значению sub из JWT-токена, но напрочь игнорировала поле iss, то есть издателя этого токена. На практике это означало, что токен, выпущенный Издателем А с полем sub, совпадающим с идентификатором чьего-то пользователя у Издателя Б, пускал злоумышленника в систему под чужим именем. Пароль для этого не требовался вообще.
Функция называется token exchange (обмен токенами) и доступна только в Enterprise-версии — её используют OEM-партнёры, встраивающие n8n в свои продукты. Реализация опирается на RFC 8693 и придумана, чтобы избавить пользователя от второго экрана авторизации: партнёр подписывает короткоживущий JWT своим ключом, n8n сверяет подпись с настроенным публичным ключом, сопоставляет claims с локальной учётной записью — и человек оказывается залогинен. Доверенные ключи прописываются через переменную N8N_TOKEN_EXCHANGE_TRUSTED_KEYS. Примечательно, что в документации по развёртыванию эта функция до сих пор помечена как «preview», то есть предварительная версия.
Корень проблемы лежит в самой спецификации токенов. RFC 7519 прямо говорит: значение sub гарантированно уникально только в границах издателя, который его выпустил — оно должно быть «локально уникальным в контексте издателя» либо уникальным глобально. Правильный идентификатор пользователя — это пара iss + sub, а не одно только sub. В n8n использовали лишь половину нужной связки. Ничто не мешало двум разным издателям выдать одинаковую строку subject, и оба случая маппились бы на один и тот же аккаунт внутри n8n.
Уязвимости присвоили номер CVE-2026-59208. Публикация CVE состоялась 9 июля, хотя патч вышел заметно раньше — 24 июня. Оценки серьёзности разошлись между площадками: GitHub как CNA (Numbering Authority) поставил 7.6 балла по CVSS 4.0 с рейтингом High, отметив наличие «требований к атаке» без дальнейших уточнений. NVD оценила иначе — 6.8 по CVSS 3.1, уровень Medium, и оценку по CVSS 4.0 пока не выпустила вообще. В записи NVD фигурируют два кода классификации слабостей: CWE-287 и CWE-346. Агентство CISA в оценке SSVC от 13 июля указало статус эксплуатации как «none» — данных об использовании уязвимости в реальных атаках нет. The Hacker News проверяли открытые источники на 16 июля и публичного proof-of-concept тоже не нашли.
Об уязвимости сообщил пользователь GitHub с ником bearsyankees. В его профиле указана компания Strix, которая делает агента для автоматизированного пентеста на основе ИИ. По их собственному описанию, агента направили именно на функциональность token exchange, и там он обнаружил проблему с привязкой идентичности.
Масштаб проблемы, если верить самому n8n, довольно узкий: под удар попадают только инсталляции, где token exchange включён, и при этом настроено доверие как минимум к двум внешним издателям токенов одновременно. Поскольку функция доступна лишь в Enterprise-версии и всё ещё числится в статусе preview, реальный круг затронутых развёртываний ограничивается конкретными OEM-партнёрами. Остаётся открытым один практический вопрос: как злоумышленник вообще добывает такой вредоносный токен. В официальном разборе сказано лишь, что атакующий «может получить» токен — но не объясняется, способен ли обычный пользователь у доверенного издателя как-то повлиять на собственное значение sub. Публичные материалы ответа на это не дают.
Проблема затрагивает все релизы n8n ниже версии 2.27.4, а также отдельно версию 2.28.0. Исправление вошло в 2.27.4 и 2.28.1 — это минимальные безопасные версии. На момент проверки 16 июля пакет n8n в npm-реестре под тегами «latest» и «stable» показывал версию 2.30.6. По собственному заявлению разработчиков, новая минорная версия выходит почти каждую неделю.
Тем, кто пока не может обновиться, рекомендуют проверить две настройки: переменную N8N_TOKEN_EXCHANGE_TRUSTED_KEYS с доверенными ключами подписи и отдельный preview-флаг, включающий саму функцию token exchange. В качестве временной меры советуют либо сократить список доверенных издателей до одного, либо вовсе отключить token exchange. Правда, в самом security advisory указано, что ни одна из этих мер полностью риск не устраняет — хотя формулировка эта, по наблюдению журналистов, идентична как минимум трём другим предупреждениям безопасности n8n, включая одно от 10 июня. При этом если верить заявленным рамкам самого n8n, инсталляция с выключенным token exchange уязвимости вообще не подвержена.
Двумя неделями раньше июньского патча, примерно 10 июня, в n8n закрыли другую уязвимость — CVE-2026-54305, тоже касающуюся только Enterprise-функций. Природа бага там иная: отсутствовала проверка владения ресурсом, а не привязка идентичности. Из-за этого любой аутентифицированный пользователь мог перезаписать или отозвать чужие сохранённые OAuth-токены через эндпоинты Dynamic Credentials. Баг другой, но зона поражения та же — корпоративные функции платформы.
Отдельного внимания заслуживает то, что ни в одном из release notes — ни к 2.27.4, ни к 2.28.1 — исправление по привязке идентичности вообще не упоминается. The Hacker News проверили оба changelog: там фигурируют исправление импорта Python, обновление ноды Google Ads, проверка AI-воркфлоу и изменение в процессе сборки нод. Ни слова про security-фикс. Единственное место, где это исправление документировано — сам security advisory. Команды, которые принимают решения об обновлении, ориентируясь только на changelog, рискуют этот патч попросту пропустить.
The Hacker News направили запрос в n8n с просьбой подтвердить масштаб и последствия CVE-2026-59208 и обещали обновить материал при получении ответа.