CVE-2025-68613 (n8n)

TL;DR

• CVE: CVE-2025-68613 — krytyczne RCE w platformie automatyzacji workflow n8n (expression evaluation / expression injection), wymagające uwierzytelnienia użytkownika (PR:L).
• Wpływ: wykonanie dowolnego kodu z uprawnieniami procesu n8n → potencjalne przejęcie instancji, modyfikacje workflow, dostęp do danych/sekretów.
• Wersje podatne: >= 0.211.0 oraz < 1.120.4 (oraz osobna gałąź >= 1.121.0 i < 1.121.1)`.
• Wersje naprawione: 1.120.4, 1.121.1, 1.122.0; rekomendacja maintainerów: upgrade do 1.122.0+ (dodatkowe zabezpieczenia).
• CVSS (CNA/GitHub): 9.9 CRITICAL, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.
• MITRE ATT&CK mapowanie (główne): T1190 Exploit Public-Facing Application (takt. Initial Access). ATT&CK v18, technika T1190 v2.8, Last Modified: 24 Oct 2025.
• Ryzyko „skali Internetu”: Censys raportował ~103,476 potencjalnie podatnych instancji (stan na 22 grudnia 2025) oraz „no known exploitation at time of writing”.

---

Krótka definicja techniczna

T1190 (Exploit Public-Facing Application) to technika Initial Access, w której atakujący wykorzystuje lukę w aplikacji/usłudze wystawionej na Internet (lub szerzej: osiągalnej z sieci), aby uzyskać dostęp i uruchomić kod w kontekście tej aplikacji. W przypadku CVE-2025-68613 wektor jest sieciowy, a „wejściem” są workflow expressions w n8n oceniane w kontekście niedostatecznie odizolowanym od runtime, co daje RCE z uprawnieniami procesu n8n.

---

Gdzie występuje / przykłady platform (Windows, AD, AWS, Azure, GCP, K8s, ESXi, M365)

Typowe środowiska dla n8n + ryzyko T1190/CVE-2025-68613:

• Windows: n8n jako proces node.exe/usługa; detekcja głównie po process creation (4688/Sysmon EID 1) i anomaliach w ruchu wychodzącym.
• Linux: najczęściej spotykane wdrożenie (bare metal/VM/containers); detekcja po execve (auditd) i potomkach procesu node.
• K8s (EKS/AKS/GKE): n8n jako Deployment/StatefulSet; ślady w K8s audit, logach Ingress (nginx/traefik), oraz w telemetrii runtime (Falco/eBPF).
• AWS: n8n na EC2/ECS/EKS; ryzyko wzrasta, jeśli instancja ma rolę IAM (po RCE możliwa kradzież tokenów z metadata). T1190 wspiera platformy IaaS/Containers.
• Azure: n8n na VM/AKS; analogicznie — MDE/AMA/Defender for Cloud do korelacji procesu i sieci.
• GCP: n8n na GCE/GKE; analogicznie — Cloud Logging + VPC Flow Logs + GKE audit.
• ESXi: n8n uruchomione jako VM; kontekst T1190 obejmuje również ESXi jako platformę (ogólnie dla public-facing usług).
• AD: sama luka nie jest „AD-specific”, ale dostęp uwierzytelniony bywa pochodną kompromitacji tożsamości/SSO. W praktyce koreluj: logowanie do n8n ↔ zmiany workflow ↔ zdarzenia na hostach domenowych, jeśli n8n ma integracje.
• M365: jeśli n8n przechowuje tokeny do M365 (Graph/Exchange/SharePoint), po przejęciu instancji ryzykujesz nadużycie tych tokenów; szukaj anomalii w M365 Unified Audit Log (operacje administracyjne, nietypowe OAuth usage).

---

Szczegółowy opis techniki (jak działa, cele, dlaczego jest skuteczna)

Mechanika (na przykładzie n8n i CVE-2025-68613)

1. Warunek wstępny: atakujący posiada dostęp uwierzytelniony do n8n (PR:L).
2. Punkt wejścia: podczas konfiguracji workflow wprowadzane są expressions (np. w polach korzystających z expression engine).
3. Błąd izolacji: w podatnych wersjach expression evaluation może odbywać się w kontekście niewystarczająco odizolowanym od runtime (CWE-913).
4. Efekt: możliwość uruchomienia dowolnego kodu z uprawnieniami procesu n8n → odczyt/zmiana workflow, dostęp do danych, potencjalne operacje systemowe.

Dlaczego to jest skuteczne w realnym środowisku

• n8n bywa wystawiane na Internet (panel edycji, webhooki, API), a workflow często przechowują sekrety i integracje (SaaS, chmury).
• Wymóg uwierzytelnienia nie „ratuje” sytuacji, jeśli:
  • konta są współdzielone,
  • brak MFA,
  • jest SSO z podatnym IdP,
  • dochodzi do przejęcia sesji/tokenów.
• Skuteczność rośnie, gdy proces n8n działa z szerokimi uprawnieniami (np. root w kontenerze, dostęp do socketa Dockera, dostęp do metadata/roli IAM, szeroki egress).

---

Artefakty i logi (tabela — EID, CloudTrail events, K8s audit, M365 operations)

Warstwa	Źródło logów / artefakt	ID / typ zdarzenia	Co polować (IOA)
Aplikacja	n8n logs (console/file, najlepiej json)	[brak EID]	Nagłe błędy evaluatora, nietypowe pola expressions, wzrost błędów 5xx w UI/API; ustaw N8N_LOG_FORMAT=json dla parsowalności.
Aplikacja	n8n “Security audit” (n8n audit, /audit)	[raport]	Wykrycie ryzykownych node’ów, niechronionych webhooków, brakujących ustawień, „outdated instance”.
Reverse proxy/WAF	Nginx/Traefik/ALB/Ingress access logs	HTTP access	Sekwencja: logowanie → edycja workflow/API → błędy 5xx/4xx → chwilę później anomalie procesowe/egress (korelacja).
Windows	Security	4688	node.exe/n8n uruchamia cmd.exe, powershell.exe lub narzędzia sieciowe (nietypowe dla automatyzacji).
Windows	Sysmon	EID 1, 3, 11	Process create + network connect + file create w krótkim oknie czasu po zmianie workflow.
Linux	auditd	execve, connect	Proces node (n8n) spawn’uje /bin/sh, interpretery, pobiera pliki, tworzy cron/systemd.
K8s	K8s audit log	create/patch/exec	Niespodziewane pods/exec, zmiany w Deployment/Secret/ConfigMap po incydencie (jeśli atak eskaluje do K8s API).
AWS	CloudTrail	AssumeRole, GetCallerIdentity, List*, Get*, Put*	Nietypowe użycie roli/kluczy przypisanych do n8n/instancji po symptomach RCE (szczególnie STS).
M365	Unified Audit Log	Operacje Exchange/SharePoint/Entra	Skok w aktywności aplikacji/OAuth (jeśli w n8n były tokeny do M365) — koreluj czasowo z przejęciem instancji.

Uwaga: część wpisów (CloudTrail/M365/K8s) jest warunkowa — zależy od tego, jakie integracje i uprawnienia ma n8n w Twoim środowisku.

---

Detekcja (praktyczne reguły)

Sigma (gotowa reguła)

title: Suspicious child process spawned by n8n / Node.js (possible n8n RCE - CVE-2025-68613)
id: 3e7b6d6a-3a33-4a23-9a9a-2c7e3b6f4c11
status: experimental
description: >
  Detects suspicious process spawning patterns where a Node.js-based n8n service spawns shells
  or common system utilities. Useful as a post-exploitation signal for CVE-2025-68613.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2025-68613
author: Badacz CVE (SOC/Blue Team)
date: 2025/12/24
tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\node.exe'
      - '\n8n.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\bitsadmin.exe'
      - '\certutil.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate automation that intentionally executes OS commands from workflows (high-risk design).
  - Maintenance scripts launched by the n8n service account.
level: high

Splunk (SPL)

Przykład dla Sysmon (EID 1) lub równoważnych zdarzeń procesu:

index=endpoint (sourcetype="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1)
(
  ParentImage="*\\node.exe" OR ParentImage="*\\n8n.exe" OR ParentCommandLine="* n8n *"
)
(
  Image="*\\cmd.exe" OR Image="*\\powershell.exe" OR Image="*\\pwsh.exe" OR Image="*\\wscript.exe" OR Image="*\\cscript.exe"
  OR Image="*\\bitsadmin.exe" OR Image="*\\certutil.exe" OR Image="*\\mshta.exe" OR Image="*\\rundll32.exe"
)
| stats count min(_time) as first_seen max(_time) as last_seen values(Computer) values(User) values(ParentCommandLine) values(CommandLine) by Image, ParentImage
| convert ctime(first_seen) ctime(last_seen)

KQL (Azure / Microsoft Defender for Endpoint)

Wariant oparty o DeviceProcessEvents:

DeviceProcessEvents
| where InitiatingProcessFileName in~ ("node.exe", "node", "n8n.exe", "n8n")
| where FileName in~ ("cmd.exe","powershell.exe","pwsh.exe","wscript.exe","cscript.exe","bash","sh")
| project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, FolderPath, SHA256
| order by Timestamp desc

CloudTrail query (AWS CLI/CloudWatch)

CloudWatch Logs Insights (przykład “polowania” na nietypowe STS/Identity po objawach kompromitacji aplikacji):

fields @timestamp, eventSource, eventName, userIdentity.type, userIdentity.arn, sourceIPAddress, userAgent
| filter eventSource in ("sts.amazonaws.com","iam.amazonaws.com")
| filter eventName in ("AssumeRole","GetCallerIdentity","CreateAccessKey","PutUserPolicy","AttachRolePolicy")
| sort @timestamp desc
| limit 200

AWS CLI (jeśli trzymasz CloudTrail w S3 i masz Athena/Glue — tutaj tylko “szkielet”; dostosuj do swojego źródła logów):

# Wyszukaj zdarzenia STS dla roli/ARN powiązanej z n8n (uzupełnij <ROLE_ARN_FRAGMENT>)
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=sts.amazonaws.com \
  --max-results 50 \
| jq '.Events[] | select(.CloudTrailEvent | contains("<ROLE_ARN_FRAGMENT>"))'

Elastic/EQL przykłady

EQL dla Elastic Endpoint / logs-*:

process
where event.type == "start"
  and process.parent.name in ("node","node.exe","n8n","n8n.exe")
  and process.name in ("cmd.exe","powershell.exe","pwsh.exe","bash","sh","wscript.exe","cscript.exe")

---

Heurystyki / korelacje (co łączyć)

Najlepiej działa korelacja „multi-sygnał” (T1190), zgodna z ideą: request → error → post-exploit behavior:

1. Ingress/WAF/Reverse proxy: nietypowe żądania do n8n + skok 4xx/5xx.
2. Aplikacja: logi n8n (w JSON) pokazują wzmożoną aktywność edycji/uruchomień workflow albo błędy w evaluacji.
3. Host/Container: proces node zaczyna tworzyć nietypowe potomki (shell/interpretery) w krótkim oknie czasu po anomaliach HTTP.
4. Egress: nowe połączenia wychodzące (szczególnie do Internetu lub do usług typu metadata 169.254.169.254 w chmurach — jeśli środowisko to umożliwia).
   MITRE opisuje taki łańcuch korelacyjny jako skuteczną strategię detekcji dla T1190 (również dla aplikacji kontenerowych i chmurowych).

---

False positives / tuning

Najczęstsze źródła FP:

• Środowiska, w których n8n z założenia uruchamia polecenia systemowe (workflow jako „orchestrator” hosta).
• Zadania administracyjne (backup, eksport, maintenance) wykonywane przez konto serwisowe n8n.

Tuning praktyczny:

• Dodaj warunek kontekstu: alertuj tylko, jeśli parent=Node/n8n uruchamia shell i jednocześnie:
  • jest „nowy” zewnętrzny kierunek egress,
  • wystąpił spike 5xx,
  • zaszła zmiana workflow/aktywacja workflow w nietypowych godzinach.
• Wykorzystaj n8n audit do identyfikacji “risky nodes”/niechronionych webhooków i potraktuj je jako wskaźnik podwyższonego ryzyka (priorytetyzacja instancji do hardeningu).

---

Playbook reagowania (kroki + komendy)

Krok 1 — identyfikacja narażenia (scoping)

• Sprawdź wersję n8n i porównaj z zakresem podatności oraz wersjami naprawionymi.
• Jeśli korzystasz z logów plikowych/JSON — upewnij się, że logowanie jest włączone i parsowalne (np. N8N_LOG_FORMAT=json, N8N_LOG_OUTPUT=file).

Przykładowe komendy (Linux/Docker, defensywne):

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'
docker inspect <n8n_container> --format '{{.Config.Image}}'
docker logs <n8n_container> --since 24h | tail -n 200

Krok 2 — natychmiastowe ograniczenie ryzyka (containment)

Zalecenia workarounds od maintainerów (tymczasowe, gdy nie możesz patchować od razu):

• Ogranicz prawa do tworzenia/edycji workflow wyłącznie do w pełni zaufanych użytkowników.
• Uruchom n8n w środowisku utwardzonym: najmniejsze uprawnienia OS, segmentacja, ograniczony egress.

Krok 3 — zebranie materiału dowodowego

• Zbierz: logi reverse proxy/WAF, logi n8n (najlepiej JSON), zdarzenia procesów na hoście, listę aktywnych połączeń, listę zmienionych plików w ostatnich 24–72h.

Przykładowe komendy (Linux):

# połączenia i procesy (triage)
ss -tpn
ps -eo pid,ppid,user,cmd --sort=-%cpu | head

# szybkie polowanie na świeże pliki (dostosuj ścieżki do wdrożenia)
find / -xdev -mtime -2 -type f 2>/dev/null | head

Krok 4 — eradication i recovery

• Upgrade do wersji naprawionej: 1.120.4 / 1.121.1 / 1.122.0, preferencyjnie 1.122.0+.
• Jeśli podejrzewasz przejęcie: potraktuj instancję jak „burned”:
  • rotuj sekrety/tokenu API używane w workflow,
  • wymuś reset sesji/kont,
  • rozważ redeploy z czystego obrazu + odtworzenie workflow z zaufanego backupu.

Krok 5 — działania po incydencie (hardening)

Odnieś się do mitigations dla T1190:

• Update Software (M1051) + procedury szybkiego patchowania,
• Network Segmentation (M1030) / DMZ,
• Filter Network Traffic (M1037) (szczególnie outbound),
• Application Isolation and Sandboxing (M1048).

---

Przykłady z kampanii / case studies

• Skala ekspozycji: Censys raportował 103,476 potencjalnie podatnych instancji (stan na 22 grudnia 2025), co typowo napędza skanowanie oportunistyczne po publikacji krytycznego RCE.
• Status exploitacji: według Censys (22 grudnia 2025) „No known exploitation at time of writing” — to nie jest gwarancja bezpieczeństwa, ale ważny punkt odniesienia w komunikacji ryzyka.
• Disclosure: advisory na GitHub opublikowano 19 grudnia 2025, jako krytyczne, z przypisaniem CWE-913 i wskazaniem patched versions.

---

Lab (bezpieczne testy) — przykładowe komendy

Poniżej bezpieczne testy dla zespołu SOC/Blue Team (bez payloadów i bez instrukcji exploitacji):

1. Weryfikacja konfiguracji logowania (parsowalność pod SIEM)
   Zgodnie z dokumentacją n8n ustaw logi na JSON i wyjście do pliku/console (w zależności od wdrożenia).

export N8N_LOG_FORMAT=json
export N8N_LOG_OUTPUT=console,file
export N8N_LOG_LEVEL=info

2. Uruchomienie security audytu n8n
   To test „higieny” instancji (risky nodes, niechronione webhooki, outdated instance).

# w środowisku testowym / na kopii instancji
n8n audit

3. Test detekcji post-exploit (symulacja TTP bez exploita)

• W labie sprawdź, czy Twoje EDR/SIEM podnosi alert, gdy proces node uruchamia nieoczekiwany interpreter/shell (symulacja kontrolowana przez administratora labu).
• Celem jest walidacja reguł Sigma/SPL/KQL/EQL z sekcji 7.

---

Mapowania (Mitigations, Powiązane techniki)

Mitigations dla T1190 (MITRE)

Z techniki T1190 wynikają szczególnie praktyczne mitygacje:

• M1048 Application Isolation and Sandboxing
• M1050 Exploit Protection (np. WAF)
• M1037 Filter Network Traffic (zwłaszcza outbound z serwera aplikacji)
• M1035 Limit Access to Resource Over Network
• M1030 Network Segmentation
• M1026 Privileged Account Management (least privilege konta usługi)
• M1051 Update Software
• M1016 Vulnerability Scanning

Powiązane techniki (praktyczne mapowanie łańcucha zdarzeń)

• T1190 Exploit Public-Facing Application (główne; wejście przez podatną instancję n8n).
• T1078 Valid Accounts (wymóg uwierzytelnienia w CVE sugeruje nadużycie kont/poświadczeń jako warunek).
• T1059 Command and Scripting Interpreter (częsty etap po RCE: uruchamianie poleceń/interpreterów).
• Dalsze (zależne od scenariusza): credential access, lateral movement, collection — zależnie od tego, jakie integracje i sekrety przechowuje n8n.

---

Źródła / dalsza literatura

• MITRE ATT&CK: T1190 Exploit Public-Facing Application (ATT&CK v18; Last Modified 24 Oct 2025). (MITRE ATT&CK)
• NVD: CVE-2025-68613 (opis, CVSS z CNA/GitHub, wektor). (NVD)
• GitHub Security Advisory (n8n): GHSA-v98v-ff95-f3cp (affected/patched, workarounds, CWE-913). (GitHub)
• Censys advisory: ekspozycja i status exploitacji (stan na 22 Dec 2025). (Censys)
• n8n Docs: Logging oraz zmienne środowiskowe logów (N8N_LOG_FORMAT, N8N_LOG_LEVEL, itp.). (n8n Docs)
• n8n Docs: Security audit (n8n audit, /audit). (n8n Docs)

---

Checklisty dla SOC / CISO

SOC (operacyjnie)

• Zidentyfikuj instancje n8n wystawione na Internet (ASM/CMDB) i sprawdź wersje vs zakres podatności.
• Włącz/utwardź logowanie n8n (JSON + centralizacja do SIEM).
• Wdróż reguły na process spawning (node→shell) + korelacje request→error→post-exploit.
• Przejrzyj uprawnienia użytkowników: kto może tworzyć/edytować workflow; ogranicz do zaufanych ról.
• Po patchu: retrospektywnie przeszukaj logi od 2025-12-19 (data disclosure) pod kątem anomalii.

CISO (zarządczo)

• Egzekwuj patch management dla internet-facing apps (SLA dla CRITICAL).
• Wymuś segmentację i ograniczenie egress dla usług automatyzacji (n8n jako high-risk).
• Zdefiniuj standard: workflow automation nie działa jako root i nie ma szerokich uprawnień do chmury bez potrzeby.
• Włącz okresowy security audit instancji (w tym “risky nodes”/webhook exposure).