Критическая уязвимость в n8n: практическое руководство по рискам и защите

Коротко о проблеме

В популярной системе автоматизации рабочих процессов обнаружена уязвимость уровня «можно взять систему под контроль». Неполадка связана с Python Code Node и реализацией Pyodide — механизмом запуска Python в браузерном/песочном окружении. В результате злоумышленник с правом создания или изменения workflow может запустить произвольную команду на хосте, где работает n8n.

Почему это важно

n8n часто используется для интеграции внешних сервисов, обработки вебхуков и автоматизации CI/CD-процессов. В типичном стеке платформа располагается рядом с базами данных, облачными ключами и API‑токенами. Удалённое исполнение команд на хосте — это не просто «еще одна уязвимость», а путь к компрометации конфиденциальных данных и распространению внутри инфраструктуры.

Ключевые факты

• Серьёзность: CVSS 9.9 — почти максимальная оценка.
• Условия: требуется авторизация и право на создание/редактирование workflow.
• Версии: затронуты релизы с 1.0.0 до 2.0.0 (не включая 2.0.0). Обновление исправляет проблему.
• Механизм: обход песочницы в Python Code Node, использующем Pyodide (WebAssembly).

Как работает уязвимость: простыми словами

Pyodide — это порт Python в WebAssembly. Он удобен: позволяет встраивать Python‑скрипты в окружения, где нет полного CPython. Но WebAssembly‑песочница — не магический щит. Если интерфейс между изолированным кодом и хостом реализован ненадёжно, изолированный код может вызвать операции на стороне хоста через API, обходы серийных вызовов, или воспользоваться уязвимостями в рантайме.

В данном случае Code Node предоставляет связку JavaScript ↔ Pyodide; недостаточная фильтрация, небезопасные мосты данных или уязвимости в самом механизме обмена данными позволяли «вырваться» из песочницы и исполнить системную команду от имени процесса n8n.

Реалистичные сценарии эксплуатации

• Кража secrets: workflow, который имеет доступ к секретам (API ключи, креды от БД), запускает код, который вытаскивает эти данные и отправляет их наружу.
• Латеральное перемещение: получение доступа к хосту, установка инструментов для дальнейшего перемещения по сети.
• Сабота: изменение конфигурации, удаление данных, подмена webhook URL'ов для перехвата входящих сообщений.

Что делать сейчас — пошагово

Если n8n ещё не обновлён до 2.0.0, приоритет — быстро запатчить. Если апдейт возможен не сразу, есть рабочие обходы:

• Обновление до n8n 2.0.0 — устраняет уязвимость, делает новую реализацию native Python runner активной по умолчанию.
• Отключить Code Node полностью: установить переменную окружения NODES_EXCLUDE: ["n8n-nodes-base.code"].
• Отключить Python-вариант в Code Node: N8N_PYTHON_ENABLED=false.
• Включить task‑runner‑based Python sandbox: выставить N8N_RUNNERS_ENABLED и N8N_NATIVE_PYTHON_RUNNER.

Эти шаги снижают риск, но не заменяют полноценного апдейта и ревью прав доступа.

Глубже: WebAssembly vs OS‑изоляция

WebAssembly даёт изоляцию на уровне рантайма, но не всегда контролирует мосты в хостовое окружение. Встроенные «песочницы» хороши для браузера и клиентских сценариев, но в серверных приложениях лучше комбинировать уровни защиты:

• контейнеризация (Docker, Kubernetes) с ограничениями прав и капабильностей;
• AppArmor/SELinux для предотвращения неожиданных вызовов;
• seccomp профили, ограничения syscalls;
• использование нативных «runner'ов», изолированных процессах или отдельном VM (Firecracker, gVisor) для запуска пользовательского кода.

Пример: вместо запуска всех workflows в едином процессе n8n, выделять task‑runner'ы в отдельные контейнеры с read‑only FS, без сетевых прав на внешние сервисы по умолчанию и с минимальным набором linux capabilities.

Оперативные рекомендации для DevOps и SecOps

• Принцип «минимальных привилегий»: роли в n8n, RBAC в Kubernetes, отдельные сервисные аккаунты для интеграций.
• Изоляция исполнения: запуск Python кода в sandbox или в отдельных контейнерах, ограничение CPU и RAM.
• Сеть по умолчанию — закрыта: egress‑политики, белые списки доменов для исходящих запросов.
• Секреты хранятся во внешнем vault’е, а не в workflow’ах (HashiCorp Vault, AWS Secrets Manager).
• Мониторинг аномалий: всплески новых процессов, неожиданные соединения, активность CLI на хосте.
• Регулярный аудит плагинов и кастомных node'ов: сторонние модули — потенциальный источник уязвимостей.

Детекция и реакция на инцидент

Если подозрение на эксплуатацию — действовать быстро:

• изолировать инстанс (остановить контейнер/VM);
• заблокировать все внешние ключи, выданные через n8n-проекты, и поменять креды;
• снять логи workflow, системные логи, docker inspect, список процессов; сохранить артефакты;
• провести форензик: какие команды запускались, какие файлы созданы/изменены, какие соединения установлены;
• сообщить заинтересованным сторонам и, при необходимости, регулятору — в зависимости от бизнеса и требования по уведомлениям.

Что это говорит о трендах безопасности低‑code/no‑code

Платформы low‑code/no‑code растут. Они расширяют круг людей, которые могут создавать автоматизацию, но одновременно расширяют поверхность атаки. Встраивание исполнения произвольного кода в пользовательские workflows — удобство, которое требует продуманной архитектуры изоляции.

Параллельно растёт интерес к WebAssembly как к средству запуска кода в изолированном виде. Однако реальный уровень безопасности зависит не от наличия WebAssembly, а от того, как реализованы мосты к хосту и какие ограничения наложены на сам рантайм.

Сравнение подходов изоляции

• WebAssembly/Pyodide: быстрый запуск, лёгкая интеграция, но потенциально сложные границы безопасности.
• Отдельные OS‑процессы: проще применять системные политики, но выше накладные расходы.
• Контейнеры: гибкий компромисс, хорошо сочетается с Kubernetes и позволяет использовать сетевые политики, seccomp и cgroups.
• Микро‑VM (Firecracker): почти нативная безопасность VM с малой накладной — отличный выбор для мульти‑тенантных сред.

Практические шаги для архитекторов

• переосмыслить модель исполнения пользовательского кода: явно разделять runtime для trusted и untrusted tasks;
• ввести автоматическое сканирование workflow при коммите: запрет на использование Code Node в общедоступных flow;
• внедрить тесты безопасности для интеграций — в CI/CD; каждая новая node должна проходить security review;
• планировать откат и резервные копии: обновления должны быть тестируемыми и откатываемыми без потери данных.

Производственный пример

Представим e‑commerce: webhook от платёжного шлюза поступает в n8n, запускает workflow, который обновляет ERP и отправляет письмо. В workflow есть Code Node, который преобразует данные. Злоумышленник, имея доступ к редактированию workflow, добавляет код, который отправляет локальный файл с базой куки на внешний сервер. Если n8n запускается с правами доступа к смонтированным томам и секретам, утечка неизбежна.

Эксцель: минимизировать риски

Апдейт до 2.0.0 и включение task‑runner native Python — первый и главный шаг. Дальше — регулярный ревью архитектуры исполнения, ужесточение сетевых политик, хранение секретов вне платформы и мониторинг подозрительной активности. Для тех, кто использует отечественные дистрибутивы, можно рассмотреть развёртывание в образах НАЙС.ОС Cloud, где доступны готовые решения для виртуальных машин и контейнеров.

Короткие рекомендации по чек‑листу

• Обновить n8n до 2.0.0.
• Если срочно — отключить Code Node или Python в нём.
• Включить native task runners (N8N_RUNNERS_ENABLED, N8N_NATIVE_PYTHON_RUNNER).
• Ограничить права пользователей, аудитировать workflows.
• Применить контейнерные и kernel‑уровневые политики (seccomp, AppArmor/SELinux).
• Ревизия внешних node'ов и интеграций.

И напоследок — вопросы к сообществу

Какие у вас практики изоляции пользовательского кода в автоматизационных платформах? Сталкивались ли вы с необходимостью отключать элементы функциональности ради безопасности — и как это повлияло на бизнес‑процессы? Какие trade‑offs между удобством и безопасностью вы считаете приемлемыми при работе с low‑code системами?