What Happened
On March 5, 2025, CISA added CVE-2025-68613 to its Known Exploited Vulnerabilities catalog. This vulnerability affects n8n, a workflow automation platform used to connect APIs and automate business processes. With a CVSS score of 9.9, this remote code execution flaw allows attackers to execute arbitrary code on vulnerable instances.
Despite the availability of a patch since the vulnerability's disclosure, more than 24,700 n8n instances remain exposed online, primarily in North America and Europe. CISA has mandated federal agencies patch by March 25, 2026, but the vulnerability is already under active exploitation.
Timeline
Understanding the sequence of events is crucial:
- Vulnerability disclosed — n8n maintainers release patch
- Active exploitation detected — attackers begin targeting vulnerable instances
- March 5, 2025 — CISA adds CVE-2025-68613 to KEV catalog
- Current state — 24,700+ instances remain unpatched
- March 25, 2026 — Federal deadline for remediation
The gap between patch availability and the current exposure window highlights a breakdown in vulnerability management for many organizations.
Which Controls Failed
No Automated Asset Discovery
You cannot patch what you don't know exists. The 24,700 exposed instances suggest organizations lack visibility into their internet-facing automation platforms. This violates NIST 800-53 Rev 5 control CM-8 (System Component Inventory), which requires maintaining current inventories of system components.
If you're running n8n, you should know where every instance resides — cloud accounts, developer workstations, staging environments, and forgotten proof-of-concepts. Shadow IT deployments are particularly dangerous for tools like n8n that developers can quickly deploy.
No Risk-Based Patching Workflow
A 9.9 CVSS score with active exploitation should trigger emergency patching procedures. The fact that tens of thousands of instances remain vulnerable months after patch availability indicates organizations are either:
- Treating all vulnerabilities equally
- Lacking processes to escalate critical vulnerabilities
- Unable to deploy patches without extensive testing cycles
This violates PCI DSS v4.0.1 Requirement 6.3.3, which mandates addressing critical security vulnerabilities within one month of release. For actively exploited vulnerabilities in internet-facing systems, one month is already too slow.
Insufficient Internet Exposure Management
These instances are exposed online, discoverable via Shodan, Censys, or basic port scanning. Organizations failed to implement network segmentation or access controls that would limit exposure.
ISO 27001 control A.8.20 (Networks Security) requires appropriate controls to protect information in networks. An automation platform handling API credentials and business workflows should never be directly internet-accessible without authentication layers, VPN requirements, or IP allowlisting.
Missing External Attack Surface Monitoring
Your security team should have discovered these exposed instances before attackers did. The gap represents a failure in continuous attack surface monitoring — a core requirement under NIST CSF function "Identify" (ID.AM-2: Software platforms and applications are inventoried).
What the Standards Require
PCI DSS v4.0.1 Requirement 6.3.3 states: "Security vulnerabilities are identified and addressed as follows: Critical or high security vulnerabilities are resolved based on the risk they pose to the environment."
For a 9.9 CVSS vulnerability under active exploitation affecting an automation platform that likely handles payment data connections, this means emergency patching within days, not months.
NIST 800-53 Rev 5 SI-2 (Flaw Remediation) requires organizations to:
- Install security-relevant software updates within organization-defined time periods
- Incorporate flaw remediation into configuration management processes
- Employ automated mechanisms to determine the state of system components regarding flaw remediation
The 24,700 exposed instances demonstrate failures across all three requirements.
SOC 2 Type II CC7.1 (Common Criteria 7.1) requires entities to identify, report, and act upon system security incidents, including vulnerabilities. If you're claiming SOC 2 compliance while running unpatched critical vulnerabilities under active exploitation, your next audit will have findings.
Lessons and Action Items
1. Implement Emergency Patching Procedures
Create a documented process that triggers when:
- CISA adds a vulnerability to the KEV catalog
- CVSS score exceeds 9.0 AND exploitation is detected
- The vulnerability affects internet-facing systems
Your emergency process should bypass normal change management for critical vulnerabilities. Document the exception process, but don't let change advisory boards delay patching a 9.9 RCE under active exploitation.
Action: Draft an emergency patch policy that defines severity thresholds, approval chains, and maximum time-to-patch for critical vulnerabilities. Get it approved by your CISO before the next incident.
2. Deploy Continuous External Attack Surface Monitoring
Use tools like Censys, Shodan, or commercial attack surface management platforms to discover your internet-facing assets. Run weekly scans and alert on new discoveries.
Action: Search Shodan right now for your organization's IP ranges and domains. Filter for n8n, but also look for other automation platforms, databases, and admin panels that shouldn't be public.
3. Inventory Your Automation and Integration Platforms
n8n isn't the only workflow tool developers deploy. Also inventory: Zapier, Make (formerly Integromat), Apache Airflow, Prefect, and any custom automation scripts.
Action: Query your cloud providers' APIs for instances running these platforms. Check developer workstations. Review expense reports for SaaS subscriptions your security team doesn't know about.
4. Require Network Segmentation for Automation Platforms
Workflow automation tools handle API keys, database credentials, and business logic. They should live in isolated network segments with strict access controls.
Action: If your n8n instances are internet-accessible, put them behind a VPN or implement IP allowlisting today. For cloud deployments, use security groups or network policies to restrict access to specific CIDR ranges.
5. Subscribe to CISA KEV Updates
When CISA adds a vulnerability to the KEV catalog, it's because they've observed exploitation targeting federal networks. Treat KEV additions as "patch now" signals.
Action: Subscribe to CISA's KEV feed and route alerts to your vulnerability management team's Slack or Teams channel.
The 24,700 exposed n8n instances aren't the result of a sophisticated zero-day. They're the result of organizations failing to execute basic vulnerability management when a patch was available and exploitation was public. Your team can do better.
