Join our Newsletter — 33% off our NHI Course
Home› FAQ› Threats, Abuse & Incident Response› Is CVE-2025-68613 (n8n Improper Control of Dynamically-Managed Code…
Threats, Abuse & Incident Response

Is CVE-2025-68613 (n8n Improper Control of Dynamically-Managed Code Resources) being exploited in the wild?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2025-68613 to its Known Exploited Vulnerabilities catalogue on 11 March 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. n8n contains an improper control of dynamically managed code resources vulnerability in its workflow expression evaluation system that allows for remote code execution.

What “being exploited in the wild” means for this CVE

For a CVE, “exploited in the wild” is not a generic suspicion, it is a higher-confidence operational signal. In this case, CISA’s inclusion of CVE-2025-68613 in KEV means defenders should treat it as active exploitation, not as a theoretical n8n workflow weakness. That changes priority: exposure review, containment, and compromise checks matter immediately.

Because the flaw sits in n8n’s workflow expression evaluation system and can lead to remote code execution, the practical question is not only whether the product is internet-facing. It is whether any reachable instance can be driven into unsafe code execution through an expression path, automation workflow, or adjacent integration boundary.

For a concise reference path on how to triage confirmed exploitation, compare KEV status, and decide when emergency response is justified, use Zero-Day and Exploited Vulnerabilities Guide.

How to confirm exposure and reduce blast radius

Start by locating every n8n deployment, including test, staging, self-hosted, containerised and embedded instances. Then determine whether untrusted users, integrations, or imported workflows can influence expression evaluation. The risk is highest where the platform is broadly exposed, workflows are reused across environments, or administrative boundaries are loose.

If the instance is exposed, treat the exploit path as a code-execution problem, not just an application bug. Restrict access, remove unnecessary network reachability, and review which service accounts, connectors, and secrets the automation runtime can access. A compromised workflow engine can become a pivot point into adjacent systems very quickly.

For broader vulnerability triage and prioritisation around KEV-listed issues, the Vulnerability Management Guide is useful because it frames exposure, prioritisation, remediation SLAs, and post-fix verification as one workflow rather than separate tasks.

For official version and remediation details, use the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog rather than relying on summaries alone.

What to do if patching or mitigation must wait

If you cannot remediate immediately, the goal is to make exploitation materially harder and easier to detect. Reduce who can reach the service, disable or constrain any workflow paths that accept untrusted input, and remove excessive runtime permissions wherever possible. The more the platform can do on behalf of other systems, the more valuable it becomes to an attacker.

Where the workflow engine touches credentials, API keys, or privileged connectors, assume those values may be at risk until proven otherwise. Rotate the most exposed secrets first, especially anything used by the n8n runtime itself or by high-value downstream systems it can reach.

Because active exploitation is already confirmed, delaying action should trigger a deliberate exception process: document why the fix is deferred, what compensating controls are in place, and when the system will be retested. That is a better operational decision than treating the issue as a normal backlog item.

Risk and Threat Considerations

The main risk is that a workflow orchestration platform can become a general-purpose execution foothold. If an attacker reaches the expression evaluation path, they may move from a single vulnerable instance into connected services, stored secrets, and automation-enabled business processes.

Failure mechanism: The vulnerability allows maliciously influenced expression handling to cross into remote code execution, which can convert routine workflow processing into attacker-controlled execution. In practice, that can turn an integration layer into an initial access or persistence point.

Impact: Successful exploitation can expose credentials, tamper with workflows, and create downstream compromise across any system the n8n deployment can access. In environments that use n8n as an automation hub, the blast radius can be much larger than the vulnerable application itself.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
CIS Controls v8CIS-7 — Continuous Vulnerability ManagementActive exploitation of a CVE calls for rapid exposure review and prioritised remediation.
Recommendation — Prioritise remediation of KEV-listed exposure and verify mitigation after change.
NIST CSF 2.0ID.RA-01 — Asset Vulnerability IdentificationThis question is about confirming vulnerable exposure and exploited status for a specific asset.
Recommendation — Identify exposed n8n assets and assess exploitability against current threat intelligence.
NIST SP 800-53 Rev 5RA-5 — Vulnerability Monitoring and ScanningA KEV-listed CVE requires timely identification, tracking and verification of vulnerable deployments.
SI-2 — Flaw RemediationThe issue is a remediable software flaw with active exploitation and urgent fix requirements.
IA-5 — Authenticator ManagementThe flaw can expose credentials and secrets used by the workflow runtime and connected systems.
Recommendation — Scan for affected n8n instances and validate remediation before returning to service. Apply the vendor fix or mitigation and document exception handling until closure. Rotate exposed secrets, tokens and service credentials after confirming access paths.

Practitioner Guidance

What to prioritise: Inventory every n8n instance first, then rank them by internet exposure, privilege level, and whether they process untrusted workflow content or secrets. The most dangerous instance is usually the one that can both execute workflows and reach high-value systems.

What to verify: Confirm whether any instance has already shown unusual workflow edits, unexpected outbound connections, unexplained process execution, or secret access after the KEV publication date. If you find those signs, treat the issue as potential compromise, not just vulnerability exposure.

Decision rule: If the deployment is reachable and cannot be patched immediately, isolate it, restrict credentials, and rotate any secrets it can access before assuming the environment is clean. For this type of flaw, blast-radius reduction is part of remediation, not a separate optional task.

Practitioner takeaway: KEV inclusion means this is an active exploitation problem, so the correct response is to verify exposure, constrain execution paths, and look for compromise in the same workstream, not in sequence.

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org