Популярна платформа для автоматизації бізнес-процесів n8n зіткнулася з критичною уразливістю CVE-2026-25049 із оцінкою 9,4 за CVSS. Помилка в механізмі ізоляції JavaScript-коду дозволяла автентифікованим користувачам виконувати довільні системні команди на сервері, фактично отримуючи повний контроль над інстансом n8n.
Уразливість n8n CVE-2026-25049: суть проблеми та збій пісочниці
У центрі інциденту — компонент JavaScript-пісочниці, який використовується для безпечного виконання виразів у робочих процесах n8n. Щоб відфільтрувати небезпечні конструкції, платформа застосовує аналіз абстрактного синтаксичного дерева (AST), блокуючи потенційно шкідливий код ще до його запуску.
Дослідники з Pillar Security, Endor Labs та SecureLayer7 виявили, що реалізація AST-фільтрації була неповною. Обмеження можна було обійти за допомогою еквівалентних конструкцій JavaScript, що відкривало доступ до глобального об’єкта Node.js та системних функцій поза межами пісочниці.
Особливо показово, що CVE-2026-25049 дала змогу обійти вже впроваджений захист від іншої критичної вади — CVE-2025-68613 з рейтингом 9,9 за CVSS, закритої у грудні 2025 року. Таким чином, нова уразливість стала альтернативним вектором атаки попри попередній патч.
Механізм атаки: обхід JavaScript-sandbox та віддалене виконання коду
За даними SecureLayer7, зловмисникам вдалося домогтися виконання JavaScript на стороні сервера через конструктор Function, який у нормі має бути недоступним у пісочниці. Для підбору робочої обхідної конструкції знадобилося понад 150 ітерацій, що демонструє складність реалізації надійної ізоляції коду.
Експерти Endor Labs підготували простий proof-of-concept-експлойт, який демонструє повноцінний remote code execution (RCE) на сервері n8n. Після успішного обходу AST-перевірок атакувальник отримував доступ до Node.js API, міг викликати системні утиліти й використовувати інстанс як точку входу в корпоративну інфраструктуру.
Кого зачіпає уразливість n8n та які наслідки
Для експлуатації CVE-2026-25049 достатньо мати обліковий запис із правом створення або редагування воркфлоу. Як зазначають у Pillar Security, за такого рівня доступу «фактично можна захопити контроль над сервером n8n».
1. Віддалене виконання системних команд (RCE). Зловмисник може запускати команди ОС, встановлювати додаткове ПЗ, розгортати бекдори та використовувати скомпрометований сервер для подальшого руху мережею (lateral movement).
2. Компрометація секретів та інтеграцій. Під загрозою всі чутливі дані, що зберігаються в n8n: API-ключі, OAuth-токени, логіни й паролі до зовнішніх сервісів. За даними звітів з кібербезпеки, компрометація облікових даних є чинником у більш ніж половині успішних атак, тож ризик тут особливо високий.
3. Доступ до файлової системи й внутрішніх сервісів. Зловмисник може читати й у певних сценаріях змінювати файли, звертатися до внутрішніх сервісів, баз даних та API, які не мають прямого виходу в інтернет.
4. Вплив на AI-воркфлоу. Оскільки n8n активно використовують для оркестрації AI-процесів, атакуючий може перехоплювати промпти, непомітно змінювати відповіді моделей чи логіку ланцюжків, а також перенаправляти трафік до контрольованих ним сервісів.
Найвищий рівень ризику спостерігається в multi-tenant-розгортаннях, де один кластер обслуговує кількох клієнтів. У разі RCE з’являється теоретична можливість вийти за межі одного орендаря та дістатися даних інших організацій.
Таймлайн CVE-2026-25049 та робота з дослідниками
Pillar Security повідомила розробників n8n про проблему 21 грудня 2025 року, надавши практичну демонстрацію втечі з пісочниці та доступу до глобального об’єкта Node.js. Перше виправлення вийшло вже через два дні, однак подальший аналіз показав, що воно не перекриває всі варіанти обходу AST-фільтрації.
Остаточне закриття уразливості відбулося у версії n8n 2.4.0, реліз якої датовано 12 січня 2026 року. Для користувачів стабільних гілок рекомендовані до встановлення версії 1.123.17 та 2.5.2, де механізм пісочниці був доопрацьований комплексно.
Рекомендації з захисту інсталяцій n8n
Оновлення та базові дії реагування
Адміністраторам інстансів n8n варто якнайшвидше оновити платформу до актуальних стабільних релізів. Саме патчинг залишається найбільш ефективним способом нейтралізувати уразливість RCE в n8n.
Експерти Pillar Security додатково рекомендують:
1. Змінити ключ шифрування. Генерувати нове значення N8N_ENCRYPTION_KEY, що використовується для захисту збережених секретів.
2. Провести повну ротацію облікових даних. Пересоздати всі паролі, токени, API-ключі та OAuth-креденшіали, що зберігаються в n8n, навіть за відсутності прямих ознак компрометації.
3. Проаудитувати робочі процеси. Перевірити воркфлоу на наявність підозрілих JavaScript-виразів, особливо тих, що звертаються до системних функцій, файлової системи чи нетипових мережевих endpoint’ів.
Додаткові заходи мінімізації ризиків
Якщо оновлення неможливе негайно, варто тимчасово:
— обмежити права на створення й редагування воркфлоу лише перевіреними користувачами за принципом найменших привілеїв;
— запускати n8n в ізольованому середовищі (окремі контейнери, мінімальні права, жорсткі мережеві фільтри, сегментація доступу до внутрішніх сервісів);
— посилити моніторинг аномальної активності, зокрема запуску нетипових команд та підозрілих змін конфігурацій.
Інші уразливості безпеки n8n, закриті разом із CVE-2026-25049
Паралельно з CVE-2026-25049 розробники n8n усунули ще чотири уразливості, дві з яких також отримали оцінку 9,4 за CVSS і вимагають пильної уваги:
— CVE-2026-25053: ін’єкція команд у Git-node, що дозволяє виконувати довільні команди при роботі з репозиторіями;
— CVE-2026-25056: можливість запису довільних файлів через SQL Query у Merge-node, яка відкриває шлях до модифікації файлової системи сервера.
Також були закриті важливі, хоча й менш критичні проблеми:
— CVE-2026-25054: збережена XSS у компоненті рендерингу Markdown, що створює ризик атак на користувачів веб-інтерфейсу;
— CVE-2026-25055: path traversal у SSH-node під час обробки завантажуваних файлів, який може дозволити доступ до небажаних шляхів у файловій системі.
Інцидент навколо уразливості n8n CVE-2026-25049 демонструє, наскільки складно спроєктувати по-справжньому надійний JavaScript-sandbox у платформах автоматизації. Організаціям, що використовують n8n у продакшені, варто не обмежуватися оновленням: переглянути модель довіри до користувачів, які створюють воркфлоу, посилити сегментацію мережі, запровадити регулярну ротацію секретів і безперервний моніторинг. Чим раніше такі практики стануть стандартом, тим менше буде потенційний вплив неминучих уразливостей у складних екосистемах автоматизації.
