321 сервер n8n принимал API-токены, утёкшие в публичные репозитории

GitGuardian обнаружила 4576 уникальных API-токенов n8n в публичных коммитах GitHub. Из 896 доступных для проверки серверов 321 продолжал принимать хотя бы один утёкший ключ, открывая доступ к рабочим процессам, данным и связанным учётным записям.

Исследователи проверили открытые коммиты, появившиеся с апреля 2025 года, и связали найденные ключи с 1255 адресами серверов. Это не уязвимость в коде n8n и не новый CVE: речь идёт о действующих реквизитах доступа, которые разработчики случайно оставили в публичных репозиториях. Из 896 доступных в момент проверки экземпляров 36% принимали хотя бы один скомпрометированный токен.

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

Отдельную опасность создают старые ключи. По данным исследователей, токены, выпущенные до версии n8n 1.78.0 в феврале 2025 года, могли не иметь срока действия и оставаться пригодными до ручного отзыва. Адрес сервера нередко попадал в тот же репозиторий вместе с ключом, что упрощало проверку украденных реквизитов.

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

Кроме обычных API-ключей обнаружены 372 токена для MCP-интеграций; семь из них оставались действующими. Около 30% затронутых экземпляров относились к n8n.cloud или похожим управляемым сервисам, поэтому проблема не ограничивается самостоятельно установленными серверами.

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