Security
• 1 min read
  • security
  • vulnerabilities
  • kev
  • automation

CISA adds n8n remote code execution flaw to KEV catalog after active exploitation

CISA has added CVE-2025-68613, an n8n improper control of dynamically managed code resources vulnerability, to its Known Exploited Vulnerabilities catalog based on evidence of active exploitation.

Summary

CISA has added CVE-2025-68613, an n8n improper control of dynamically managed code resources vulnerability, to its Known Exploited Vulnerabilities catalog based on evidence of active exploitation. The update is narrow in scope, but it matters because KEV inclusion turns a product-specific bug into a priority remediation item for any organisation running exposed or internet-reachable n8n instances.

What happened

On 11 March 2026, CISA announced that it had added one new vulnerability to the Known Exploited Vulnerabilities catalog: CVE-2025-68613, affecting n8n. CISA describes the issue as an improper control of dynamically managed code resources vulnerability and said the addition was based on evidence of active exploitation.

Under Binding Operational Directive 22-01, KEV additions trigger formal remediation expectations for US federal civilian agencies. CISA also continues to use the catalog more broadly as a signal to all organisations that a vulnerability has moved beyond theoretical risk and into active attacker use.

Who is affected

  • organisations using n8n for workflow automation, integrations, or internal process orchestration
  • teams running self-hosted n8n instances exposed to the internet or reachable from less-trusted network segments
  • defenders responsible for patching, logging, and validating compromise on automation platforms that often hold privileged credentials

Key details

  • CISA added CVE-2025-68613 to the KEV catalog on 11 March 2026
  • the affected product is n8n
  • CISA characterises the flaw as an improper control of dynamically managed code resources vulnerability
  • the listing is based on evidence of active exploitation, not just vendor disclosure or theoretical severity
  • KEV inclusion means the issue should be treated as a live remediation priority rather than routine backlog work

Why it matters

Workflow automation tools are easy to underestimate because they often sit between systems rather than at the centre of them. In practice, that can make them unusually sensitive. They may hold API keys, SaaS tokens, database credentials, webhook secrets, and logic connecting multiple business systems.

That is why active exploitation against an n8n flaw deserves more attention than a generic one-line KEV update might suggest. If an attacker gains code execution or abuses dynamic code-handling in an automation platform, the likely blast radius is not confined to that one service.

Assessment

This is strong enough to treat as an operational signal, but not because the advisory itself is rich in detail. The important point is that CISA saw enough evidence of real-world exploitation to elevate the issue into KEV. For defenders, that should trigger two questions immediately: whether n8n is present anywhere in the environment, and whether anyone is treating it like low-risk glue infrastructure instead of a privileged execution surface.

The broader lesson is familiar: orchestration and automation platforms often accumulate trust quietly. When one of them lands in KEV, teams should assume the problem is not just patching speed but also secret exposure, workflow abuse, and downstream system access.

Key follow-on points to watch include:

  • whether vendor or third-party reporting clarifies the exact exploitation path and affected versions
  • whether incident responders start disclosing post-compromise abuse of credentials or connected systems through n8n
  • whether organisations revisit how much privilege and network reach their automation platforms really have
  • identify whether n8n is present in your environment, including test, shadow IT, and self-hosted deployments
  • prioritise remediation for affected instances and verify exposure from the public internet or semi-trusted internal segments
  • review what secrets, tokens, connectors, and downstream systems the platform can access if compromised
  • preserve logs and investigate for signs of suspicious workflow execution, code handling, or credential abuse where relevant
  • monitor follow-on vendor and CISA guidance for version-specific remediation and compromise indicators

Further reading