Огляд CVE-2026-21858 та Ni8mare для команд безпеки

CVE-2026-21858 (codename: Ni8mare) — критична уразливість у self-hosted n8n, яка за певних умов дозволяє unauthenticated attacker перейти від доступу до локальних файлів до повного takeover інстансу (включно з RCE-ланцюжком). Цей write-up фокусується на відтворюваному detection PoC: як безпечно (без експлуатації) ідентифікувати потенційно вразливі інстанси за версією, витягнутою з публічних сторінок n8n. 

Ключові факти

• CVE: CVE-2026-21858
• Продукт: n8n (workflow automation platform)
• Вектор: Network, без authentication, без user interaction
• Root cause: Content-Type confusion у form/webhook request handling
• Affected: версії починаючи з 1.65.0 та нижче 1.121.0 (patched у 1.121.0)

Технічний опис: Content-Type confusion у form-based workflows

Проблема виникає на межі обробки HTTP request для webhook/form сценаріїв: n8n некоректно інтерпретує (або змішує) семантику Content-Type для form submission, що призводить до обходу очікуваних перевірок і некоректного формування server-side структур даних. У “поганій” комбінації конфігурації та workflow-логіки це відкриває шлях до server-side file access (наприклад, читання локальних файлів), а далі — до підвищення привілеїв та компрометації (ланцюжок залежить від того, як саме інстанс розгорнутий, які secrets/keys доступні, і які workflows активні). 

Задіяні компоненти

• HTTP layer: routing до /signin, /login та інших публічних сторінок (для detection — лише читання HTML)
• Workflow execution surface: form/webhook handling middleware (для самої уразливості)
• Secrets storage / DB / config artifacts (як потенційні high-value targets у разі експлуатації)

Impact: бізнес-наслідки критичного RCE ризику в n8n

n8n часто виступає “інтеграційною шиною” між внутрішніми системами (CRM/ERP, IAM, cloud accounts, ticketing, CI/CD). Компрометація n8n може конвертуватися у компрометацію підключених систем через збережені credentials, API tokens, webhooks і service accounts. 

• Зрив процесів: зупинка автоматизацій, інциденти у ланцюжках постачання (supply-chain у межах бізнес-процесів)
• Витік даних: витік PII/финансових даних/інтеграційних токенів
• Фінансові втрати: простій, відновлення, форензика, можливий ransomware-impact
• Репутаційні втрати: компрометація інтеграцій і third-party сервісів через довірені токени

Рекомендації для менеджерів: OWASP / CIS / NIST орієнтири

Нижче — практичні кроки, узгоджені з common best practices: vulnerability management, secure configuration, least privilege, network exposure reduction, monitoring and incident response readiness. 

Негайні дії (72 години)

• Patch management: оновити n8n до 1.121.0+ у всіх середовищах (prod/stage/dev, включно з ephemeral)
• Exposure reduction: прибрати публічний доступ до n8n (VPN / IP allowlist / private ingress). Якщо публічний доступ критичний — мінімізувати attack surface (reverse proxy rules, доступ лише до необхідних endpoints)
• Secrets hygiene: ініціювати rotation для tokens/credentials, які зберігаються/використовуються n8n, особливо якщо інстанс був Internet-facing
• Incident readiness: зібрати inventory інстансів n8n (asset management), визначити owners, критичні workflows, інтеграції та залежності

Середньострокові дії (2–4 тижні)

• Hardening: застосувати CIS-style hardening для host/container (read-only filesystem де можливо, мінімальні capabilities, non-root, network policies)
• Least privilege: переглянути permissions service accounts і токенів, які використовує n8n (мінімально необхідні scopes)
• Monitoring: централізувати access logs / audit trails, додати алерти на аномальні звернення до n8n
• SDLC: security review для workflows, що приймають зовнішній input (особливо form/webhook), додати validation/sanitization на рівні workflow design

Чому detection PoC працює: data flow і точка спостереження

Detection не експлуатує уразливість. Він лише читає публічну HTML сторінку n8n (наприклад /signin) і витягує Base64-рядок з meta-тегу конфігурації. У цьому base64 payload зазвичай присутній маркер пакету на кшталт n8n@X.Y.Z, за яким можна визначити версію. Далі виконується просте правило: якщо версія у діапазоні 1.65.0 ≤ version < 1.121.0, інстанс вважається потенційно вразливим і потребує негайного remediation. 

Canonical PoC: Nuclei template (detection)

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”*

Практичний 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

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

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

Workarounds, обмеження та нюанси detection

• Патч є єдиним надійним remediation: оновлення до 1.121.0+.
• Fingerprinting може не спрацювати, якщо сторінка /signin недоступна, прихована reverse proxy, або meta n8n:config:sentry відсутній/змінений.
• Версія може бути замаскована кастомним build або template; у такому випадку версію треба визначати іншим способом (package metadata у контейнері, deployment manifests, logs).
• Навіть якщо версія вразлива, реальний exploitability може залежати від конкретних workflows та конфігурації — але це не зменшує ризик і не є підставою відкладати patch.

Detection ideas: що логувати та як ловити спроби сканування

Нижче — практичні detection ідеї, які не потребують knowledge про конкретний exploit payload і підходять для early warning. 

• Алерти на аномальну частоту GET до /signin, /login та / (enumeration/fingerprinting) з різних IP або з "scanner-like" User-Agent.
• Reverse proxy/WAF: кореляція spikes по 4xx/5xx на n8n з ростом запитів на public endpoints.
• Зміни у workflow execution: несподівані execution без очікуваних triggers, або execution у неробочий час.
• Secrets access patterns: читання/експорт credentials, незвичні API calls до інтеграційних систем (SIEM/UEBA кореляція).

Підсумок: як діяти безпечно

Якщо інстанс n8n Internet-facing і його версія потрапляє у діапазон 1.65.0 ≤ version < 1.121.0 — вважайте ризик критичним. Detection PoC вище дозволяє швидко скласти inventory і пріоритезувати remediation без виконання exploit chain.