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.0oraz< 1.120.4(oraz osobna gałąź>= 1.121.0i< 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 procesunode. - 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)
- Warunek wstępny: atakujący posiada dostęp uwierzytelniony do n8n (PR:L).
- Punkt wejścia: podczas konfiguracji workflow wprowadzane są expressions (np. w polach korzystających z expression engine).
- Błąd izolacji: w podatnych wersjach expression evaluation może odbywać się w kontekście niewystarczająco odizolowanym od runtime (CWE-913).
- 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: highSplunk (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 descCloudTrail 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 200AWS 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:
- Ingress/WAF/Reverse proxy: nietypowe żądania do n8n + skok 4xx/5xx.
- Aplikacja: logi n8n (w JSON) pokazują wzmożoną aktywność edycji/uruchomień workflow albo błędy w evaluacji.
- Host/Container: proces
nodezaczyna tworzyć nietypowe potomki (shell/interpretery) w krótkim oknie czasu po anomaliach HTTP. - Egress: nowe połączenia wychodzące (szczególnie do Internetu lub do usług typu metadata
169.254.169.254w 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 auditdo 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 200Krok 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 | headKrok 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):
- 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- Uruchomienie security audytu n8n
To test „higieny” instancji (risky nodes, niechronione webhooki, outdated instance).
# w środowisku testowym / na kopii instancji
n8n audit- Test detekcji post-exploit (symulacja TTP bez exploita)
- W labie sprawdź, czy Twoje EDR/SIEM podnosi alert, gdy proces
nodeuruchamia 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).
