Подпишись на наши каналы в телеграме и в Max, там ты найдешь огромное количество качественного контента, без инфошума и воды!
В начале 2026 года была опубликована критическая уязвимость в n8n.
Идентификатор: CVE-2026-21858
CVSS v.3.1: 10.0
Интересна здесь не столько оценка критичности, сколько сама причина уязвимости и как её можно проэксплуатировать. Всё начинается с обычного HTTP-заголовка Content-Type, но об этом чуть позже.
Что такое n8n?
n8n — это платформа автоматизации процессов, позволяющая собирать сценарии из блоков и связывать между собой разные системы. Например:
- Пользователь отправил форму -> данные сохранились-> отправилось письмо.
- Пришёл заказ -> обновилась БД -> отправилось уведомление.
Поэтому для обеспечения автоматизации n8n может:
- хранить API-ключи;
- хранить OAuth-токены;
- подключаться к базам данных;
- интегрироваться с десятками сервисов.
То есть это центральный узел автоматизации, через который проходит чувствительная информация и управление другими системами.
Как все начинается?
Любой сценарий автоматизации должен с чего-то начинаться. В n8n сценарий может запускаться через HTTP-endpoint, который принимает входящий запрос. Когда приходит запрос, сервер делает 3 вещи:
- Смотрит на заголовок Content-Type.
- В зависимости от него выбирает способ разбора тела запроса (выбирается парсер).
- Сохраняет результат сформированный парсером в req.body.
Если загружается файл, корректный вариант выглядит так:
Content-Type: multipart/form-data
В этом случае используется специальный парсер загрузки файлов. Он принимает файл и сохраняет его во временную директорию на сервере. Этот парсер безопасен в том смысле, что пользователь не может сам указать путь, куда будет сохранён файл.
Если же тип другой, например:
Content-Type: application/json
Используется обычный JSON-парсер. И вот здесь возникает проблема.
Что предполагала логика системы?
Дальше форма должна сохранить загруженный файл. Для этого в коде есть функция, которая берёт req.body.files, затем для каждого файла берёт filepath и копирует файл в постоянное хранилище n8n.
Разработчики исходили из предположения «Если мы обрабатываем файл, значит req.body.files сформирован безопасным загрузочным парсером». То есть структура считается доверенной, потому что её создал загрузочный парсер.
Рассмотрим, что происходит при корректной работе:
- Файл пришел как multipart/form-data
- Загрузочный парсер сохранил его во временную папку
- req.body.files[0].filepath указывает на /tmp/случайное_имя
- Код копирует этот временный файл в хранилище n8n
Теперь рассмотрим, что меняется при атаке.
Атакующий делает одну вещь – меняет Content-Type на application/json. Из-за этого сервер выбирает не загрузочный парсер, а обычный JSON-парсер. JSON-парсер просто разбирает текст запроса и записывает данные в req.body. И если в JSON есть поле:
{
"files": {
"0": {
"filepath": "/etc/passwd"
}
}
}
То после парсинга в памяти сервера будет:
req.body.files[0].filepath = "/etc/passwd"
Иллюстрирующий пример модификации запроса с помощью Burp Suite представлен на рисунке.
Важный момент в том, что код обработки запроса не проверяет, был ли файл действительно загружен через форму. Он лишь смотрит, существует ли в req.body поле files. Если такое поле есть, система считает данные корректными и открывает файл по указанному в filepath пути, копируя его в своё хранилище.
На данном этапе атакующий уже может читать любые файлы на сервере n8n. Однако чтение файлов ещё не является выполнением кода. Чтобы получить контроль над сервером, атакующему нужно обойти аутентификацию.
Как n8n понимает, что вы администратор?
Когда пользователь входит в систему, n8n создает cookie: n8n-auth. Эта cookie, по сути, представляет собой подписанное удостоверение и хранит идентификатор пользователя и часть SHA256-хэша от строки, составленной из email и значения пароля, которое хранится в базе данных (bcrypt-хэша). Всё это дополнительно подписывается секретным ключом.
Подпись создается с использованием секретного ключа, который хранится на сервере. Смысл её простой - если подпись корректная, значит cookie настоящая, а пользователь авторизован.
Для того чтобы можно было подделать подпись необходимо 2 вещи:
- Данные пользователя (id и хэш значение от [email + хранимый в базе хэш пароля])
- Секретный ключ, которым подписывается cookie
Вот для этого и пригодится чтение файлов.
Где лежит всё необходимое?
Если n8n развернут на собственном сервере, база данных и файл конфигурации по умолчанию хранятся на диске этой машины:
- База пользователей - /home/node/.n8n/database.sqlite
- Секретный ключ подписи хранится в конфигурационном файле - /home/node/.n8n/config
После чтения базы, атакующий находит запись администратора, формирует корректный payload (id + хэш), подписывает его секретным ключом и устанавливает эту cookie в браузере. После этого атакующий успешно авторизуется и ему становится доступен интерфейс администратора, где он может создавать, менять сценарии и просматривать учетные данные.
В n8n есть встроенный узел Execute Command, который позволяет выполнять команды операционной системы прямо из сценария. Всё, что указано в этом узле, выполняется так же, как если бы команду ввели вручную в терминале этой машины:
Таким образом, получив административный доступ к n8n, атакующий получает не просто доступ к интерфейсу управления сценариями, а возможность выполнять произвольные команды на сервере.
К счастью, описанная проблема уже исправлена разработчиками. Уязвимость CVE-2026-21858 устранена в версии n8n 1.121.0 и во всех более новых релизах. Чтобы исключить возможность её эксплуатации, необходимо обновиться до актуальной версии.
Эта уязвимость ещё раз показывает, что даже небольшая логическая ошибка в обработке входных данных может привести к компрометации системы. Поэтому к обновлениям и вопросам безопасности стоит относиться внимательно, регулярно отслеживать информацию о выявленных уязвимостях и своевременно переходить на версии, в которых они устранены.
В завершение отметим, что всем, кто интересуется статическим анализом исходного кода, практическими примерами и новостями в этой области, будет полезно подписаться на Telegram-канал.