Исследователи проверили публичные коммиты GitHub начиная с апреля 2025 года и обнаружили 4576 уникальных API-токенов n8n в 5469 коммитах. Рядом с ними находились адреса 1255 уникальных хостов. На момент проверки 896 экземпляров n8n отвечали через интернет, причем 321 из них принял хотя бы один скомпрометированный токен. Это около 36% доступных экземпляров и 26% всех найденных хостов. Для проверки использовался один запрос только на чтение: GET /api/v1/workflows с заголовком X-N8N-API-KEY: <token>. Ответ HTTP 200 означал успешную аутентификацию, HTTP 401 указывал на недействительный либо удаленный из базы ключ или ошибку проверки подписи, HTTP 404 мог означать отключенный публичный API. Никакие данные на чужих серверах при такой проверке не изменялись.
n8n представляет собой открытую low-code-платформу автоматизации рабочих процессов с поддержкой ИИ-агентов и сотнями встроенных интеграций. Ее разворачивают самостоятельно или через , а репозиторий проекта набрал почти 200 000 звезд GitHub. Рабочий процесс состоит из узлов, которые запускаются по расписанию или вебхуку, преобразуют данные, исполняют JavaScript и Python, отправляют SQL-запросы и обращаются к внешним сервисам. API-ключи, токены и пароли баз данных хранятся в зашифрованном виде с мастер-секретом N8N_ENCRYPTION_KEY, но во время исполнения n8n неизбежно расшифровывает их. Поэтому доступ к платформе порой означает доступ к репозиториям исходного кода, базам данных, облакам, ИИ-сервисам, системам поддержки клиентов и внутренним приложениям.
Через Shodan было видно более 100 000 экземпляров n8n. С января 2026 года опубликовано свыше 50 уведомлений о безопасности, а на 31 марта 2026 года 58% проверенных серверов работали на версии, затронутой хотя бы одной известной проблемой. Среди найденных ранее уязвимостей были способы выйти из песочницы исполнения и получить произвольный доступ на чтение или запись к файловой системе хоста. Уязвимость внедрения выражений CVE-2025-68613 получила 9,9 балла по шкале CVSS; 11 марта 2026 года Агентство по кибербезопасности и защите инфраструктуры США, CISA, внесло ее в каталог Known Exploited Vulnerabilities, подтвердив эксплуатацию в реальных атаках. Но украденный API-ключ делает поиск CVE необязательным: штатные полномочия уже могут дать атакующему все необходимое.
Отдельно проверялись ключи n8n Model Context Protocol, или MCP, позволяющие ИИ-помощникам вызывать рабочие процессы по этому протоколу. Среди тех же коммитов нашлось 372 MCP-токена, семь из них, то есть примерно 2%, продолжали работать. Обычный API-ключ n8n имеет формат подписанного JSON Web Token. В разобранном примере присутствовали поля sub: «efdf9cca-049a-46aa-afdc-172f0824f6cb», iss: «n8n», aud: «public-api», jti: «aac8a7a8-c8c4-4855-8e8b-2806e90b16e1» и iat: 1781551662. Здесь sub обозначает связанную учетную запись, iss — издателя, aud — назначение токена, jti — его уникальный идентификатор, iat — время выпуска. Старые ключи часто не содержали exp, то есть срока действия. Автоматическое истечение через 30 дней появилось лишь в версии 1.78.0, выпущенной в феврале 2025 года. При этом одного корректного JWT недостаточно: ключ должен оставаться в базе n8n. Если его не удалить и не отозвать, попавший на GitHub токен способен работать месяцами.
Адрес сервера обычно лежал в том же коммите. Типичная пара выглядела как N8N_URL=" " и N8N_API_KEY="eyJhREDACTEDPWw4". В файлах разрешений Claude Code,.claude/settings.json и.claude/settings.local.json, встречались заранее одобренные команды наподобие Bash(curl -s " " -H "X-N8N-API-KEY: eyJhREDACTEDegE"). Такие файлы реже включают в.gitignore, чем привычный.env. Те же сведения публиковались под именами N8N_MCP_URL, N8N_WEBHOOK_BASE_URL, process.env.N8N_URL и os.getenv("N8N_HOST", "...»). Отдельно искать инфраструктуру исследователям фактически не пришлось.
Полномочия токена зависят от создавшего его пользователя, однако среди утечек часто попадались ключи владельцев и администраторов, которые сами настраивали интеграции. GET /api/v1/users способен вернуть имена, электронную почту, даты создания аккаунтов и ожидающие приглашения; часть сведений доступна лишь владельцу. GET /api/v1/workflows выдает полные схемы процессов с настройками узлов, кодом JavaScript и Python, SQL-запросами и секретами, записанными прямо в параметры. GET /api/v1/credentials показывает названия, типы, идентификаторы и сведения о совместном использовании учетных данных, хотя не возвращает их содержимое; этот метод ограничен владельцами и администраторами. GET /api/v1/executions?includeData=true может раскрыть полные входные и выходные данные запусков, GET /api/v1/data-tables — доступные строки внутренних таблиц, GET /api/v1/variables — имена и содержимое переменных, также только для владельцев и администраторов. Самая простая добыча здесь — секреты, которые разработчик вписал в параметры узла открытым текстом.
Встроенный аудит n8n при наличии подходящих прав превращается в готовую карту атаки. Его отчет перечисляет возможные SQL-инъекции в процессах, узлы с доступом к файловой системе, незащищенные вебхуки, установленную версию n8n и подходящие к ней CVE. Там же можно увидеть неиспользуемые учетные данные, рискованные и установленные сообществом узлы, включенные защитные функции, списки разрешенных и заблокированных узлов, настройки телеметрии. Администратору эти сведения нужны для проверки системы, постороннему с утекшим привилегированным токеном — для выбора наиболее короткого пути к данным.
Пример рабочего процесса n8n был собран в отдельной контролируемой среде с тремя намеренными слабостями. Веб-форма записывала ответы во внутреннюю таблицу; узел OpenAI обрабатывал каждую запись через сохраненный объект учетных данных; узел HTTP Request публиковал результат на GitHub, причем GitHub-токен находился прямо в параметрах. Первая из четырех проверенных техник ограничилась чтением: GET /api/v1/users вернул четыре аккаунта — одного владельца, двух активных пользователей и одну ожидающую регистрацию. GET /api/v1/workflows раскрыл девять полных процессов. В одном из них исследователи сразу увидели GitHub-токен открытым текстом. Создавать или менять процессы для этого не понадобилось.
Во второй технике GET /api/v1/credentials обнаружил объект «Учетная запись OpenAI», показав его название, тип и идентификатор, но не сам API-ключ. Исследователи создали процесс из триггера Schedule и узла OpenAI, связали узел с найденным объектом и активировали схему. Примерно через 10 секунд Schedule сработал автоматически. Затем GET /api/v1/executions?includeData=true вернул полную запись исполнения, поскольку n8n сохранял результат каждого узла, включая ответ OpenAI в открытом виде. Так удалось отправлять произвольные запросы за счет чужой учетной записи OpenAI, ни разу не увидев исходный секрет.
Третья техника использовала тот же Schedule и узел Data Table, настроенный на чтение всех строк. Через несколько секунд журнал исполнения выдал четыре записи с именами, адресами электронной почты, ответами из формы и статусами обработки; после получения данных процесс удалили. В четвертой технике извлекли уже сам ключ OpenAI. Исследователи запустили HTTP-приемник и создали процесс с Schedule и HTTP Request, указав сохраненную учетную запись OpenAI как способ аутентификации, а свой сервер — как произвольный адрес назначения. При запуске n8n добавил секрет в виде Bearer-токена в исходящий заголовок Authorization. Приемник получил сырой API-ключ через несколько секунд, после чего процесс удалили. Все четыре приема опирались на документированный REST API, обычные HTTP-запросы и штатное поведение n8n, без эксплуатации CVE и специальных атакующих инструментов.
Цепочка начиналась с перечисления пользователей, процессов и настроек безопасности, продолжалась поиском сохраненных объектов и зашитых секретов, а заканчивалась чтением внутренних данных, использованием чужих учетных записей и отправкой их исходных значений наружу. Удаление вредоносного процесса убирало из интерфейса и связанные с ним записи исполнения, оставляя внутри n8n мало материала для расследования. Похожая ошибка нашлась в реальной резервной копии на публичном GitHub: процесс автоматически выгружал туда собственные определения, а в одном узле был жестко прописан SSH-ключ развертывания. История Git содержала прежние версии всех процессов, и SSH-ключ по-прежнему работал. Каждый запуск, по сути, снова публиковал конфигурацию и учетные данные.
Исследователи пытались уведомить семь организаций: трех хостинг-провайдеров, вместе обслуживавших около 100 затронутых экземпляров, и четыре отдельные компании. Один провайдер не ответил; без ответа остались и три из четырех компаний. Единственная компания с программой bug bounty подтвердила проблему, сразу отозвала ключ и выплатила 1200 долларов. n8n признала получение сообщений, заявила, что знает о проблемах и планирует заняться ими, а затем закрыла отчеты. Примерно 30% из 321 подтвержденного экземпляра размещались в или похожих управляемых сервисах. В исходном рекламном описании неназванный продукт обещал определять контекст и радиус поражения утекших ключей, массово запускать исправление до превращения секрета в путь атаки и заявлял о доверии более 600 000 разработчиков и предприятий, включая Snowflake, ING, BASF, Datadog, Qlik, Euronext и Orange.
После обнаружения утечки недостаточно отозвать один токен n8n. Нужно установить, какие процессы видел скомпрометированный аккаунт, какие таблицы, переменные, вебхуки, входные данные и результаты запусков ему были доступны, а затем проверить создание, активацию, изменение и удаление процессов. Следует сопоставить журналы n8n с внешними логами, найти секреты в параметрах узлов, перечислить все доступные аккаунту объекты учетных данных и сменить ключи подключенных систем, если их использование или извлечение нельзя исключить. В область расследования входят GitHub и другие репозитории, базы данных, облачные среды, OpenAI и прочие ИИ-API, платформы поддержки, клиентские данные и внутренние сервисы: один действующий токен автоматизации дает доступ не к одному приложению, а к связям между ними.
Изображение носит иллюстративный характер
n8n представляет собой открытую low-code-платформу автоматизации рабочих процессов с поддержкой ИИ-агентов и сотнями встроенных интеграций. Ее разворачивают самостоятельно или через , а репозиторий проекта набрал почти 200 000 звезд GitHub. Рабочий процесс состоит из узлов, которые запускаются по расписанию или вебхуку, преобразуют данные, исполняют JavaScript и Python, отправляют SQL-запросы и обращаются к внешним сервисам. API-ключи, токены и пароли баз данных хранятся в зашифрованном виде с мастер-секретом N8N_ENCRYPTION_KEY, но во время исполнения n8n неизбежно расшифровывает их. Поэтому доступ к платформе порой означает доступ к репозиториям исходного кода, базам данных, облакам, ИИ-сервисам, системам поддержки клиентов и внутренним приложениям.
Через Shodan было видно более 100 000 экземпляров n8n. С января 2026 года опубликовано свыше 50 уведомлений о безопасности, а на 31 марта 2026 года 58% проверенных серверов работали на версии, затронутой хотя бы одной известной проблемой. Среди найденных ранее уязвимостей были способы выйти из песочницы исполнения и получить произвольный доступ на чтение или запись к файловой системе хоста. Уязвимость внедрения выражений CVE-2025-68613 получила 9,9 балла по шкале CVSS; 11 марта 2026 года Агентство по кибербезопасности и защите инфраструктуры США, CISA, внесло ее в каталог Known Exploited Vulnerabilities, подтвердив эксплуатацию в реальных атаках. Но украденный API-ключ делает поиск CVE необязательным: штатные полномочия уже могут дать атакующему все необходимое.
Отдельно проверялись ключи n8n Model Context Protocol, или MCP, позволяющие ИИ-помощникам вызывать рабочие процессы по этому протоколу. Среди тех же коммитов нашлось 372 MCP-токена, семь из них, то есть примерно 2%, продолжали работать. Обычный API-ключ n8n имеет формат подписанного JSON Web Token. В разобранном примере присутствовали поля sub: «efdf9cca-049a-46aa-afdc-172f0824f6cb», iss: «n8n», aud: «public-api», jti: «aac8a7a8-c8c4-4855-8e8b-2806e90b16e1» и iat: 1781551662. Здесь sub обозначает связанную учетную запись, iss — издателя, aud — назначение токена, jti — его уникальный идентификатор, iat — время выпуска. Старые ключи часто не содержали exp, то есть срока действия. Автоматическое истечение через 30 дней появилось лишь в версии 1.78.0, выпущенной в феврале 2025 года. При этом одного корректного JWT недостаточно: ключ должен оставаться в базе n8n. Если его не удалить и не отозвать, попавший на GitHub токен способен работать месяцами.
Адрес сервера обычно лежал в том же коммите. Типичная пара выглядела как N8N_URL=" " и N8N_API_KEY="eyJhREDACTEDPWw4". В файлах разрешений Claude Code,.claude/settings.json и.claude/settings.local.json, встречались заранее одобренные команды наподобие Bash(curl -s " " -H "X-N8N-API-KEY: eyJhREDACTEDegE"). Такие файлы реже включают в.gitignore, чем привычный.env. Те же сведения публиковались под именами N8N_MCP_URL, N8N_WEBHOOK_BASE_URL, process.env.N8N_URL и os.getenv("N8N_HOST", "...»). Отдельно искать инфраструктуру исследователям фактически не пришлось.
Полномочия токена зависят от создавшего его пользователя, однако среди утечек часто попадались ключи владельцев и администраторов, которые сами настраивали интеграции. GET /api/v1/users способен вернуть имена, электронную почту, даты создания аккаунтов и ожидающие приглашения; часть сведений доступна лишь владельцу. GET /api/v1/workflows выдает полные схемы процессов с настройками узлов, кодом JavaScript и Python, SQL-запросами и секретами, записанными прямо в параметры. GET /api/v1/credentials показывает названия, типы, идентификаторы и сведения о совместном использовании учетных данных, хотя не возвращает их содержимое; этот метод ограничен владельцами и администраторами. GET /api/v1/executions?includeData=true может раскрыть полные входные и выходные данные запусков, GET /api/v1/data-tables — доступные строки внутренних таблиц, GET /api/v1/variables — имена и содержимое переменных, также только для владельцев и администраторов. Самая простая добыча здесь — секреты, которые разработчик вписал в параметры узла открытым текстом.
Встроенный аудит n8n при наличии подходящих прав превращается в готовую карту атаки. Его отчет перечисляет возможные SQL-инъекции в процессах, узлы с доступом к файловой системе, незащищенные вебхуки, установленную версию n8n и подходящие к ней CVE. Там же можно увидеть неиспользуемые учетные данные, рискованные и установленные сообществом узлы, включенные защитные функции, списки разрешенных и заблокированных узлов, настройки телеметрии. Администратору эти сведения нужны для проверки системы, постороннему с утекшим привилегированным токеном — для выбора наиболее короткого пути к данным.
Пример рабочего процесса n8n был собран в отдельной контролируемой среде с тремя намеренными слабостями. Веб-форма записывала ответы во внутреннюю таблицу; узел OpenAI обрабатывал каждую запись через сохраненный объект учетных данных; узел HTTP Request публиковал результат на GitHub, причем GitHub-токен находился прямо в параметрах. Первая из четырех проверенных техник ограничилась чтением: GET /api/v1/users вернул четыре аккаунта — одного владельца, двух активных пользователей и одну ожидающую регистрацию. GET /api/v1/workflows раскрыл девять полных процессов. В одном из них исследователи сразу увидели GitHub-токен открытым текстом. Создавать или менять процессы для этого не понадобилось.
Во второй технике GET /api/v1/credentials обнаружил объект «Учетная запись OpenAI», показав его название, тип и идентификатор, но не сам API-ключ. Исследователи создали процесс из триггера Schedule и узла OpenAI, связали узел с найденным объектом и активировали схему. Примерно через 10 секунд Schedule сработал автоматически. Затем GET /api/v1/executions?includeData=true вернул полную запись исполнения, поскольку n8n сохранял результат каждого узла, включая ответ OpenAI в открытом виде. Так удалось отправлять произвольные запросы за счет чужой учетной записи OpenAI, ни разу не увидев исходный секрет.
Третья техника использовала тот же Schedule и узел Data Table, настроенный на чтение всех строк. Через несколько секунд журнал исполнения выдал четыре записи с именами, адресами электронной почты, ответами из формы и статусами обработки; после получения данных процесс удалили. В четвертой технике извлекли уже сам ключ OpenAI. Исследователи запустили HTTP-приемник и создали процесс с Schedule и HTTP Request, указав сохраненную учетную запись OpenAI как способ аутентификации, а свой сервер — как произвольный адрес назначения. При запуске n8n добавил секрет в виде Bearer-токена в исходящий заголовок Authorization. Приемник получил сырой API-ключ через несколько секунд, после чего процесс удалили. Все четыре приема опирались на документированный REST API, обычные HTTP-запросы и штатное поведение n8n, без эксплуатации CVE и специальных атакующих инструментов.
Цепочка начиналась с перечисления пользователей, процессов и настроек безопасности, продолжалась поиском сохраненных объектов и зашитых секретов, а заканчивалась чтением внутренних данных, использованием чужих учетных записей и отправкой их исходных значений наружу. Удаление вредоносного процесса убирало из интерфейса и связанные с ним записи исполнения, оставляя внутри n8n мало материала для расследования. Похожая ошибка нашлась в реальной резервной копии на публичном GitHub: процесс автоматически выгружал туда собственные определения, а в одном узле был жестко прописан SSH-ключ развертывания. История Git содержала прежние версии всех процессов, и SSH-ключ по-прежнему работал. Каждый запуск, по сути, снова публиковал конфигурацию и учетные данные.
Исследователи пытались уведомить семь организаций: трех хостинг-провайдеров, вместе обслуживавших около 100 затронутых экземпляров, и четыре отдельные компании. Один провайдер не ответил; без ответа остались и три из четырех компаний. Единственная компания с программой bug bounty подтвердила проблему, сразу отозвала ключ и выплатила 1200 долларов. n8n признала получение сообщений, заявила, что знает о проблемах и планирует заняться ими, а затем закрыла отчеты. Примерно 30% из 321 подтвержденного экземпляра размещались в или похожих управляемых сервисах. В исходном рекламном описании неназванный продукт обещал определять контекст и радиус поражения утекших ключей, массово запускать исправление до превращения секрета в путь атаки и заявлял о доверии более 600 000 разработчиков и предприятий, включая Snowflake, ING, BASF, Datadog, Qlik, Euronext и Orange.
После обнаружения утечки недостаточно отозвать один токен n8n. Нужно установить, какие процессы видел скомпрометированный аккаунт, какие таблицы, переменные, вебхуки, входные данные и результаты запусков ему были доступны, а затем проверить создание, активацию, изменение и удаление процессов. Следует сопоставить журналы n8n с внешними логами, найти секреты в параметрах узлов, перечислить все доступные аккаунту объекты учетных данных и сменить ключи подключенных систем, если их использование или извлечение нельзя исключить. В область расследования входят GitHub и другие репозитории, базы данных, облачные среды, OpenAI и прочие ИИ-API, платформы поддержки, клиентские данные и внутренние сервисы: один действующий токен автоматизации дает доступ не к одному приложению, а к связям между ними.
