Вразливість кінцевої точки авторизації OAuth в n8n: пояснення
Що таке вразливість кінцевої точки авторизації OAuth в n8n (GHSA-3qcw-p65v-c7vq), які версії зачіпає і що робити зараз, за порадою GitHub від 30.09.2026.
Перевірено за наведеними джерелами .
Що змінилося: порада з безпеки n8n, вересень 2026
30 вересня 2026 року GitHub опублікував пораду з безпеки для npm-пакета n8n, яка описує те, що вона називає «Неавтентифікованим необмеженим збереженням OAuth-клієнтів через кінцеву точку авторизації» (Unauthenticated Unbounded OAuth Client Persistence via the Authorize Endpoint), відстежуваним як GHSA-3qcw-p65v-c7vq. Якщо ваша команда намагається зрозуміти вразливість кінцевої точки авторизації OAuth в n8n, саме порада є найкращою відправною точкою, і ця стаття послідовно викладає те, що в ній зазначено. На власній сторінці огляду безпеки репозиторію n8n-io/n8n на GitHub ця порада вказана як опублікована 30 вересня 2026 року користувачем Matsuuu з рівнем серйозності High, що підтверджує дату й рівень серйозності, наведені в самій пораді.
Основний висновок поради стосується вразливості збереження OAuth-клієнтів: записи OAuth-клієнтів, створені через кінцеву точку авторизації без будь-якої автентифікації, не мають обмеження за розміром, терміну дії чи шляху видалення — так це формулює сама порада. На практиці це означає, що неавтентифікований викликач може нескінченно додавати нові записи клієнтів, оскільки ніщо в описаному в пораді процесі не очищає їх. Ми вважаємо, що сам факт повідомлення та розкриття цієї проблеми через стандартний процес порад GitHub є доброю ознакою для стану безпеки n8n, хоча саму базову помилку все ж потрібно виправити.
Sources: Unauthenticated Unbounded OAuth Client Persistence via the Authorize Endpoint · Advisory · n8n-io/n8n · GitHub, Overview · n8n-io/n8n · GitHub
Кого це стосується: версії n8n та проблема неавтентифікованого OAuth-клієнта в n8n
Порада чітко визначає діапазон версій, які охоплює вразливість кінцевої точки авторизації OAuth в n8n, також описану як проблема неавтентифікованого OAuth-клієнта в n8n: до уражених версій npm-пакета n8n належать ті, що вийшли до 2.42.1 та до 2.41.4, а виправлення випущено у версіях 2.42.1 та 2.41.4.
| Гілка | Уражені версії | Виправлена версія |
|---|---|---|
| Гілка 2.42.x | До 2.42.1 | 2.42.1 або новіше |
| Гілка 2.41.x | До 2.41.4 | 2.41.4 або новіше |
Те, про що порада мовчить, тут має не менше значення. У ній не зазначено, чи зачіпає проблема n8n Cloud або інші хмарні тарифи, чи вже виправлена вона на стороні n8n, і вона не розрізняє видання Community (self-hosted) та Enterprise n8n. Ми б радили не сприймати цю мовчанку як заспокійливий сигнал: порада, яка нічого не говорить про хмарні тарифи чи видання, просто не розглянула їх, а не виключила можливу проблему, тож командам усе одно варто перевірити власне розгортання, а не припускати, що їх це не стосується.
Як працює вразливість і чому важливі записи OAuth-клієнтів
Кінцева точка авторизації n8n є частиною OAuth-процесу, яким користується робочий процес, коли йому потрібно передати керування зовнішньому сервісу для авторизації. Саме цей механізм перебуває в центрі вразливості кінцевої точки авторизації OAuth в n8n. Порада описує проблему так: записи, створені на цій кінцевій точці, зберігаються без обмеження за розміром, терміну дії чи шляху видалення, хоча сама кінцева точка не вимагає автентифікації для виклику. Кожен виклик, як видається, залишає після себе запис клієнта, який надалі нічим у системі не видаляється.
Порада GitHub оцінює цю проблему як High severity (високий рівень серйозності) — це твердження самої поради, а не висновок, зроблений цією статтею. Саме через цей рівень серйозності важливо, щоб команди, які перевіряють власну вразливість, читали пораду безпосередньо, а не переказ із других рук.
Sources: Unauthenticated Unbounded OAuth Client Persistence via the Authorize Endpoint · Advisory · n8n-io/n8n · GitHub, Overview · n8n-io/n8n · GitHub
Що робити зараз
Виправлення, яке сама порада визначає як рішення, — використовувати виправлену версію: 2.42.1 або новішу в гілці 2.42.x, або 2.41.4 або новішу в гілці 2.41.x. Негайне оновлення — це наша власна редакційна рекомендація, а не те, що прямо радить сама порада понад назвою виправлених версій, і ми вважаємо її правильною саме тому, що порада описує обхідні рішення як неповні.
Якщо негайне оновлення неможливе, порада перелічує кілька обхідних рішень, зокрема моніторинг розміру бази даних на непередбачене зростання, обмеження мережевого доступу та перевірку вузлів Form або Chat Trigger, що використовують n8nUserAuth. Порада прямо вказує, що ці заходи не усувають ризик повністю й призначені лише як тимчасове пом'якшення — це обмеження варто повторити, бо список обхідних рішень легко сприйняти як повноцінне виправлення. Наша практична порада: застосовувати всі перелічені обхідні рішення разом, а не обирати одне з них, і попри це не відкладати оновлення.
Що порада залишає без пояснення
Окрім видань і хмарних тарифів, порада не наводить жодного відомого CVE чи CWE для цієї проблеми, тож немає незалежного ідентифікатора для перевірки в інших трекерах. Вона також не дає кількісної оцінки того, наскільки великою може стати таблиця клієнтів, скільки дискового простору займають типові записи чи наскільки швидко зростання може перетворитися на практичну проблему для конкретного розгортання. Це прогалини, які залишає сама порада, а не упущення цього огляду.
Сторінка безпеки репозиторію n8n-io/n8n на GitHub показує цю пораду поряд із кількома іншими порадами, опублікованими того ж дня, 30 вересня 2026 року. Це редакційна пропозиція цієї статті, а не те, що радить сама порада: перегляд повнішого переліку може допомогти командам переконатися, що це не єдине релевантне виправлення в цій партії.
Sources: Unauthenticated Unbounded OAuth Client Persistence via the Authorize Endpoint · Advisory · n8n-io/n8n · GitHub, Overview · n8n-io/n8n · GitHub
