Обход каталогов в n8n позволяет выполнить код, а узел Snowflake допускает чтение и запись файлов

В платформе автоматизации рабочих процессов n8n нашли две уязвимости высокого уровня опасности. Первая использует обход каталогов в загрузчике схем узлов и ведёт к выполнению кода в основном процессе приложения. Вторая затрагивает узел Snowflake и позволяет произвольно читать и записывать файлы на хосте. Для эксплуатации обеих достаточно учётной записи с минимальными привилегиями.

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

n8n - платформа с открытым исходным кодом для интеграции приложений и автоматизации рутинных задач. Компании применяют её в среднем и крупном бизнесе, где через неё проходят процессы обработки данных. Узлы в n8n представляют собой готовые блоки для отдельных операций. Они отправляют запросы, трансформируют информацию и взаимодействуют с внешними сервисами. Схема узла описывает его параметры и интерфейс. Именно в механизме загрузки таких схем кроется первая проблема.

Компонент загрузки схем формирует путь к модулю напрямую из строки с типом узла. Эта строка поступает от пользователя, и система не проверяет её на наличие последовательностей обхода каталогов. В итоге аутентифицированный пользователь с ролью global:member, то есть минимальным уровнем доступа, может указать ссылку на произвольный файл в файловой системе. Система загрузит этот файл как схему узла, а его содержимое обработает основной процесс n8n. Такой сценарий ведёт к выполнению произвольного кода на сервере. Основной процесс управляет всеми рабочими процессами и часто работает с расширенными правами, поэтому последствия могут выходить далеко за пределы отдельного узла. По сути, уязвимость использует штатный механизм загрузки схем для доставки вредоносного кода.

Вторая уязвимость находится в узле Snowflake, который предназначен для взаимодействия с одноимённым облачным хранилищем данных. Узел передаёт пользовательский запрос в комплект разработчика Snowflake без проверки на соответствие ограничениям доступа к файлам. Это касается и клиентских команд, которые работают локально, а не в облаке. Такие команды служат для работы с локальными файлами, например для загрузки данных в хранилище. В обычном сценарии n8n ограничивает доступ к файловой системе, но в этом случае ограничения не действуют. Пользователь с учётными данными Snowflake может загрузить файл с хоста n8n. Перезапись существующего файла также возможна. В результате появляется риск утечки конфиденциальных данных и нарушения целостности системы.

Обе уязвимости получили оценку High по шкале CVSS v4. Вектор атаки сетевой, сложность низкая, особые условия эксплуатации не требуются. Взаимодействие с пользователем не нужно, а необходимый уровень привилегий низкий. Влияние на конфиденциальность, целостность и доступность высокое. При этом последующее воздействие на другие системы отсутствует. Такой профиль делает уязвимости привлекательными для атакующих, которые уже имеют доступ к учётной записи в n8n. Поскольку обе проблемы эксплуатируются удалённо, они не требуют физического доступа к серверу. Классификаторы CWE, описывающие типы уязвимостей, для этих проблем также отсутствуют, что затрудняет автоматическую категоризацию в некоторых сканерах безопасности.

Эти проблемы важны для организаций, которые используют n8n в производственных сценариях. Платформа автоматизирует бизнес-процессы и интегрирует десятки внешних сервисов, поэтому она часто работает на серверах с доступом к внутренним системам. Уязвимости позволяют низкопривилегированному пользователю выйти за пределы изолированной среды. Далее он может воздействовать на основную операционную систему. Особенно рискованна ситуация, когда процесс n8n работает под административной учётной записью. В таком случае выполнение кода в основном процессе означает практически полный контроль над сервером. Следовательно, администраторам стоит пересмотреть права учётных записей и модель доступа к платформе. Для компаний это означает риск остановки процессов, утечки информации и компрометации серверов.

Разработчики устранили проблемы в версиях 1.123.69, 2.33.4 и 2.34.1. Пользователям следует обновиться до одной из этих версий или более поздней. Версии 1.x, 2.33.x и 2.34.x представляют разные ветки, поэтому администраторам важно свериться с документацией проекта при планировании обновления. Если обновление невозможно немедленно, стоит применить временные меры. Доступ к экземпляру n8n следует ограничить только полностью доверенными пользователями. При отсутствии необходимости лучше отключить MCP - механизм, который подключает к n8n внешние модели и инструменты через стандартизированный протокол. Узел Snowflake можно исключить из конфигурации с помощью переменной окружения. Кроме того, стоит запускать процесс n8n под отдельной учётной записью операционной системы с минимальными привилегиями. Эти меры снижают риск, однако не устраняют его полностью.

Примечательно, что проект не получил идентификаторы CVE для обеих уязвимостей. Раскрытие информации произошло через систему безопасности GitHub, где n8n использует собственные идентификаторы. Сообщения вышли в базе GitHub Security Advisories, которая служит источником данных для многих сканеров уязвимостей. Отсутствие CVE может усложнить отслеживание проблемы в корпоративных системах управления уязвимостями, которые полагаются на стандартные реестры. Тем не менее это не влияет на необходимость обновления.

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

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

Ссылки