Витік API-токенів n8n відкрив доступ до 321 інстанса

GitGuardian виявила 321 доступний інстанс n8n, який усе ще приймав API-токени з публічних GitHub-комітів. Дійсні ключі могли відкрити workflows, executions, variables, data tables та відомості про збережені credentials. Це не експлуатація вразливості програми: для переходу межі API було достатньо чинного викраденого ключа.

Дослідники знайшли 4 576 унікальних API-токенів n8n у 5 469 комітах і пов’язали їх із 1 255 hostnames. Із 896 доступних під час перевірки інстансів 321 прийняв принаймні один розкритий токен. Адміністратор має негайно відкликати такий ключ, а потім визначити, до яких workflows і підключених сервісів він відкривав шлях.

Що показало дослідження токенів n8n

Число 321 означає, що ключі пройшли перевірку під час дослідження; воно не доводить зловмисний доступ до кожного інстанса. Водночас результат підтверджує: видалення секрету з поточної гілки або закриття репозиторію не робить недійсним токен, уже скопійований з історії Git.

Чому відкликання токена n8n — лише перший крок

Чинний API-ключ може відкрити більше, ніж назву інстанса. Документований API охоплює користувачів, визначення workflows і дані executions. Залежно від прав і конфігурації також можуть бути видимі data tables, variables, назви та типи credentials. У контрольованих тестах дослідники показали ще важливішу межу: той, хто може створити або змінити workflow, потенційно здатен змусити n8n використати збережений credential без показу його значення.

Тобто секрет можна застосувати через автоматизацію, навіть якщо його plaintext не повертається у відповіді API. Несанкціонований workflow може виконати автентифікований запит до зовнішньої системи, прочитати робочі дані або переслати їх назовні. Один workflow у наборі дослідження навіть містив hardcoded SSH deploy key і копіював себе до публічного репозиторію.

Відкликання закриває сесію витеклого API-токена n8n, але не скасовує попередню зміну workflow і не відкликає downstream OAuth grants, cloud keys, паролі баз, webhook secrets або deploy keys. Схожий принцип діяв після викрадення developer-токенів у кампанії з Keyv: спочатку потрібно прибрати активний механізм, а потім змінювати credentials і перевіряти зміни в репозиторіях чи автоматизаціях.

Де залишалися розкриті ключі

GitGuardian пов’язала токени з публічними комітами, зокрема з environment files та конфігурацією AI-асистентів на кшталт .claude/settings.json. Видалення рядка в наступному коміті не очищає попередні Git objects, forks, clones, caches або індекси secret-scanning систем. Будь-який production token, що потрапив у commit, слід вважати скомпрометованим.

Старі API-ключі n8n можуть працювати довго. За даними дослідження, типове завершення дії через 30 днів з’явилося в n8n 1.78.0 у лютому 2025 року, тоді як раніше створені ключі можуть не мати поля expiration. Короткий строк дії зменшує майбутній ризик, але не замінює відкликання відомого витоку.

Чотири стани доказів, які не слід змішувати

1. Токен є в репозиторії. Секрет публічний або був публічним, але відповідний інстанс може вже не існувати.
2. Токен проходить перевірку. Ключ відкриває чинний інстанс і потребує відкликання, однак сама валідація не доводить зловмисного використання.
3. Видно несанкціонований доступ. У журналах є невідомі API calls, перегляди workflows або отримання execution data.
4. Змінено workflow або використано downstream-доступ. Хтось створив автоматизацію, запустив дію з credential, експортував дані чи застосував секрет поза n8n.

Фіксуйте найвищий стан, підтверджений доказами. Назвати кожен commit підтвердженим зламом — перебільшення; завершити розслідування одразу після відкликання ключа — недооцінити можливі наслідки.

Порядок реагування на витік ключа n8n

1. Збережіть докази до очищення. Зафіксуйте історію repository, результат n8n audit, журнали reverse proxy й застосунку, execution history, список users та метадані workflows.
2. Відкличте всі розкриті n8n API і MCP tokens. Не чекайте переписування Git history та перевірте, що старі значення більше не автентифікуються.
3. Проскануйте всю історію Git. Перевірте branches, tags, pull-request refs, forks, build artifacts, backups і developer clones, а не лише default branch.
4. Виконайте аудит інстанса як owner. Запустіть офіційний n8n security audit і перевірте users, активні та вимкнені workflows, executions, variables, data tables, community nodes і налаштування.
5. Порівняйте зміни workflows. Шукайте невідомі HTTP Request nodes, нові webhooks, змінені destinations, вимкнену validation, нові schedules або export до зовнішніх endpoints.
6. Складіть перелік доступних credentials. Врахуйте OAuth grants, cloud accounts, databases, email, chat, source control, SSH, webhooks і internal APIs.
7. Змініть підключені секрети в джерелі. Видалення credential у n8n може залишити чинним upstream provider token. Відкличте його у провайдера та перевірте access logs.
8. Дослідіть downstream-активність. Зіставте період експозиції з identity, cloud, database, source-control, mail і network-egress logs.

Подібна межа виникає після читання файлів: патч Rails CVE-2026-66066 не повертає секретність уже доступним даним. В обох випадках containment і зміна credentials — окремі етапи.

Як не допустити нового витоку n8n

• Зберігайте production keys у secret manager або захищених CI variables, а не у workflow exports, source files, прикладах, shell history чи налаштуваннях AI-інструментів.
• Використовуйте короткий строк дії та least privilege. Підтримуйте перелік automation identities і підключених сервісів, який регулярно перевіряє owner.
• Тримайте source-control repositories приватними, якщо публікація не є свідомим рішенням, і скануйте кожен commit до його виходу за межі організації.
• Віддавайте перевагу OAuth там, де n8n його підтримує, а після витоку відкликайте grant у upstream provider.
• Перевіряйте community nodes та обмежуйте доступ до інстанса, outbound network paths і право створювати credential-backed workflows.
• Регулярно запускайте n8n security audit та сповіщайте про нових users, credentials, workflows, schedules і нетипові execution destinations.

Джерела

1. The Hacker News. «Leaked n8n API Tokens Exposed Live Instances to Workflow and Credential Theft». Матеріал за дослідженням GitGuardian, опубліковано 5 серпня 2026 року; дата звернення: 5 серпня 2026 року. звіт про дослідження.
2. n8n. «Security audit». Документація n8n; дата звернення: 5 серпня 2026 року. офіційна документація аудиту.
3. n8n. «Security». Рекомендації n8n із безпеки; дата звернення: 5 серпня 2026 року. офіційні рекомендації.