Вразливості безпеки n8n: історія розкриття та виправлення
Огляд того, наскільки прозоро й швидко n8n розкриває та усуває вразливості безпеки n8n на основі рекомендацій, попереджень CERT та досліджень.
Перевірено за наведеними джерелами .
Вразливості безпеки n8n: обсяг і критерії огляду
Цей огляд відповідає на запитання, наскільки прозоро та швидко n8n розкриває й усуває вразливості безпеки n8n, і що цей послужний список означає для технічного лідера, який запускає n8n на власній інфраструктурі. Ми розглядаємо лише три речі: як швидко повідомлена вразливість перетворюється на опубліковану рекомендацію (advisory), скільки технічних деталей кожна рекомендація дає захиснику, і наскільки чіткими є вказівки n8n щодо патчів та обхідних рішень для хмарних версій порівняно з самостійно розгорнутими. Ми спираємося на власні рекомендації n8n на GitHub і сторінки політик, на попередження національних органів кібербезпеки та на незалежні звіти про безпеку за той самий період — здебільшого з кінця 2025 до початку 2026 року.
Ми не намагаємося відтворити повну історію всіх CVE для n8n, коли-небудь зареєстрованих. Доступні нам дані зосереджені навколо кластеру рекомендацій із листопада 2025 по лютий 2026 року, плюс один давніший випадок із 2023 року, тож це огляд документованих прикладів, а не повна багаторічна тенденція.
Як структуровано програму розкриття вразливостей n8n
Політика безпеки n8n на GitHub каже, що будь-хто, хто знайшов вразливість, має повідомити про неї через формальну Програму розкриття вразливостей (Vulnerability Disclosure Program), а не писати напряму якомусь з мейнтейнерів — так зазначено на сторінці SECURITY.md n8n. Ця сторінка — короткий фрагмент політики без історії версій, тож неможливо сказати, як довго існує цей формальний канал.
Віцепрезидент з інженерії n8n прямо звернувся до цієї тенденції у власному блозі компанії, після того як зростаючий темп публікації рекомендацій спричинив запитання користувачів про те, чи має проєкт проблему з безпекою.
Власна сторінка довіри (trust page) n8n також описує регулярний режим тестування: сканування вразливостей третьою стороною щонайменше раз на 90 днів і тест на проникнення (penetration test) третьою стороною щонайменше раз на рік — як частину програми управління загрозами та вразливостями. Це самостійно заявлений опис власного процесу n8n, а не незалежно перевірений звіт про те, як часто ці тести реально проводилися.
Sources: Security Policy · n8n-io/n8n · GitHub, Security
Швидкість розкриття на практиці: що показують останні хронології
Якщо порівняти їх поруч, останні вразливості безпеки n8n показують закономірність, яку варто назвати прямо: патчі іноді випускалися тихо, за кілька тижнів до того, як публічна рекомендація наздоганяла їх. Для вразливості, що торкається версій n8n з 1.65 по 1.120.4, власна рекомендація n8n від 8 січня 2026 року каже, що виправлення було випущено для всієї клієнтської бази 18 листопада 2025 року — але сама рекомендація не була опублікована до 8 січня 2026 року, приблизно сім тижнів пізніше. n8n пояснює цю затримку як навмисну, що дає клієнтам час на оновлення до того, як технічні деталі стануть публічними.
Незалежні звіти додають ще одне свідчення подібного розриву. Звіт CyberScoop від 7 січня 2026 року каже, що компанія з безпеки Cyera виявила та повідомила про той самий CVE-2026-21858 n8n 9 листопада 2025 року, що n8n виправила його 18 листопада, але CVE не було публічно присвоєно чи розкрито до 7 січня 2026 року — приблизно два місяці після початкового повідомлення. n8n не відповіла на запит CyberScoop про коментар, тож там зафіксовано лише сторону Cyera щодо цього конкретного розриву.
На нашу думку, затримка у стилі ембарго між виправленням і публікацією може бути обґрунтованим компромісом у сфері безпеки, оскільки вона заважає зловмисникам реверс-інжинірити виправлення до того, як клієнти його застосують. Але це працює лише тоді, коли кожна постраждала команда дійсно використовує свіжі релізи протягом цього тихого періоду, а це велике припущення для самостійно розгорнутого n8n.
На момент, коли Канадський центр кіберзахисту (Cyber Centre) видав своє попередження від 12 січня 2026 року, він зазначив, що експлойти-доведення концепції (proof-of-concept), які поєднують CVE-2026-21858 з раннішою вразливістю 2025 року, уже публічно циркулюють, і окремо зауважив, що лінійка версій 1.X n8n досягає кінця підтримки на початку березня 2026 року.
Sources: Security Advisory: Security Vulnerability in n8n Versions 1.65-1.120.4 – n8n Blog, Researchers rush to warn defenders of max-severity defect in n8n | CyberScoop, AL26-001 – Vulnerabilities affecting n8n – CVE-2026-21858, CVE-2026-21877 and CVE-2025-68613 - Canadian Centre for Cyber Security
Наскільки детальні рекомендації n8n щодо CVE та вказівки з патчів
Після публікації рекомендації безпеки n8n на GitHub зазвичай мають технічну змістовність. Рекомендація для CVE-2025-68613 (GHSA-v98v-ff95-f3cp, опублікована 19 грудня 2025 року) містить діапазон уражених версій, виправлену версію — n8n v1.122.0 — вектор CVSS, класифікацію CWE та подяку дослідникові, який повідомив про вразливість.
- Діапазони уражених і виправлених версій
- Оцінка та вектор CVSS
- Класифікація слабкості CWE
- Подяка дослідникові або компанії, яка повідомила про вразливість
- Вказівки щодо обхідних рішень, коли вони існують
Обхідні рішення відрізняються за надійністю. Рекомендація для пов'язаної з Pyodide вразливості вузла Python Code (GHSA-62r4-hw23-cc8v, CVE-2025-68668, опублікована 24 грудня 2025 року) дає три конкретні варіанти пом'якшення, включно зі встановленням змінної середовища N8N_PYTHON_ENABLED=false, щоб повністю вимкнути уражену функцію. На противагу цьому, рекомендація щодо вразливості віддаленого виконання коду через втечу з виразів (expression-escape) (GHSA-6cqr-8cfr-67f8, CVE-2026-25049, опублікована 4 лютого 2026 року) прямо каже, що перелічені обхідні рішення не повністю усувають ризик і мають використовуватися лише як тимчасовий захід.
Та сама рекомендація від лютого 2026 року також зазначає, що n8n прийняла CVSS 4.0 як основний стандарт оцінювання надалі, продовжуючи водночас публікувати оцінки CVSS 3.1 для зворотної сумісності — це деталь методології, а не сигнал про швидкість, але вона допомагає захисникам послідовно порівнювати рівні серйозності.
Sources: n8n Remote Code Execution via Expression Injection · Advisory · n8n-io/n8n · GitHub, Arbitrary Command Execution in Pyodide based Python Code Node · Advisory · n8n-io/n8n · GitHub, Expression Escape Vulnerability Leading to RCE · Advisory · n8n-io/n8n · GitHub
Зовнішня перевірка: попередження CERT та незалежні дослідження безпеки
Власні рекомендації n8n не єдине джерело. Бельгійський національний орган кібербезпеки, CCB, задокументував і CVE-2026-21858, і CVE-2026-21877 з максимальною оцінкою CVSS 10.0 у своїй публічній рекомендації, останнє оновлення якої датоване 9 січня 2026 року. Ця рекомендація повторює дані про версії та пом'якшення, надані самою n8n, тож вона функціонує як канал розповсюдження, а не як незалежний технічний аудит.
| Джерело | Тип свідчення | Що додає |
|---|---|---|
| Власна рекомендація n8n (8 січ. 2026) | Постачальник, офіційне | Підтверджує дату патчу і наводить причину n8n для затримки публікації |
| CyberScoop, з посиланням на Cyera (7 січ. 2026) | Незалежна журналістика безпеки | Наводить дати Cyera щодо першого повідомлення про вразливість n8n |
| Бельгійський CCB (9 січ. 2026) | Попередження національного CERT | Підтверджує максимальні оцінки серйозності для обох критичних CVE |
| Канадський центр кіберзахисту (12 січ. 2026) | Попередження національного CERT | Підтверджує оцінки серйозності та зазначає, що публічні PoC-експлойти вже циркулюють |
| Rapid7 (8 січ. 2026, оновлено 1 лип. 2026) | Дослідження постачальника безпеки | Зводить п'ять CVE з датами публікації та оцінками CVSS/NVD в одну таблицю |
Дослідження загроз Rapid7, вперше опубліковане 8 січня 2026 року й оновлене 1 липня 2026 року, зводить п'ять CVE, що торкаються n8n і були розкриті між 19 грудня 2025 та 7 січня 2026 року, в одну таблицю дат публікації та оцінок. Rapid7 продає продукти для управління вразливостями, тож її інтерес у висвітленні вразливості n8n має й комерційний характер.
Ми б розглядали перехресну перевірку власних публікацій n8n проти цих попереджень CERT і незалежних матеріалів як стандартну практику, а не опціональний додаток, оскільки саме в розривах між поданням постачальника й зовнішніми звітами ховається справжнє вікно вразливості самостійно розгорнутої команди.
Ця закономірність активних, серйозних розкриттів не є унікальною для кінця 2025 року. Вразливість підвищення привілеїв 2023 року, CVE-2023-27563, що торкається версій n8n нижче 0.216.1, була задокументована в базі даних GitHub Advisory Database 10 травня 2023 року з посиланням на оригінальне дослідження компанії з безпеки Synacktiv — хоча цей запис не містить деталей про власну внутрішню хронологію розкриття n8n для цього випадку.
Sources: Warning: Two critical vulnerabilities in n8n can lead to remote code execution, Patch Immediately! | CCB Belgium, AL26-001 – Vulnerabilities affecting n8n – CVE-2026-21858, CVE-2026-21877 and CVE-2025-68613 - Canadian Centre for Cyber Security, Ni8mare and N8scape flaws among multiple critical vulnerabilities affecting n8n, n8n Privilege Escalation vulnerability · CVE-2023-27563 · GitHub Advisory Database · GitHub
Що цей послужний список означає для ризику самостійно розгорнутої команди
У сукупності цей послужний список виглядає як постачальник, який розкриває вразливості, але іноді робить це із запізненням. Рекомендації n8n технічно детальні після публікації, і n8n має власний регулярний режим тестування, але розрив між тихим патчем і публічним звітом сягав приблизно семи тижнів принаймні в одному добре задокументованому випадку.
Наше прагматичне прочитання полягає в тому, що саме розрив між тихим патчем і публічною рекомендацією становить справжній операційний ризик для самостійно розгорнутих команд — більше, ніж сама кількість вразливостей безпеки n8n, розкритих за будь-який квартал. Команда, яка лише реагує на листи з рекомендаціями, може тижнями залишатися невиправленою, не знаючи про це.
Попередження Канадського центру кіберзахисту також зазначило, що лінійка версій 1.X n8n досягає кінця підтримки на початку березня 2026 року, що важливо для будь-якої самостійно розгорнутої команди, яка ще планує свій шлях оновлення, а не вважає оновлення версій опціональним.
Sources: Security Advisory: Security Vulnerability in n8n Versions 1.65-1.120.4 – n8n Blog, Security, AL26-001 – Vulnerabilities affecting n8n – CVE-2026-21858, CVE-2026-21877 and CVE-2025-68613 - Canadian Centre for Cyber Security
Практичні рекомендації для самостійно розгорнутих команд
Ніщо з цього не змінює базового завдання самостійно розгорнутої команди: тримайтеся близько до поточних релізів і вибудуйте процес, який не залежить від того, чи прочитаєте ви кожен пост у блозі в день його виходу.
Технічному лідеру, який хоче чіткої відповіді на питання, чи дійсно його інстанс виправлений і захищений так, як передбачають ці рекомендації, зазвичай потрібен хтось, хто перевірить реальне налаштування, а не лише сторінку політики.
Sources: Security Advisory: Security Vulnerability in n8n Versions 1.65-1.120.4 – n8n Blog, Researchers rush to warn defenders of max-severity defect in n8n | CyberScoop, n8n Remote Code Execution via Expression Injection · Advisory · n8n-io/n8n · GitHub, Arbitrary Command Execution in Pyodide based Python Code Node · Advisory · n8n-io/n8n · GitHub, Warning: Two critical vulnerabilities in n8n can lead to remote code execution, Patch Immediately! | CCB Belgium, AL26-001 – Vulnerabilities affecting n8n – CVE-2026-21858, CVE-2026-21877 and CVE-2025-68613 - Canadian Centre for Cyber Security, Ni8mare and N8scape flaws among multiple critical vulnerabilities affecting n8n
