У платформі автоматизації робочих процесів 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 у свої платформи. Для таких інстансів вразливість фактично означає можливість крос-тенантного захоплення облікових записів — користувач одного партнера може отримати доступ до даних і робочих процесів користувача іншого партнера.
Відкритим лишається питання практичної здійсненності атаки: advisory не уточнює, чи може пересічний користувач довіреного емітента впливати на значення 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, за наявною інформацією, виправлення не згадується. Інформація міститься лише в advisory. Організації, які ухвалюють рішення щодо оновлення виключно на основі release notes, ризикують пропустити цей патч.
Адміністраторам n8n Enterprise з активною функцією token exchange і кількома довіреними емітентами варто розглядати оновлення як невідкладне. Навіть за вузького охоплення вразливості наслідки її експлуатації — повне захоплення облікового запису без взаємодії з жертвою — роблять зволікання невиправданим. Перевірте поточну версію, вміст N8N_TOKEN_EXCHANGE_TRUSTED_KEYS і ухваліть рішення: оновити чи обмежити конфігурацію.
