CVE-2025-68613: Authenticated Expression-Injection RCE in n8n (CWE-913) — What’s Affected, What to Patch, and How to Contain It

What CVE-2025-68613 actually is

CVE-2025-68613 affects n8n, an open-source workflow automation platform. The vulnerability is a remote code execution (RCE) issue in n8n’s workflow expression evaluation system: under certain conditions, expressions supplied by authenticated users during workflow configuration can be evaluated in an execution context that is not sufficiently isolated from the underlying runtime. An attacker can abuse that behavior to execute arbitrary code with the privileges of the n8n process, potentially leading to full compromise of the instance (data access, workflow modification, system-level operations). (NVD)

The National Vulnerability Database (NVD) entry currently shows that NVD’s own scoring enrichment is not yet provided, but it does display the CNA score from GitHub, Inc.: CVSS v3.1 base score 9.9 (CRITICAL) with vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. (NVD)

That vector matters operationally: the issue is network-reachable, low complexity, requires only low privileges, no user interaction, and has changed scope—exactly the pattern that tends to turn “an app bug” into “an environment compromise” when the service is connected to internal systems.

The weakness mapping is CWE-913. MITRE defines CWE-913 as improper control over dynamically-managed code resources (variables, objects, classes, attributes, functions, executable instructions/statements), which aligns with the “expression evaluation escapes intended isolation” nature of this issue. (cwe.mitre.org)

One table you can drop into a security advisory

Why “requires authentication” still deserves emergency handling

Treating this as “less urgent because it’s authenticated” is a common failure mode. In n8n, authenticated users are often not just admins; they can be automation builders, integration operators, or service accounts. Once the expression evaluation boundary is broken, the attacker is not limited to application actions—NVD explicitly notes arbitrary code execution with the privileges of the n8n process and the possibility of full instance compromise. (NVD)

In practice, workflow platforms concentrate three things that attackers love: broad connectivity, secrets, and logic execution. That’s why you should anchor your response plan to the CVSS vector (PR:L + S:C + C/I/A:H) rather than your intuition about “login required.” (NVD)

Patch strategy that doesn’t collapse into chaos

Your “correct” end state is simple: run a fixed version. NVD lists the issue as fixed in 1.120.4, 1.121.1, and 1.122.0. (NVD)

The n8n/GitHub advisory text highlights that the issue is fixed in v1.122.0 and recommends upgrading to 1.122.0 or later because it “introduces additional safeguards to restrict expression evaluation.” (GitHub)

Operationally, that suggests a straightforward rule:

If you can move forward safely, converge on 1.122.0+; if you are pinned to a specific release train, land on the minimum fixed versions indicated by NVD while planning a forward move as soon as feasible. (NVD)

Here’s an audit-only version checker you can run in CI, on hosts, or in a fleet job (no exploit logic, just version/risk flagging):

#!/usr/bin/env bash
# CVE-2025-68613 n8n version audit (no exploitation)

set -euo pipefail

if command -v n8n >/dev/null 2>&1; then
  VER="$(n8n --version | tr -d 'v' | head -n1)"
else
  VER="${N8N_VERSION:-unknown}"
fi

echo "n8n version detected: $VER"

# Affected range per GitHub advisory: >=0.211.0 <1.120.4
# Fixed versions per NVD: 1.120.4, 1.121.1, 1.122.0
if [[ "$VER" != "unknown" ]] && \\
   [[ "$(printf '%s\\n' "0.211.0" "$VER" | sort -V | head -n1)" == "0.211.0" ]] && \\
   [[ "$(printf '%s\\n' "$VER" "1.120.4" | sort -V | head -n1)" == "$VER" ]] && \\
   [[ "$VER" != "1.120.4" ]]; then
  echo "FLAG: Potentially affected by CVE-2025-68613. Upgrade per NVD/GitHub guidance."
  exit 2
fi

echo "No flag from this quick check. Validate against official advisory + your exact deployment details."

Short-term mitigations

Both NVD and the GitHub advisory provide the same short-term mitigations: restrict workflow creation/editing permissions to fully trusted users, and deploy n8n in a hardened environment with restricted OS privileges and network access to reduce impact—while explicitly stating these mitigations do not fully eliminate risk. (NVD)

If you want this to be enforceable, “hardened environment” should translate into runtime controls. Here is a conservative container hardening sketch to reduce post-exploitation leverage (defense-in-depth):

services:
  n8n:
    image: n8nio/n8n:1.122.0
    read_only: true
    tmpfs:
      - /tmp
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    user: "1000:1000"
    environment:
      - N8N_LOG_LEVEL=info
    # Pair with network policy / firewall:
    # deny egress by default, allow only required destinations

Detection and threat hunting: behavior over fragile signatures

Because the triggering mechanism is “expressions during workflow configuration evaluated in an insufficiently isolated context,” you can build useful detection around who is editing workflows, how often, and what the runtime does afterward. (NVD)

A practical approach that survives implementation differences is to correlate:

Unusual workflow edits by low-privilege users (or service accounts) + suspicious process execution / outbound connections from the n8n runtime. This aligns with NVD’s statement that successful exploitation may result in system-level operations executed with the n8n process privileges. (NVD)

Example auditd idea (adapt to your environment):

-a always,exit -F arch=b64 -S execve -F comm=node -k n8n_exec
-a always,exit -F arch=b64 -S connect -F comm=node -k n8n_net

Adjacent high-impact n8n CVEs you should review

If your organization relies on n8n, CVE-2025-68613 shouldn’t be treated as a one-off. Two adjacent examples illustrate a recurring theme in workflow platforms: features that blur the boundary between configuration and execution.

CVE-2025-65964 is a separate n8n issue involving the Git node: NVD describes that versions 0.123.1 through 1.119.1 lacked adequate protections to prevent RCE through Git hooks, where workflow actions could influence Git configuration (e.g., core.hooksPath) and cause hook execution; the issue is fixed in 1.119.2. (NVD)

CVE-2025-57749 is a symlink traversal vulnerability in n8n’s Read/Write File node before 1.106.0, where directory restrictions could be bypassed via symbolic links, enabling access to otherwise restricted paths. (NVD)

These are different bugs, but the same lesson: workflow engines sit dangerously close to “code and system capabilities,” so isolation, node-level guardrails, and strict privilege boundaries are not optional. MITRE’s CWE-913 definition captures why these issues reappear when dynamic code resources can be influenced unexpectedly. (cwe.mitre.org)

If your goal is an engineering closed loop—asset discovery, version validation, patch verification, and evidence-grade reporting—then an AI-driven security workflow platform like Penligent can fit naturally into the “verify fixes and regressions” phase. If your only goal is to reduce production risk immediately, the highest-leverage action remains: upgrade to the fixed versions and apply the vendor’s short-term mitigations until you can. (NVD)

https://nvd.nist.gov/vuln/detail/CVE-2025-68613
https://github.com/n8n-io/n8n/security/advisories/GHSA-v98v-ff95-f3cp
https://cwe.mitre.org/data/definitions/913.html
https://docs.n8n.io/release-notes/
https://nvd.nist.gov/vuln/detail/CVE-2025-65964
https://github.com/n8n-io/n8n/security/advisories/GHSA-wpqc-h9wp-chmq
https://nvd.nist.gov/vuln/detail/CVE-2025-57749