AI Threat Alert
n8n's AI Agents feature lets a member-level user who only has "use" (not "read") rights on a shared credential configure an MCP tool inside an agent workflow and point it at any URL, including a server the attacker controls — and prior to 2.27.4/2.28.1 the platform's "Allowed HTTP Request Domains" restriction, the exact control meant to stop that credential's secret from leaving an approved domain, was never enforced on that MCP tool call path. For any org running n8n as an internal automation or AI-agent orchestration hub with shared API keys, database credentials, or SaaS tokens, this turns a routine "use-only" grant into a full secret-exfiltration primitive for any authenticated low-privilege insider — no external attacker or user interaction required, and confidentiality impact is total (CVSS 6.5, C:H/I:N/A:N). It is not in CISA KEV, has no public exploit or Nuclei template, and sits at the 82nd EPSS percentile, so this reads as an insider-abuse/access-control gap rather than an imminent mass-exploitation threat. Action: patch to n8n 2.27.4 or 2.28.1 immediately, then audit which shared credentials have use-only member access and whether any AI Agent workflows contain MCP tools pointed at unexpected external domains, and review credential-usage logs for anomalous outbound calls from agent executions in the interim.
What is the risk?
Medium severity (CVSS 6.5) but high sensitivity impact: this is a pure confidentiality break of a protection mechanism (CWE-693) specifically designed to let organizations share credentials safely across users of differing trust levels. Exploitability is low-complexity and requires no user interaction, but it does require an existing authenticated account with at least use-only access to a shared credential — so exposure is bounded by n8n's own user base and RBAC, not the open internet. EPSS (0.26%, 82nd percentile) and absence from CISA KEV/no public PoC indicate no evidence of active or imminent mass exploitation. The real risk driver is n8n's growing footprint as an AI-agent/workflow backbone (129 other CVEs in the package history, OpenSSF Scorecard 6.6/10) combined with the fact that this specific control failure defeats the primary mechanism admins would rely on to safely delegate credential use to less-trusted team members or contractors.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| n8n | npm | >= 2.28.0, < 2.28.1 | 2.28.1 |
Do you use n8n? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
1) Patch n8n to 2.27.4 (2.27.x branch) or 2.28.1 (2.28.x branch) immediately — this is the only complete fix. 2) Until patched, treat any shared credential with an "Allowed HTTP Request Domains" restriction as fully exposed to all users with use-only access on that credential and reduce membership accordingly. 3) Audit existing AI Agent workflows for MCP tools configured with URLs pointing outside expected/approved domains. 4) Rotate any credentials that were shared under a use-only trust model with lower-privileged members, since the restriction may have already been silently bypassed. 5) After patching, verify enforcement by testing that an MCP tool call against a non-allowlisted domain is blocked for a use-only credential grant. 6) For detection, review outbound HTTP logs or credential-usage audit trails from n8n executions for calls to unexpected external hosts correlated with AI Agent node executions.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-59207?
n8n's AI Agents feature lets a member-level user who only has "use" (not "read") rights on a shared credential configure an MCP tool inside an agent workflow and point it at any URL, including a server the attacker controls — and prior to 2.27.4/2.28.1 the platform's "Allowed HTTP Request Domains" restriction, the exact control meant to stop that credential's secret from leaving an approved domain, was never enforced on that MCP tool call path. For any org running n8n as an internal automation or AI-agent orchestration hub with shared API keys, database credentials, or SaaS tokens, this turns a routine "use-only" grant into a full secret-exfiltration primitive for any authenticated low-privilege insider — no external attacker or user interaction required, and confidentiality impact is total (CVSS 6.5, C:H/I:N/A:N). It is not in CISA KEV, has no public exploit or Nuclei template, and sits at the 82nd EPSS percentile, so this reads as an insider-abuse/access-control gap rather than an imminent mass-exploitation threat. Action: patch to n8n 2.27.4 or 2.28.1 immediately, then audit which shared credentials have use-only member access and whether any AI Agent workflows contain MCP tools pointed at unexpected external domains, and review credential-usage logs for anomalous outbound calls from agent executions in the interim.
Is CVE-2026-59207 actively exploited?
No confirmed active exploitation of CVE-2026-59207 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-59207?
1) Patch n8n to 2.27.4 (2.27.x branch) or 2.28.1 (2.28.x branch) immediately — this is the only complete fix. 2) Until patched, treat any shared credential with an "Allowed HTTP Request Domains" restriction as fully exposed to all users with use-only access on that credential and reduce membership accordingly. 3) Audit existing AI Agent workflows for MCP tools configured with URLs pointing outside expected/approved domains. 4) Rotate any credentials that were shared under a use-only trust model with lower-privileged members, since the restriction may have already been silently bypassed. 5) After patching, verify enforcement by testing that an MCP tool call against a non-allowlisted domain is blocked for a use-only credential grant. 6) For detection, review outbound HTTP logs or credential-usage audit trails from n8n executions for calls to unexpected external hosts correlated with AI Agent node executions.
What systems are affected by CVE-2026-59207?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, MCP tool integrations, workflow automation / AI agent orchestration, credential management in agentic pipelines.
What is the CVSS score for CVE-2026-59207?
CVE-2026-59207 has a CVSS v3.1 base score of 6.5 (MEDIUM). The EPSS exploitation probability is 0.45%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0053 AI Agent Tool Invocation AML.T0086 Exfiltration via AI Agent Tool Invocation AML.T0098 AI Agent Tool Credential Harvesting Compliance Controls Affected
What are the technical details?
Original Advisory
n8n is an open source workflow automation platform. Prior to 2.27.4 and 2.28.1, the AI Agents feature did not enforce the Allowed HTTP Request Domains restriction configured on credentials when an MCP tool was pointed at an arbitrary URL, allowing a member-level user with use-only access to a shared credential to send its secret to an external server they control. This issue is fixed in versions 2.27.4 and 2.28.1.
Exploitation Scenario
An organization shares an internal API credential (e.g., a CRM or ticketing token) with a contractor or junior analyst via n8n's RBAC, granting "use" access on the credential but restricting it via Allowed HTTP Request Domains to only the vendor's official API domain, explicitly to prevent the credential value itself from being exfiltrated. The low-privileged user creates or edits an AI Agent workflow, attaches an MCP tool bound to that credential, and configures the MCP tool's target URL to point at a webhook endpoint they control (e.g., a request-bin style server). When the agent invokes the tool, n8n fails to check the destination against the credential's domain allowlist, so the full credential secret is transmitted in the outbound request to the attacker-controlled server. The attacker now holds a valid, unrestricted copy of the credential and can use it directly against the real upstream service, bypassing both the domain restriction and the original "use-only, no-read" access control entirely.
Weaknesses (CWE)
CWE-693 Protection Mechanism Failure
Primary
CWE-693 Protection Mechanism Failure CWE-693 Protection Mechanism Failure CWE-693 — Protection Mechanism Failure: The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N References
Timeline
Related Vulnerabilities
CVE-2026-33663 10.0 n8n: member role steals plaintext HTTP credentials
Same package: n8n CVE-2026-33660 10.0 TensorFlow: type confusion NPD in tensor conversion
Same package: n8n CVE-2026-21858 10.0 n8n: Input Validation flaw enables exploitation
Same package: n8n CVE-2025-68668 9.9 n8n: Protection Bypass circumvents security controls
Same package: n8n CVE-2026-27495 9.9 n8n: Code Injection enables RCE
Same package: n8n