n8n допускает установку произвольных пакетов через очередь Redis и утечку токена сессии

Платформа автоматизации n8n закрывает две уязвимости высокой степени опасности - в механизме установки пакетов сообщества и в модуле динамических учётных данных. Первая даёт возможность выполнить произвольный код на всех узлах кластера, если развёртывание работает в режиме очереди с Redis. Вторая раскрывает токен сессии владельца или коллеги по общему рабочему процессу. Исправления вышли в версиях 1.123.80, 2.39.6 и 2.40.1, идентификаторы CVE ни одной из проблем не присвоены.

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

В режиме очереди n8n распределяет задачи между несколькими экземплярами через Redis - хранилище данных в оперативной памяти, которое часто используют как посредника для обмена сообщениями между сервисами. Внутренний обработчик установки пакетов сообщества не выполнял ни одной проверки, которые проходит обычный путь установки. Речь о проверке имени и префикса, разрешении на установку, сверке контрольной суммы и проверке безопасности самого пакета в реестре npm (реестр библиотек для JavaScript). Любой, у кого есть доступ на запись в Redis, мог заставить n8n скачать, установить и загрузить произвольный пакет на каждом узле кластера. Учётная запись n8n для этого не нужна, хотя обычно такие действия разрешены только владельцу инстанса.

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

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

Отдельного внимания обе проблемы заслуживают из-за отсутствия CVE-идентификаторов. Искать их в публичных базах уязвимостей бесполезно, ориентироваться приходится на версии и внутренние бюллетени вендора. Если обновление откладывается, администраторам стоит ограничить доступ к Redis только доверенными компонентами n8n: включить аутентификацию, закрыть хранилище правилами межсетевого экрана и вывести его в приватную сеть. Установку пакетов сообщества можно выключить, если они не используются, - для этого есть параметр N8N_COMMUNITY_PACKAGES_ENABLED=false. Полезно проверить список уже установленных пакетов и убрать всё незнакомое. Сам n8n тоже лучше открывать только доверенным сотрудникам.

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

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

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

Ссылки