Перевірка прав доступу до облікових даних у n8n: повідомлення від 14 жовтня та подальші дії
Повідомлення n8n від 14 жовтня 2026 року про перевірку прав доступу до облікових даних: виправлені версії, тимчасові заходи та подальші дії команд.
Перевірено за наведеними джерелами .
Що n8n повідомила 14 жовтня
Повідомлення GHSA-8vrr-mgc5-jg55 про перевірку прав доступу до облікових даних у n8n, опубліковане 14 жовтня 2026 року, закликає користувачів оновитися до версії 1.123.85, 2.43.5 або 2.44.1 чи новішої, щоб усунути вразливість, пов’язану з вузлами inline sub-workflow. 14 жовтня — дата публікації повідомлення; її не зазначено як дату випуску виправлення.
У повідомленні наведено межі вразливих версій, нижчі за ці виправлені версії, без назв каналів випуску. Наша редакційна порада — зіставити розгорнуту версію з даними повідомлення. На нашу думку, найкорисніший перший крок для команди — чітко визначити відповідального за оновлення.
Як перевірка прав доступу до облікових даних у n8n могла пропустити вузол
Згідно з повідомленням, перевірка прав доступу до облікових даних і механізм виконання по-різному трактували вимкнені вузли. Для вузлів inline sub-workflow у n8n ця розбіжність могла дозволити вузлу уникнути перевірки прав доступу й усе одно виконатися. Повідомлення стосується небулевого значення disabled у n8n: значення, відмінного від булевого true або false.
Зазначена передумова важлива для команд, які переглядають права доступу: учасник мав би знати ID облікових даних, до яких він не має доступу. У повідомленні сказано, що такий учасник міг використати вразливість, щоб надіслати розшифрований вміст облікових даних на підконтрольний йому сервер. У ньому немає відомостей про зафіксовані випадки експлуатації, кількість постраждалих клієнтів чи виміряні наслідки інцидентів.
Що робити, якщо оновлення доводиться відкласти
Адміністраторам, які не можуть оновитися негайно, n8n рекомендує такі тимчасові дії щодо вразливості перевірки прав доступу до облікових даних у n8n:
У повідомленні прямо попереджено, що ці обхідні заходи не усувають ризик повністю й мають бути короткостроковими. Воно вказує, що слід перевірити, але не містить запитів для пошуку в журналах, процедури розслідування чи гарантії виявлення експлуатації, а також не наводить кількісної оцінки зниження ризику.
На нашу думку, обмеження доступу та перегляд журналів мають супроводжувати заплановане оновлення, а не ставати причиною його відкладати.
Що залишилося неуточненим у повідомленні
У повідомленні не зазначено, яких редакцій це стосується, як відбувається оновлення на хостингових тарифах і чи отримують хмарні інстанси виправлення автоматично. Також не описано реалізацію виправлення, конкретні некоректні значення disabled, команди оновлення чи процедури перевірки після нього.
Наша редакційна порада — окремо зафіксувати ці питання щодо розгортання під час координації оновлення перевірки прав доступу до облікових даних у n8n, щоб припущення про те, хто виконує оновлення, не стали планом дій команди.
