Оpen source-платформа автоматизації робочих процесів n8n опинилася в епіцентрі уваги фахівців з кібербезпеки. Протягом останніх тижнів розкрито деталі одразу чотирьох критичних уразливостей, дві з яких отримали максимальний бал 10,0 за CVSS. Найнебезпечніша з них — Ni8mare (CVE-2026-21858) — дозволяє віддалено перехопити контроль над інстансом без будь-якої аутентифікації.
n8n як ціль для атак: чому платформа автоматизації така ризикована
n8n — це no-code/low-code платформа для побудови інтеграційних воркфлоу, яка з’єднує застосунки, API та хмарні сервіси через візуальний конструктор. Вона широко використовується для оркестрації LLM, запуску ІІ‑агентів та RAG‑ланцюгів, тому стала ключовим елементом багатьох сучасних ІІ‑екосистем.
За даними екосистеми, n8n має понад 50 000 щотижневих завантажень у npm та перевищує 100 млн завантажень на Docker Hub. Така популярність робить платформу привабливою мішенню для зловмисників.
Критичність атак на n8n посилюється тим, що платформа часто зберігає найчутливіші секрети інфраструктури: API‑ключі, OAuth‑токени, паролі до баз даних, доступи до хмарних облікових записів, CI/CD‑секрети. Компрометація одного інстансу фактично відкриває зловмиснику «ключі від усієї цифрової інфраструктури» організації.
Ni8mare (CVE-2026-21858): захоплення інстансу через помилку обробки Content-Type
Уразливість Ni8mare (CVSS: 10.0) дозволяє неавторизованому атакувальнику отримати доступ до локальних файлів на сервері n8n, а в низці сценаріїв — довести атаку до виконання довільного коду (RCE). Проблема пов’язана з content-type confusion — некоректною обробкою вхідних даних залежно від заголовка Content-Type у вебхуках та формах.
У n8n застосовуються два різні механізми парсингу запитів. Для multipart/form-data використовується спеціальний парсер, який зберігає файли у тимчасових директоріях та захищає від path traversal. Для інших типів, наприклад application/json, працює стандартний парсер без такої перевірки шляху.
Дослідники показали, що якщо задати заголовок Content-Type: application/json, але передати поля, які n8n очікує як файлові, можна отримати повний контроль над об’єктом req.body.files. Це дає змогу маніпулювати метаданими, зокрема шляхом до файлу, і замість роботи з завантаженим файлом змусити інстанс читати довільні файли файлової системи.
У результаті зловмисник може отримати доступ до конфігурацій, логів, баз даних, ключів шифрування, використати їх для підробки cookie, обходу аутентифікації та подальшої ескалації до RCE. За офіційною інформацією, Ni8mare зачіпає всі збірки n8n до версії 1.65.0 включно і виправлена у релізі 1.121.0. Повноцінних обхідних рішень немає: розробники рекомендують обмежити або тимчасово вимкнути публічно доступні webhook‑ та form‑ендпоінти до встановлення оновлень.
Інші критичні уразливості n8n: RCE, завантаження файлів та втеча з пісочниці
CVE-2026-21877: небезпечна обробка завантажуваних файлів
Уразливість CVE-2026-21877 (CVSS: 10.0) пов’язана з небезпечною логікою завантаження файлів. За певних умов автентифікований користувач може завантажити шкідливий вміст і домогтися виконання свого коду на сервері, що веде до повної компрометації інстансу.
Проблема стосується версій від 0.123.0 до 1.121.3 (не включно) і була усунена у версії 1.121.3. До оновлення рекомендується відключити Git‑ноду та обмежити доступ для недовірених користувачів, особливо у мультиорендних та SaaS‑сценаріях.
N8scape (CVE-2025-68668): втеча з Python‑пісочниці Pyodide
N8scape (CVE-2025-68668, CVSS: 9.9) вражає Python Code Node, який працює у пісочниці на базі Pyodide. Користувач, що має право створювати чи змінювати воркфлоу, може обійти механізми ізоляції та виконати команди на хості з правами процесу n8n.
Під загрозою версії від 1.0.0 до 2.0.0 (не включно). У релізі 2.0.0 за замовчуванням увімкнено нативну імплементацію Python на основі task runner, вперше представлену опційно в 1.111.0, що значно посилює ізоляцію виконання коду.
CVE-2025-68613: недостатній контроль динамічного коду
Ще одна критична вада — CVE-2025-68613 (CVSS: 9.9), класифікована як improper control of dynamically-managed code resources. В окремих конфігураціях автентифіковані користувачі здатні досягти віддаленого виконання коду. Виправлення доступні у версіях 1.120.4, 1.121.1 та 1.122.0. За оцінкою Censys, до кінця грудня 2025 року в мережі нараховувалося понад 100 000 потенційно вразливих розгортань n8n.
Масштаби експозиції та наслідки для DevOps‑ та ІІ‑інфраструктури
За даними Censys, у відкритому доступі ідентифіковано понад 26 000 хостів n8n. Найбільша концентрація спостерігається у США (7079), Німеччині (4280), Франції (2655), Бразилії (1347) та Сінгапурі (1129). Реальна кількість інстансів, що працюють за VPN, проксі та в приватних сегментах, імовірно значно вища.
Оскільки n8n часто виступає як інтеграційна «шина» між базами даних, чергами повідомлень, хмарними сервісами та CI/CD‑конвеєрами, її компрометація перетворюється на зручну стартову точку для атаки на усю DevOps‑ та ІІ‑інфраструктуру організації.
Практичні кроки захисту інстансів n8n
Адміністраторам та DevOps‑командам доцільно в найкоротші строки оновити n8n до захищених версій: щонайменше до 1.121.3 для усунення Ni8mare та CVE-2026-21877 і до 2.0.0 — для закриття N8scape. Важливо переконатися, що інстальовані виправлення для CVE-2025-68613 (версії 1.120.4, 1.121.1 або 1.122.0).
Додатково рекомендується не публікувати інстанс n8n безпосередньо в інтернет, а розміщувати його за VPN, reverse‑proxy або Zero Trust‑шлюзом; увімкнути аутентифікацію для всіх Forms і вебхуків; мінімізувати права користувачів за принципом найменших привілеїв; регулярно переглядати список секретів, що зберігаються в n8n, та ротувати їх у разі підозри на компрометацію.
Організаціям, які активно використовують автоматизацію та ІІ‑оркестрацію, варто розглядати n8n та подібні платформи як критичні елементи інфраструктури. Регулярні аудити конфігурації, тестування на проникнення, моніторинг підозрілої активності воркфлоу та централізоване управління секретами суттєво зменшують ризик того, що наступна масштабна атака розпочнеться саме з компрометації платформи автоматизації.
