Огляд вразливості для команд безпеки

Ni8mare - це мережевий вектор атаки без автентифікації й без взаємодії з користувачем. Вразливими є версії n8n від 1.65.0 до 1.120.x включно.
Виправлення було випущено у 1.121.0.

У певних конфігураціях це може призвести до arbitrary file read (LFI-подібна поведінка), що дозволяє отримати конфігураційні секрети, токени доступу або credentials, і зрештою призводить до повної компрометації інстансу (RCE).

З технічної точки зору зачіпаються:

• HTTP request layer (публічні сторінки /signin, /login);
• Webhook та form middleware;
• Secrets storage, база даних і конфігураційні артефакти.
   

Чому ризик критичний

n8n часто працює як інтеграційний вузол між CRM, ERP, IAM, CI/CD та хмарними сервісами. Тому компрометація n8n майже завжди означає компрометацію пов’язаних систем через токени доступу, облікові дані та вебхуки.

Це може призвести до зупинки автоматизацій, витоку даних, фінансових втрат, та репутаційних наслідків через компрометацію інтеграцій.

Що робити в перші 72 години

Найважливіше - оновити n8n до версії 1.121.0+ у всіх середовищах. Паралельно варто зменшити відкритість сервісу: прибрати публічний доступ або максимально обмежити його через VPN, створити список дозволених IP-адрес чи зворотний проксі. Також необхідно змінити токени доступу та облікові дані, особливо якщо інстанс був доступний з Інтернету.

Окремий крок - скласти перелік інстансів n8n, визначити їх власників, критичні робочі процеси та залежності.

У середньостроковій перспективі важливі посилення безпеки конфігурацій, застосувати принцип найменших привілеїв, запровадити централізований моніторинг логів та провести перевірку безпеки робочих процесів, які приймають зовнішні дані.

Чому працює демонстраційний код для виявлення (Detection PoC)

Цей підхід не використовує вразливість. Він лише зчитує публічну HTML-сторінку n8n (наприклад, /signin) і витягує рядок base64 із meta-тегу конфігурації. Усередині цього рядка зазвичай є маркер виду n8n@X.Y.Z, який дозволяє визначити версію системи.

Якщо версія потрапляє в діапазон 1.65.0 ≤ version < 1.121.0, інстанс вважається потенційно вразливим.

id: CVE-2026-21858
info:
  name: CVE-2026-21858 - n8n Ni8mare RCE (Detection)
  author: ashwesker
  severity: critical
  description: |
    n8n is a fair-code licensed workflow automation platform.
    CVE-2026-21858, dubbed "Ni8mare", is a critical unauthenticated remote code execution vulnerability 
    in n8n due to Content-Type confusion in form-based workflows, allowing arbitrary file reads, 
    authentication bypass, and full server compromise.
    This template detects vulnerable versions by extracting metadata from public pages.
  reference:
    - https://www.cyera.com/research-labs/ni8mare-unauthenticated-remote-code-execution-in-n8n-cve-2026-21858
    - https://nvd.nist.gov/vuln/detail/CVE-2026-21858
    - https://github.com/n8n-io/n8n/security/advisories/GHSA-v4pr-fm98-w9pg
  metadata:
    vendor: n8n
    product: n8n Workflow Automation
    verified: true
    shodan-query: http.favicon.hash:-831756631
  tags: cve,cve2026,n8n,rce,workflow,automation,ni8mare
http:
  - method: GET
    path:
      - "{{BaseURL}}/signin"
      - "{{BaseURL}}/login"
      - "{{BaseURL}}/"
    stop-at-first-match: true
    extractors:
      - type: regex
        name: base64_content
        group: 1
        regex:
          - '<meta name="n8n:config:sentry" content="([A-Za-z0-9+/=]+)"'
        internal: true
      - type: dsl
        name: decoded
        dsl:
          - base64_decode(base64_content)
        internal: true
      - type: dsl
        name: version
        dsl:
          - replace_regex(decoded, ".*n8n@([0-9]+\\.[0-9]+\\.[0-9]+).*", "$1")
        internal: true
      - type: dsl
        dsl:
          - '"Detected n8n Version: " + version'
    matchers-condition: and
    matchers:
      - type: status
        status:
          - 200
      - type: word
        part: body
        words:
          - "n8n"
        case-insensitive: true
      - type: dsl
        name: vulnerable
        dsl:
          - compare_versions(version, "< 1.121.0") # 🚨 CVE-2026-21858 — *“Ni8mare”*

Додатково.
- meta-tag n8n:config:sentry використовується фронтендом для ініціалізації Sentry telemetry;
- інстанси n8n також можна масово знаходити через Shodan або Censys за favicon hash: http.favicon.hash:-831756631;

Практичний PoC без експлуатації: curl та Burp

Ці приклади призначені для authorized testing і виконують лише fingerprinting версії через публічну сторінку. Вони не відтворюють exploit chain і не виконують RCE. 

PoC 1: curl + витяг meta + base64 decode

# 1) Отримати HTML (спробуйте /signin, якщо 404 — /login або /)
curl -sk https://TARGET/signin -o page.html

# 2) Витягнути base64 зі meta n8n:config:sentry
B64=$(grep -oE '<meta name="n8n:config:sentry" content="[A-Za-z0-9+/=]+"' page.html | sed -E 's/.*content="([^"]+)".*/\1/')

# 3) Decode і витягнути n8n@X.Y.Z
echo "$B64" | base64 -d 2>/dev/null | tr -d '\n' | sed -nE 's/.*n8n@([0-9]+\.[0-9]+\.[0-9]+).*/Detected n8n Version: \1/p'

# Очікуваний результат (приклад):
# Detected n8n Version: 1.120.3

PoC 2: перевірка діапазону вразливості локально

Minimal fix: для автоматичної перевірки “vulnerable / not vulnerable” нижче використовується груба логіка порівняння версій через sort -V (GNU coreutils). Це не змінює кроки PoC (отримати версію), лише додає локальну оцінку. 

VER=$(echo "$B64" | base64 -d 2>/dev/null | tr -d '\n' | sed -nE 's/.*n8n@([0-9]+\.[0-9]+\.[0-9]+).*/\1/p')

# Уразливі: 1.65.0 <= VER < 1.121.0
LOW="1.65.0"
HIGH="1.121.0"

# sort -V повертає найменшу версію першою
min_low_ver=$(printf "%s\n%s\n" "$LOW" "$VER" | sort -V | head -n1)
min_ver_high=$(printf "%s\n%s\n" "$VER" "$HIGH" | sort -V | head -n1)

if [ "$min_low_ver" = "$LOW" ] && [ "$min_ver_high" = "$VER" ] && [ "$VER" != "$HIGH" ]; then
  echo "VULNERABLE (version in [1.65.0, 1.121.0))"
else
  echo "NOT VULNERABLE by version check (or version not detected)"
fi

PoC 3: Burp Suite (manual)

GET /signin HTTP/1.1
Host: TARGET
User-Agent: Burp
Accept: text/html
Connection: close

Додатково.
Найчастіше meta-tag присутній на сторінці /signin, але у деяких інсталяціях він може бути також на /login або на кореневій сторінці /.

У Response Body знайдіть meta-тег з name="n8n:config:sentry" і витягніть його content (base64). Далі decode та пошук n8n@X.Y.Z аналогічно. 

<meta name="n8n:config:sentry" content="BASE64_HERE">

Обмеження виявлення

Визначення версії за відбитками (fingerprinting) може не спрацювати, якщо сторінка /signin прихована зворотним проксі або meta-тег конфігурації змінено. Версію також можуть маскувати кастомні збірки. У такому випадку доведеться перевіряти метадані контейнера або маніфести розгортання.

Навіть якщо можливість використання вразливості залежить від конфігурації, це не причина відкладати встановлення виправлення.

Ідеї для detection та моніторингу

Сигнали раннього попередження включають різке зростання нетипових запитів до /signin, /login, /rest/settings або /rest/system з невідомих джерел. Важливо відстежувати неочікувані виконання робочих процесів, читання облікових даних і незвичні виклики API до інтегрованих систем.

Фінальні роздуми

Якщо інстанс n8n доступний з Інтернету і його версія потрапляє в діапазон 1.65.0 ≤ version < 1.121.0, його слід вважати критично вразливим до неавтентифікованого RCE до моменту оновлення.

Підхід на основі виявлення дозволяє швидко скласти перелік інстансів і пріоритезувати усунення проблеми, не виконуючи ланцюг експлуатації вразливості.