Платформа автоматизации n8n закрыла уязвимость, которая позволяла обычному пользователю с правами на создание workflow выполнять произвольные команды операционной системы прямо на сервере, где крутится сервис. Нашла дыру команда Security Joes — причём случайно, во время проверки февральского патча для другой уязвимости, CVE-2026-27577. Исследователи решили проверить, не осталась ли лазейка после того исправления, и лазейка нашлась.
Баг получил идентификатор GHSA-gv7g-jm28-cr3m и рейтинг High по шкале CVSS 4.0 — 8.7 балла. CVE на момент 27 июля 2026 года всё ещё не присвоен, хотя Security Joes изначально ждали оценку около 9.4, то есть Critical, по аналогии с февральским случаем. Вендор оценил риск чуть скромнее, но восьмёрка с копейками — это всё равно серьёзно для платформы, которая массово используется для интеграции сервисов и хранит учётные данные к базам, облакам и внутренним API.
Уязвимость касается версий младше 2.31.5, а также ветки от 2.32.0 до 2.32.1 не включительно. Исправление вышло в 2.31.5 и 2.32.1. Для линейки 1.x патча не выпустили — судя по всему, она уже не поддерживается. Отдельный вопрос, затронуло ли это n8n Cloud: в официальном advisory об этом ничего не сказано, что само по себе странно и оставляет пользователей облачной версии в неведении.
Чтобы воспользоваться дырой, нужен просто действующий аккаунт с правом создавать или редактировать workflow — никакого дополнительного взаимодействия с другими пользователями не требуется, никакой социальной инженерии. Атакующий получает возможность выполнять команды с привилегиями самого процесса n8n. А дальше, по оценке Security Joes, открывается путь к N8N_ENCRYPTION_KEY, расшифровке хранящихся в системе credentials и, соответственно, к базам данных, внутренним сервисам и облачным конечным точкам, к которым у n8n есть доступ. На момент публикации отчёта фактов эксплуатации в реальных атаках зафиксировано не было, и сам advisory не подтверждает, использовалась ли уязвимость до выпуска патча.
Техническая суть проблемы связана с тем, как n8n обрабатывает выражения внутри workflow — конструкции вроде ={{ $json.email }}, которые позволяют пользователям обращаться к данным прямо в интерфейсе. За безопасность этого механизма отвечает переписыватель абстрактного синтаксического дерева (AST), который должен перенаправлять свободные идентификаторы JavaScript в контролируемый контекст данных n8n, а не давать им доступ к настоящему окружению Node.js.
Здесь и обнаружились два independent недочёта. Первый: в версии 2.31.4 файл VariablePolyfill.ts содержал явную ветку-заглушку для ArrowFunctionExpression — то есть для стрелочных функций. Из-за этого лаконичная запись вроде () => process могла вернуть настоящий глобальный объект process из Node.js вместо песочницы. Второй недочёт касался проверки свойств: система n8n анализирует статические имена свойств в member-выражениях, но метод Reflect.get() получает запрашиваемое свойство как аргумент функции, а не как статическое имя — и потому проходит мимо этих проверок незамеченным. Комбинируя обе бреши, исследователи сначала восстановили доступ к process.getBuiltinModule, затем загрузили модуль child_process и выполнили команду на хосте.
В отчёте Security Joes есть точная формулировка, объясняющая, почему баг долго оставался незамеченным: «По отдельности ни одно из условий не достаточно. Ни то, ни другое не покрывалось тестами». Собственно, это и есть главная причина живучести подобных уязвимостей — разработчики закрывают одну дыру, не подозревая о существовании соседней, которая становится опасной только в комбинации.
Proof-of-concept тестировался на версии n8n 2.30.4 — как через официальный пакет workflow, так и на локально развёрнутом экземпляре платформы. Сравнение исходников публичных версий 2.31.4 и 2.31.5 подтверждает наличие именно первой проблемы, с пропуском стрелочных функций, но не даёт независимого подтверждения полной цепочки эксплуатации через Reflect.get() — это уже находка исследователей, воспроизведённая ими самостоятельно. В итоговом патче разработчики добавили отдельный обработчик для ArrowFunctionExpression, который теперь корректно направляет «голые» идентификаторы через контекст данных, а не позволяет им утекать в реальное окружение.
Хронология событий укладывается в полторы недели: 14 июля 2026 года Security Joes обнаружили остаточную брешь, на следующий день, 15 июля, сообщили о ней через программу раскрытия уязвимостей n8n. Уже 22 июля вышли исправленные релизы. К 27 июля, на момент проверки статуса, CVE всё ещё не был присвоен — довольно быстрый цикл реагирования для вендора, но с зависшим формальным учётом.
Что касается временных мер — n8n рекомендовал ограничить доступ к инстансу и редактированию workflow только полностью доверенным пользователям. Но в самом advisory эти меры прямо названы «неполными, краткосрочными мерами смягчения», то есть сам вендор не считает их достаточной защитой. Единственная реальная рекомендация — обновление до 2.31.5 или 2.32.1 без промедления.
Для администраторов, которые пока не могут обновиться немедленно, имеет смысл провести ручную проверку:
Для организаций, которые используют n8n с широкими привилегиями — хранят там ключи доступа к критичным системам или подключают платформу к внутренним сервисам, — риск вполне конкретный. Злоумышленник, получивший доступ к аккаунту с правом редактирования workflow, способен выполнить команды от имени процесса n8n и добраться до всего, что доступно с этого хоста по сети. Отчёт был передан изданию The Hacker News напрямую командой Security Joes.
Баг получил идентификатор GHSA-gv7g-jm28-cr3m и рейтинг High по шкале CVSS 4.0 — 8.7 балла. CVE на момент 27 июля 2026 года всё ещё не присвоен, хотя Security Joes изначально ждали оценку около 9.4, то есть Critical, по аналогии с февральским случаем. Вендор оценил риск чуть скромнее, но восьмёрка с копейками — это всё равно серьёзно для платформы, которая массово используется для интеграции сервисов и хранит учётные данные к базам, облакам и внутренним API.
Уязвимость касается версий младше 2.31.5, а также ветки от 2.32.0 до 2.32.1 не включительно. Исправление вышло в 2.31.5 и 2.32.1. Для линейки 1.x патча не выпустили — судя по всему, она уже не поддерживается. Отдельный вопрос, затронуло ли это n8n Cloud: в официальном advisory об этом ничего не сказано, что само по себе странно и оставляет пользователей облачной версии в неведении.
Чтобы воспользоваться дырой, нужен просто действующий аккаунт с правом создавать или редактировать workflow — никакого дополнительного взаимодействия с другими пользователями не требуется, никакой социальной инженерии. Атакующий получает возможность выполнять команды с привилегиями самого процесса n8n. А дальше, по оценке Security Joes, открывается путь к N8N_ENCRYPTION_KEY, расшифровке хранящихся в системе credentials и, соответственно, к базам данных, внутренним сервисам и облачным конечным точкам, к которым у n8n есть доступ. На момент публикации отчёта фактов эксплуатации в реальных атаках зафиксировано не было, и сам advisory не подтверждает, использовалась ли уязвимость до выпуска патча.
Техническая суть проблемы связана с тем, как n8n обрабатывает выражения внутри workflow — конструкции вроде ={{ $json.email }}, которые позволяют пользователям обращаться к данным прямо в интерфейсе. За безопасность этого механизма отвечает переписыватель абстрактного синтаксического дерева (AST), который должен перенаправлять свободные идентификаторы JavaScript в контролируемый контекст данных n8n, а не давать им доступ к настоящему окружению Node.js.
Здесь и обнаружились два independent недочёта. Первый: в версии 2.31.4 файл VariablePolyfill.ts содержал явную ветку-заглушку для ArrowFunctionExpression — то есть для стрелочных функций. Из-за этого лаконичная запись вроде () => process могла вернуть настоящий глобальный объект process из Node.js вместо песочницы. Второй недочёт касался проверки свойств: система n8n анализирует статические имена свойств в member-выражениях, но метод Reflect.get() получает запрашиваемое свойство как аргумент функции, а не как статическое имя — и потому проходит мимо этих проверок незамеченным. Комбинируя обе бреши, исследователи сначала восстановили доступ к process.getBuiltinModule, затем загрузили модуль child_process и выполнили команду на хосте.
В отчёте Security Joes есть точная формулировка, объясняющая, почему баг долго оставался незамеченным: «По отдельности ни одно из условий не достаточно. Ни то, ни другое не покрывалось тестами». Собственно, это и есть главная причина живучести подобных уязвимостей — разработчики закрывают одну дыру, не подозревая о существовании соседней, которая становится опасной только в комбинации.
Proof-of-concept тестировался на версии n8n 2.30.4 — как через официальный пакет workflow, так и на локально развёрнутом экземпляре платформы. Сравнение исходников публичных версий 2.31.4 и 2.31.5 подтверждает наличие именно первой проблемы, с пропуском стрелочных функций, но не даёт независимого подтверждения полной цепочки эксплуатации через Reflect.get() — это уже находка исследователей, воспроизведённая ими самостоятельно. В итоговом патче разработчики добавили отдельный обработчик для ArrowFunctionExpression, который теперь корректно направляет «голые» идентификаторы через контекст данных, а не позволяет им утекать в реальное окружение.
Хронология событий укладывается в полторы недели: 14 июля 2026 года Security Joes обнаружили остаточную брешь, на следующий день, 15 июля, сообщили о ней через программу раскрытия уязвимостей n8n. Уже 22 июля вышли исправленные релизы. К 27 июля, на момент проверки статуса, CVE всё ещё не был присвоен — довольно быстрый цикл реагирования для вендора, но с зависшим формальным учётом.
Что касается временных мер — n8n рекомендовал ограничить доступ к инстансу и редактированию workflow только полностью доверенным пользователям. Но в самом advisory эти меры прямо названы «неполными, краткосрочными мерами смягчения», то есть сам вендор не считает их достаточной защитой. Единственная реальная рекомендация — обновление до 2.31.5 или 2.32.1 без промедления.
Для администраторов, которые пока не могут обновиться немедленно, имеет смысл провести ручную проверку:
- []просмотреть недавно созданные или изменённые workflow на предмет неожиданных стрелочных функций и обфусцированного JavaScript-кода
[]поискать подозрительные дочерние процессы у n8n или Node.js — оболочки shell, PowerShell, curl, wget
[]при обнаружении признаков подозрительного выполнения workflow или команд на хосте — ротировать все credentials, к которым у платформы был доступ
Для организаций, которые используют n8n с широкими привилегиями — хранят там ключи доступа к критичным системам или подключают платформу к внутренним сервисам, — риск вполне конкретный. Злоумышленник, получивший доступ к аккаунту с правом редактирования workflow, способен выполнить команды от имени процесса n8n и добраться до всего, что доступно с этого хоста по сети. Отчёт был передан изданию The Hacker News напрямую командой Security Joes.