Уязвимость в n8n позволяет выполнить код на хосте через Git-узел

n8n

Платформа для автоматизации рабочих процессов n8n получила обновления, закрывающие уязвимость высокой степени опасности. Проблема позволяет аутентифицированному пользователю, имеющему права на создание и запуск рабочих процессов, выполнить произвольные команды на сервере через встроенный Git-узел.

Детали уязвимости

Согласно бюллетеню безопасности, опубликованному разработчиком, уязвимость затрагивает версии n8n до 1.123.67, до 2.31.5 и до 2.32.1. Исправления выпущены в перечисленных версиях и более новых. Проблеме присвоен статус High (высокая степень опасности) без указания конкретного балла по шкале CVSSv4, однако метрики указывают на сетевой вектор атаки, низкую сложность, отсутствие требований к взаимодействию с пользователем и необходимость низких привилегий.

Суть уязвимости - в механизме работы Git-узла n8n. При стандартных настройках безопасности Git, злоумышленник, имеющий доступ к платформе, может подготовить локальный репозиторий таким образом, что при его добавлении будет активирован Git-хук (hook). Хуки - это скрипты, которые Git запускает автоматически на определённые события, например, при коммите или слиянии. В результате атакующий может выполнить произвольные команды от имени пользователя процесса n8n.

Уязвимость актуальна как для самостоятельно развёрнутых экземпляров (self-hosted), так и для облачных инстанций n8n, но только при условии, что у пользователя есть права на создание и выполнение рабочих процессов, использующих Git-узел. Таким образом, угроза касается организаций, где доступ к платформе предоставлен не только администраторам, но и обычным сотрудникам или внешним участникам.

Потенциальные последствия эксплуатации включают полную компрометацию сервера n8n: чтение, изменение и удаление данных, установку вредоносного программного обеспечения, боковое перемещение внутри сети. Поскольку n8n часто используется для интеграции различных сервисов и автоматизации бизнес-процессов, утечка учётных данных или нарушение целостности рабочих процессов может привести к серьёзным операционным сбоям.

Разработчик рекомендует как можно скорее обновить платформу до исправленных версий. Если это невозможно, следует принять временные меры защиты. Ограничить доступ к экземпляру n8n только полностью доверенными пользователями. Отключить Git-узел, добавив "n8n-nodes-base.git" в переменную окружения "NODES_EXCLUDE". Также рекомендуется ограничить исходящий сетевой трафик с сервера n8n, чтобы снизить вероятность утечки данных при успешной атаке.

Эти меры не устраняют уязвимость полностью и должны рассматриваться лишь как краткосрочная защита до установки патча. Важно отметить, что в ряде конфигураций Git-узел может быть частью критически важных рабочих процессов, и его отключение потребует ручного переноса логики на другие механизмы.

Уязвимость обнаружена и описана исследователем csuermann. На момент публикации бюллетеня идентификатор CVE не присвоен, категории CWE (типы слабостей) также не указаны. Однако сама проблема относится к классу атак через цепочку поставок на уровне управления репозиторием - это не новый вектор, но его реализация через интерфейс no-code/low-code платформ создаёт дополнительный риск для пользователей, полагающихся на визуальные сценарии.

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

Пользователям n8n, особенно в крупных организациях, следует проверить версию своей платформы и, при необходимости, спланировать внеплановое обновление. Администраторам также стоит пересмотреть политику предоставления прав на создание рабочих процессов с узлами, связанными с исполнением внешнего кода - даже если на первый взгляд Git-узел кажется безопасным, его настройки по умолчанию могут быть неадекватны для многопользовательской среды с разными уровнями доверия.

Ссылки

Комментарии: 0