Вразливість Send-and-Wait в n8n: що повідомляє офіційне застереження
Що повідомляє застереження щодо вразливості Send-and-Wait у n8n (GHSA-728h-pmr2-7cgh): уражені версії, офіційне виправлення та обхідні рішення.
Перевірено за наведеними джерелами .
Що таке вразливість n8n Send-and-wait
Застереження безпеки GitHub, опубліковане 30 вересня 2026 року, описує вразливість Send-and-wait в n8n, яка впливає на кінцеву точку waiting-webhook, на яку спираються робочі процеси підтвердження. Згідно із застереженням, визначеним як GHSA-728h-pmr2-7cgh, ця кінцева точка приймала другий формат посилання на вузол Send-and-Wait без перевірок підпису, які зазвичай потрібні для підтверджень, оскільки система вибирала, яку перевірку застосувати, перш ніж нормалізувати цей формат.
Застереження описує це саме як недолік у способі перевірки запитів на відновлення Send-and-Wait. Тут ми називаємо це обходом підтвердження виконання очікування n8n як власний описовий скорочений термін, а не фразу, яку використовує саме застереження, і застереження формулює проблему вузько, а не як ширшу категорію проблем з автентифікацією.
Які версії n8n уражені
Застереження перелічує уражені версії як випуски n8n нижче 2.42.1 та нижче 2.41.4 — іншими словами, збірки 2.41.x до 2.41.4 та збірки 2.42.x до 2.42.1. Якщо ваш екземпляр працює на одній з цих ліній без пізнішого патчу, опис застереження стосується вас.
| Лінія версій | Статус за застереженням |
|---|---|
| 2.41.x до 2.41.4 | Уражена |
| 2.42.x до 2.42.1 | Уражена |
| 2.41.4 або новіша | Виправлено |
| 2.42.1 або новіша | Виправлено |
n8n стверджує, що проблему виправлено у версіях 2.42.1 та 2.41.4, і власна інструкція компанії — оновитися до однієї з цих версій або новішої. Застереження не вказує, чи мають ту саму проблему попередні основні або проміжні лінії версій, тож це питання залишається поза межами підтвердженого тут.
Серйозність та ризик обходу HMAC у n8n
Застереження розглядає це як обхід авторизації на кінцевій точці waiting-webhook, де хтось інший, а не передбачуваний затверджувач, може вирішити очікуваний крок Send-and-Wait. Воно також стверджує, що після цього все, що відбувається далі, виконується під обліковими даними власника робочого процесу, що залежно від робочого процесу може досягати виконання команд. Така комбінація означає, що ця вразливість Send-and-wait в n8n може мати наслідки, що значно перевищують сам крок підтвердження.
Ми вважаємо, що цей масштаб важливий для пріоритизації: цей обхід HMAC у n8n має найбільші наслідки в робочих процесах, де шлюз підтвердження захищає щось дороге, як-от здійснення платежу або надання доступу, і менш критичний у малозначущому внутрішньому сповіщенні.
Власний блог-пост n8n про практику розкриття вразливостей дає загальний контекст того, чому час має значення після публікації виправлення, хоча він передує цьому конкретному застереженню і не написаний саме про цей випадок.
Виправлення безпеки n8n Send-and-wait та обхідні рішення
Основний спосіб усунення n8n — це вже назване оновлення версії: 2.42.1, 2.41.4 або новіша. На нашу думку, це оновлення — єдиний крок, який справді усуває цю прогалину у виправленні безпеки Send-and-wait в n8n, і варто розглядати його як перший пункт у списку, а не включати в рутинне обслуговування.
Застереження також називає три тимчасові заходи для команд, які не можуть оновитися негайно, але чітко зазначає, що вони є лише короткостроковими і не повністю усувають основний ризик, тож вони функціонують як міст, а не як замінник патчу.
Що не повідомляє застереження
Застереження не розбиває вплив за редакцією n8n чи планом хостингу — воно надає лише межі версій пакета, а не окремі твердження щодо Cloud, Enterprise чи Community екземплярів. Якщо вашій команді потрібно знати, чи вимагав ваш конкретний план окремих дій щодо цієї вразливості Send-and-wait в n8n, це питання лежить поза межами того, що зазначено в оголошенні, і підтримка n8n або ваш менеджер облікового запису — правильне місце, щоб запитати.
Застереження також не присвоює ідентифікатор CVE, вказуючи GHSA-728h-pmr2-7cgh як єдине посилання, і не описує процедуру оновлення, очікуваний час простою чи підтверджує, чи оновлюються екземпляри Cloud автоматично.
Sources: Send-and-Wait HMAC Bypass Allows Unauthenticated Approval of Waiting Executions · Advisory · n8n-io/n8n · GitHub, Overview · n8n-io/n8n · GitHub
Довідково: як працюють токени відновлення та підтвердження Send-and-Wait
Документація вузла Wait в n8n пояснює, що вузол надає змінну resumeUrl, тож робочий процес може видати унікальне посилання, яке продовжує виконання пізніше, коли хтось натискає на нього або надсилає відповідь. Вузли Send-and-Wait у різних каналах, таких як Slack, Telegram та Discord, будують кроки підтвердження на основі цього механізму, поєднуючи посилання відновлення з підписом, призначеним підтвердити, що відповідь надійшла від передбачуваного затверджувача.
Запис журналу змін із релізу n8n за липень 2026 року, версія 2.30, зазначає, що кожен вузол Send-and-Wait у цих каналах отримав позначку часу, яка фіксує момент надходження відповіді підтвердження — функція, не пов'язана з цим застереженням. Тут про неї згадується лише як про довідкову інформацію про те, наскільки активно підтримується ця родина вузлів, а не як про щось, що стосується самого обходу HMAC.
Sources: Wait | Nodes | n8n Docs, Changelog | n8n Docs
Редакційні наступні кроки для команд, що використовують n8n
Окрім власних інструкцій застереження, ось кроки, які ми радили б команді, що використовує n8n у продакшені — це редакційна порада, а не щось, що саме застереження радить вам зробити.
- Інвентаризувати кожен робочий процес, який розміщує вузол підтвердження Send-and-Wait після публічного тригера Webhook, Form чи Chat
- Запитати підтримку n8n, чи потрібні дії для вашого конкретного розгортання
- Розглянути підписку на сповіщення про застереження безпеки n8n, щоб не пропустити майбутні виправлення
Ми оптимістично налаштовані, що команди, які вже розглядають Send-and-Wait як механізм підтвердження рівня продакшену, а не як зручність для демонстрації, легко зможуть пріоритизувати це оновлення, щойно воно опиниться в їхньому полі зору.
