n8n CVE-2025-68613 hits KEV: workflow automation is inside the agentic-AI perimeter

A Workflow-Automation CVE That Tells You Something Bigger Than the CVE

On 2026-03-11 the U.S. Cybersecurity and Infrastructure Security Agency (CISA) added CVE-2025-68613 — an authenticated remote-code-execution flaw in the workflow-expression evaluation system of the n8n workflow-automation platform — to the Known Exploited Vulnerabilities (KEV) catalog. n8n rated the bug CVSS 9.9; NIST scored it 8.8. CISA set a 2026-03-25 federal-civilian-branch remediation deadline — a two-week clock against active in-the-wild exploitation. Independent telemetry counted approximately 24,700 unpatched n8n instances still exposed online at the time of the KEV listing, with more than 12,300 in North America and more than 7,800 in Europe.

Read narrowly, that is a CVE story. An authenticated attacker with valid credentials to an n8n instance can execute arbitrary code with the privileges of the n8n process, completely compromising the workflow-automation control plane and everything it can reach. Read narrowly, the remediation is “patch the binary by the KEV deadline.” That is a true read. It is also an incomplete read.

The under-discussed angle is what the n8n KEV listing tells the agentic-DevOps category about the shape of the agentic-AI supply-chain perimeter in 2026. Through 2025 and into 2026, n8n shipped two MCP-protocol nodes that turn the workflow-automation control plane into an agent-callable surface on both sides: the MCP Server Trigger node, which exposes any published n8n workflow as an MCP-callable endpoint that external AI agents can drive; and the MCP Client Tool node, which lets the n8n AI Agent node consume external MCP servers as discoverable tools at reasoning time. n8n is no longer “a workflow-automation product with optional AI integrations.” n8n is a workflow-automation product that is part of the MCP fabric on both sides — calling AI agents and being called by AI agents — across the customer’s footprint.

That structural change applies to the whole product class. Zapier shipped first-class AI-agent integrations and AI-action triggers across 2025. Make.com (formerly Integromat) shipped AI Agents and MCP-compatible scenarios in the same window. Pipedream shipped Connect-driven AI agents. The “workflow-automation control plane” category is now the connective tissue between high-trust credential stores (the cloud, the CRM, the email system, the data warehouse, the customer’s AI service keys) and the LLM-driven agent layer that drives them. The n8n KEV listing is the first-of-its-kind receipt that this connective tissue belongs inside the agentic-AI supply-chain perimeter — and the receipt was delivered through the most authoritative channel in the U.S. cybersecurity ecosystem.

That is the structural lesson. The 2026 agentic-AI supply-chain perimeter is wider than the LLM provider, wider than the IDE host, wider than the MCP server software itself. The perimeter includes the workflow-automation control plane that sits between the credential stores and the agents.

What the n8n KEV Listing Actually Demands of a Platform Team

Five concrete obligations sit on the customer side of the workflow-automation shared-responsibility line once the agentic-AI supply-chain perimeter is taken as the operating frame. None of them is satisfied by “patch the n8n binary.”

1. Continuous inventory of every workflow-automation control plane across the customer’s footprint. Not just the official, IT-procured, IT-managed n8n / Zapier / Make.com instances. Also the shadow-IT instances — the marketing team’s Zapier account that pulls from the CRM, the customer-support team’s Make.com scenario that watches the inbox, the engineering team’s self-hosted n8n behind a Cloudflare Tunnel that orchestrates the OpenAI account, the analytics team’s Pipedream workflow that watches the data warehouse. Each instance is part of the agentic-AI supply-chain perimeter. None of them is part of the perimeter if the platform team does not have an inventory entry for it.

2. Continuous KEV-watch against the workflow-automation product class. The n8n KEV listing is the first KEV entry in the workflow-automation control-plane class against an MCP-on-both-sides product. It will not be the last. The platform team’s KEV-watch process has to include the workflow-automation product class with the same continuous-reconciliation posture the batch 29 Microsoft Defender piece established for the endpoint-protection product class: real-time KEV-channel monitoring, per-CVE-to-instance correlation, per-instance KEV-deadline reconciliation entry, automatic exception capture for misses, and per-product-version inventory pre-positioned for fast reconciliation.

3. Per-workflow stored-credential reconciliation against the customer’s secrets-management policy. Every n8n workflow that calls a downstream API stores a credential — either an n8n-managed credential reference (preferred) or a hardcoded value embedded in a workflow node parameter (the path of least resistance during development). The GitGuardian “State of Secrets Sprawl 2026” report covered in the companion piece for this batch documents the 24,008-unique-secrets-in-public-MCP-config-files exposure surface; the workflow-automation control plane is the parallel exposure surface on the AI-tool-callable side of MCP. Every credential stored in every workflow on every instance has to be reconciled against the customer’s secrets-management policy, validated against the upstream provider, blast-radius-calculated against the deployed-asset inventory, and prioritized into the revocation queue if validity verification confirms the credential is live.

4. Per-workflow capability-tier governance against the agent-callable surface. Once an n8n workflow is published as an MCP Server Trigger endpoint, any agent that can authenticate to the MCP endpoint can drive the workflow. The workflow’s authority — what cloud accounts it touches, what data it can read, what records it can write, what emails it can send, what financial actions it can take — is the workflow’s authority regardless of whether a human or an agent is driving it. The customer-side capability-tier governance has to map every published-as-MCP workflow to an Observe / Operate / Administer tier, codify the pre-authorization scope for the Operate-tier path, and require explicit approval-with-separation-of-duties for the Administer-tier path. Without that mapping, the workflow-automation control plane is a credential-store-adjacent surface with no governance scaffolding against the agent caller.

5. Immutable audit-trail entry for every workflow-automation control-plane action. Every workflow execution (whether human-triggered, schedule-triggered, webhook-triggered, or MCP-Server-Trigger-triggered), every credential reference, every workflow edit, every MCP-Server-Trigger publication / unpublication, every KEV-driven update has to land in the customer’s per-tenant audit-trail store. The audit trail is the reconciliation artifact for internal audit, external auditors, cyber-insurance underwriting, federal-contracting compliance, and the customer’s own quarterly security-posture review of the agent-callable surface.

Each of the five obligations is a continuous workload. None is achievable by a small platform team with manual processes against the 2026 product-class growth rate. The 2026 workflow-automation-control-plane posture is the active operational layer.

Why the Workflow-Automation Control Plane Is Structurally Distinct from the Surrounding Layers

The workflow-automation control plane occupies a structurally distinct position in the agentic-AI supply-chain perimeter that platform teams should understand explicitly before reasoning about the 2026 posture.

The workflow-automation control plane is the credential aggregator. Workflow-automation control planes are valuable specifically because they hold the credentials to dozens of downstream services in one place — the Salesforce credential, the HubSpot credential, the Stripe credential, the OpenAI / Anthropic credential, the AWS / GCP / Azure credential, the email-system credential, the data-warehouse credential, the project-management-tool credential. A single n8n compromise yields access to the union of those credentials. The MCP-callable expansion adds the agentic dimension to the existing credential-aggregation dimension.

The workflow-automation control plane is the orchestration layer between the credential stores and the agents. The agent does not call the downstream API directly in the MCP-on-both-sides pattern. The agent calls the MCP Server Trigger endpoint published by the workflow, and the workflow calls the downstream API with the stored credential. That indirection is the whole point of the MCP-on-both-sides design — it lets the customer build a once-and-reuse-many tool catalog for the agent to call, with the customer’s secrets-management policy enforced at the workflow layer. The indirection is also what makes the workflow-automation control plane a high-leverage target for the attacker: compromise the workflow, and you have arbitrary code execution at the orchestration layer between every credential store and every agent caller in the customer’s footprint.

The workflow-automation control plane is below the LLM-provider perimeter and above the cloud-provider perimeter. Every existing security framework treats the LLM-provider perimeter (Anthropic, OpenAI, Google AI Studio) and the cloud-provider perimeter (AWS, GCP, Azure) as first-class. Most existing security frameworks do not treat the workflow-automation control plane as first-class — it is treated as a SaaS product the procurement-and-security team approved once and then handed off to the business team. The n8n KEV listing is the empirical case that this treatment is no longer adequate. The workflow-automation control plane is first-class.

See the IAN team run on your cloud. We connect to your AWS account via a scoped read-only role, run the Observe-tier agents, and leave you with a concrete audit report — cost waste, security exposure, compliance gaps, and a labor-offset estimate. You keep the findings regardless of next steps. Get a free infrastructure audit →

What the n8n KEV Listing Means for the Platform-Engineering Roadmap

Four operational questions the n8n KEV listing shifts for the 2026 platform-engineering roadmap.

• The workflow-automation product class is now part of the security-agent KEV-watch backlog as a first-class product class. Not as a secondary SaaS product to check on annually — as a first-class product class with continuous KEV-watch, per-instance version inventory, and per-instance KEV-deadline reconciliation, alongside the endpoint-protection class, the identity-provider class, the container-runtime class, and the cloud-managed-service class.
• The shadow-IT inventory of workflow-automation instances is the gap. Most customer footprints have more workflow-automation instances than the platform team knows about. The inventory primitive needs to scan the customer’s network egress logs, the customer’s SSO sign-in event stream, the customer’s cloud-account managed-service inventory, and the customer’s domain-name and TLS-certificate transparency log to surface the shadow-IT instances. Surfacing the instance is step one; bringing it into the customer’s secrets-management and capability-tier governance scope is step two.
• The per-workflow capability-tier mapping is the executable governance. A workflow that reads from a cloud account is Observe-tier. A workflow that writes to a cloud account in a reversible / scoped way is Operate-tier. A workflow that holds IAM, billing, or org-wide authority is Administer-tier. The mapping is per-workflow, codified, audit-trailed, and enforced at the MCP-callable boundary. Without that mapping, the MCP-callable boundary is a credential-store-adjacent boundary without governance scaffolding.
• The agent-callable workflow is itself part of the customer’s deployed-asset inventory. Once a workflow is published as an MCP Server Trigger endpoint, it is a callable component of the customer’s runtime surface — not a passive automation artifact. The resource-operations-agent’s inventory has to capture the workflow as a deployed asset, with the per-workflow capability-tier mapping, the per-workflow stored-credential reference, the per-workflow last-published timestamp, and the per-workflow execution-rate baseline.

The Workflow-Automation Posture Crosses Two Agent Pillars

The continuous workflow-automation-control-plane posture sits at the intersection of two agent pillars on the active operational layer.

• Security agent. Watches the CISA KEV catalog and the vendor PSIRT channels (n8n GitHub security advisories, Zapier security bulletins, Make.com security notes, Pipedream security advisories) for every CVE that lands against the workflow-automation product class. Correlates every CVE add to the customer’s workflow-automation instance inventory. Watches every per-workflow stored credential against the customer’s secrets-management policy. Validates every credential against the upstream provider. Surfaces unsafe gaps (a published-as-MCP workflow holding a high-blast-radius credential without an Administer-tier capability-tier mapping, a shadow-IT instance without a KEV-deadline-reconciliation entry) as Operate-tier remediation candidates.
• Resource-operations agent. Maintains the live inventory of every workflow-automation instance across the customer’s footprint — official, shadow-IT, self-hosted, SaaS. Each entry captures the product, the version, the per-workflow set, the per-workflow capability-tier mapping, the per-workflow stored-credential reference catalog, the per-workflow last-published timestamp, the per-workflow execution-rate baseline, and the per-instance KEV-deadline-reconciliation status. The inventory is the input the security agent reads to compute every per-CVE reconciliation and every per-workflow governance scaffolding decision.

How IAN Helps: The Security and Resource-Operations Agents on the Active Operational Layer

IAN is the AI DevOps team for cloud infrastructure, delivered as a coordinated team of specialized agents on the active operational layer. The n8n CVE-2025-68613 KEV listing is the first-of-its-kind receipt for the category IAN has been building toward in the agentic-AI supply-chain perimeter.

• Security agent workflow-automation channel. The security agent watches the CISA KEV catalog and the workflow-automation-product-class PSIRT channels in real time. Correlates every CVE add to the customer’s workflow-automation instance inventory. Validates every per-workflow stored credential against the upstream provider. Surfaces every gap as an Observe-tier audit-trail entry with an Operate-tier remediation PR against the customer’s secrets-management policy or the workflow-automation control plane’s patch-deployment pipeline.
• Resource-operations agent workflow-automation inventory. The resource-operations agent maintains a live inventory of every workflow-automation instance across the customer’s footprint — including the shadow-IT instances surfaced by the network-egress / SSO / cloud-managed-service / TLS-certificate-transparency scan. Each entry captures the per-workflow capability-tier mapping, the per-workflow stored-credential reference catalog, and the per-instance KEV-deadline-reconciliation status.
• Capability-tier governance on every workflow-automation action. Observe-tier scans (KEV channel monitoring, per-workflow stored-credential reconciliation, per-instance KEV-deadline reconciliation, per-workflow execution-rate baseline) run automatically. Operate-tier remediations (per-workflow secrets-policy drift correction, per-instance patch-deployment pipeline trigger, per-workflow capability-tier-mapping drift correction) require pre-authorization once. Administer-tier actions (high-blast-radius workflow capability-tier promotion, organization-wide workflow-automation policy edits, separation-of-duties policy edits) require explicit human approval with separation-of-duties.
• BYOK on model keys. Customers bring their own Anthropic / OpenAI keys. The agent layer does not see workflow-automation perimeter management as an LLM-call-markup opportunity. Pricing is usage-based on orchestration actions, with a monthly minimum.
• MCP-first interface. The IAN agent team is itself reachable from Claude, Claude Code, Cursor, and any MCP-compatible client. The same MCP fabric that turned the workflow-automation control plane into a first-class agent-callable surface is the fabric the customer uses to drive the agent team.
• Immutable audit trail. Every KEV add, every per-workflow reconciliation, every credential revocation, every capability-tier mapping change, every Administer-tier approval lands in the customer’s per-tenant audit-trail store.

The Three-Phase Rollout

Phase 1 — Observe the workflow-automation-control-plane footprint across the customer’s network. Run the security and resource-operations agents in Observe mode against the customer’s network-egress logs, SSO sign-in event stream, cloud-managed-service inventory, and TLS-certificate transparency log. Produce the workflow-automation instance inventory (official + shadow-IT), the per-instance KEV-deadline reconciliation baseline, the per-workflow stored-credential catalog with validity verification results, and the per-workflow capability-tier mapping draft. Two-to-four weeks.

Phase 2 — Codify the per-tier scope and promote to Operate-tier. Pre-authorize the Operate-tier scope for the per-instance patch-deployment pipeline trigger, the per-workflow secrets-policy drift correction, and the per-workflow capability-tier-mapping drift correction. Codify the Administer-tier approval policy for high-blast-radius workflow capability-tier promotion, organization-wide workflow-automation policy edits, and separation-of-duties enforcement. Two-to-three months.

Phase 3 — Cross the security / resource / deployment / cost agent loop. Every workflow-automation KEV reconciliation feeds the deployment-agent’s patch-window planner. Every workflow-stored credential revocation feeds the deployment-agent’s release-window planner (for the consuming systems). Every per-workflow execution-rate anomaly feeds the cost-agent’s spend-regression watch. The team coordinates as a team.

The 2026-03-11 n8n KEV listing is the first-of-its-kind receipt that workflow-automation control planes belong inside the agentic-AI supply-chain perimeter. The structural response is the active operational layer — a coordinated team of specialized agents that runs the perimeter, with humans in the loop only where judgment matters. That is the shape IAN delivers.

Get a free infrastructure audit → | See pricing →