Повторне підключення до чату агента між користувачами: що каже рекомендація за вересень 2026
Що каже рекомендація GitHub від 30.09.2026 про вразливість чату агента між користувачами: що змінилося, кого стосується і що робити зараз.
Перевірено за наведеними джерелами .
Оновлення
30 вересня 2026 року рекомендація з безпеки GitHub повідомила про вразливість повторного підключення до чату агента між користувачами, яка стосується npm-пакета n8n. Ця рекомендація під назвою «Cross-User Agent Chat Resume Allows Hijacking Another User's Pending Tool Approval» є основним джерелом усієї інформації в цій статті щодо цієї проблеми.
Ми розглядаємо лише те, що сама рекомендація повідомляє про цю вразливість безпеки чату агента: що саме змінилося, кого стосується за номером версії та що рекомендація визначає як виправлення і тимчасові обхідні рішення. Там, де рекомендація мовчить, наприклад щодо n8n Cloud або інших хостинг-планів, ми прямо про це говоримо, а не припускаємо.
Що було оголошено і коли
Рекомендацію було опубліковано на github.com 30 вересня 2026 року під назвою, що прямо називає проблему повторного підключення до чату агента між користувачами. У ній описано ваду в тому, як спільний проєкт n8n обробляє призупинену розмову з агентом, яка очікує, доки людина підтвердить виклик інструмента.
Рекомендація документує цю ваду відновлення чату AI-агента як прогалину в авторизації: система не перевіряє, чи є користувач, який відновлює чат, тим самим користувачем, який його розпочав, у проєкті, спільному для кількох людей.
Як вразливість дозволяє перехопити очікуване підтвердження інструмента
Згідно з рекомендацією, зловмисник, який має доступ до спільного проєкту, може повністю прочитати приватну розмову іншого користувача з агентом. Опинившись у цій розмові, зловмисник може відповісти на очікуване підтвердження від імені жертви, дозволивши інструменту виконатися, і записати результат назад у власний потік розмови жертви.
Ми вважаємо, що це корисне нагадування про те, що крок підтвердження людиною надійний лише настільки, наскільки надійна перевірка особи навколо нього; шлюз підтвердження, який може натиснути будь-хто у спільному робочому просторі, насправді не є шлюзом. Сама рекомендація описує цю загрозу як перехоплення очікуваного підтвердження інструмента, на яке мав відповідати лише той, хто надіслав запит.
Кого і які версії це стосується
Рекомендація зазначає, що npm-пакет n8n є вразливим у версіях до 2.42.0 та до 2.41.4. Таким чином, ця проблема повторного підключення до чату агента між користувачами стосується всіх, хто використовує одну з цих попередніх збірок, де кілька користувачів мають спільний доступ на рівні проєкту до агентів, які використовують підтвердження інструментів.
| Статус | Діапазон версій | Що каже рекомендація |
|---|---|---|
| Уражено | До 2.42.0 та до 2.41.4 | Визначено як вразливі до проблеми повторного підключення до чату між користувачами |
| Виправлено | 2.42.0 та 2.41.4 | Визначено як версії, у яких проблему виправлено |
Що робити зараз: оновлення та тимчасові обхідні рішення
Рекомендація стверджує, що проблему виправлено у версіях n8n 2.42.0 та 2.41.4, і закликає користувачів оновитися до однієї з цих версій або новішої. Це оновлення — єдиний спосіб усунення проблеми, який рекомендація справді радить.
Для команд, які не можуть оновитися негайно, рекомендація наводить кілька тимчасових заходів: вимкнення модуля Agents через налаштування N8N_ENABLED_MODULES, обмеження доступу до інстансу лише довіреними користувачами, обмеження кола учасників спільного проєкту та уникнення інструментів із увімкненою опцією «Require approval» на агентах, доступних кількох людям.
На нашу думку, тут важлива власна обережність рекомендації: вона прямо каже, що ці обхідні рішення не повністю усувають ризик, тож ми б не покладалися на жодне з них окремо і розглядали оновлення як справжнє виправлення, а не просто бажану опцію.
Що не вказано в оголошенні
Рекомендація не повідомляє, чи стосується проблема n8n Cloud або інших хостинг-планів; це питання просто не розглядається в тексті, який ми вивчили. Вона також не пояснює, як довго існувала проблема до її виявлення, скільки інстансів було уразливими та чи хтось експлуатував її до виходу виправлення.
- Чи стосується це n8n Cloud або інших хостинг-планів
- Чи відрізняються за вразливістю видання Community та Enterprise
- Як довго існувала вада до її виявлення
- Чи була вона експлуатована до виходу виправлення
Рекомендація не вказує, чи було цій проблемі присвоєно ідентифікатор CVE, і не наводить числову оцінку серйозності; ці деталі не розглядаються у матеріалах, які ми вивчили. На нашу думку, відсутність CVE під рукою — це незначна перешкода для систем відстеження вразливостей, а не ознака того, що проблема менш серйозна, тож команди, які покладаються на канали CVE, наразі мають стежити за цією проблемою за назвою рекомендації.
