Which versions of n8n are affected by CVE-2026-42236?

CVE-2026-42236 affects n8n workflow automation platforms, allowing unauthenticated attackers to remotely crash instances through memory exhaustion attacks on the MCP OAuth registration endpoint.. A patch is available.

How to fix or mitigate CVE-2026-42236?

Within 24 hours: Identify all n8n instances in production and verify current versions against patched releases (1.123.32, 2.17.4, or 2.18.1). Within 7 days: Upgrade all affected instances to patched versions or implement network-level access controls blocking unauthenticated requests to the MCP OAuth registration endpoint. Within 30 days: Conduct post-upgrade validation of all critical workflows and establish monitoring for abnormal memory consumption patterns.

n8n CVE-2026-42236

Q: What is the CVSS score of CVE-2026-42236?

CVE-2026-42236 has a CVSS 4.0 base score of 8.7 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.1%.

EUVD-2026-27111 HIGH

Allocation of Resources Without Limits or Throttling (CWE-770)

2026-04-29 https://github.com/n8n-io/n8n

GHSA-49m9-pgww-9vq6

Denial Of Service

8.7

CVSS 4.0 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

8.7 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Patch available

May 04, 2026 - 20:01 EUVD

Re-analysis Queued

May 04, 2026 - 19:22 vuln.today

cvss_changed

CVSS changed

May 04, 2026 - 19:22 NVD

8.7 (HIGH)

Source Code Evidence Fetched

Apr 29, 2026 - 22:01 vuln.today

Analysis Generated

Apr 29, 2026 - 22:01 vuln.today

Analysis Generated

Apr 29, 2026 - 21:30 vuln.today

CVE Published

Apr 29, 2026 - 21:19 nvd

HIGH

DescriptionGitHub Advisory

Impact

The MCP OAuth client registration endpoint accepted unauthenticated requests and stored client data without adequate resource controls. An unauthenticated remote attacker could exhaust server memory resources by sending large registration payloads, rendering the n8n instance unavailable. The MCP enable/disable toggle gates MCP access but did not restrict client registrations, meaning the endpoint is reachable regardless of whether MCP access is enabled on the instance.

The patches address the unbound registration with an upper bound of registered clients and disabling creation when MCP is disabled on the instance. Mean to restrict the payload size of requests already exist and can be used to control additional risks.

Patches

The issue has been fixed in n8n versions 1.123.32, 2.17.4, and 2.18.1. Users should upgrade to one of these versions or later to remediate the vulnerability.

Workarounds

If upgrading is not immediately possible, administrators should consider the following temporary mitigations:

Restrict network access to the n8n instance to prevent requests from untrusted sources.
Reduce the maximum accepted payload size by lowering the N8N_PAYLOAD_SIZE_MAX environment variable from its default value.

These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.

AnalysisAI

Unauthenticated remote attackers can crash n8n workflow automation instances by flooding the MCP OAuth client registration endpoint with large payloads, exhausting server memory and causing denial of service. The vulnerability affects all n8n instances regardless of whether MCP (Model Context Protocol) access is enabled, as the endpoint lacks authentication and resource controls. Vendor-released patches (1.123.32, 2.17.4, 2.18.1) impose registration limits and disable the endpoint when MCP is turned off. No public exploit identified at time of analysis, though the attack is trivial to execute given the unauthenticated nature of the endpoint.

Technical ContextAI

n8n is a workflow automation tool distributed as an npm package that includes Model Context Protocol (MCP) OAuth capabilities. The vulnerability stems from CWE-770 (Allocation of Resources Without Limits or Throttling) in the MCP client registration endpoint. This endpoint processes OAuth dynamic client registration requests per RFC 7591, but the implementation failed to implement critical security controls: it accepted unauthenticated HTTP requests, lacked rate limiting on registration operations, imposed no upper bound on the number of registered clients, and did not respect the instance-level MCP enable/disable configuration setting. The endpoint stores client metadata in server memory without size constraints, allowing attackers to craft large registration payloads that accumulate until available memory is exhausted. The default payload size limit (N8N_PAYLOAD_SIZE_MAX) exists at the HTTP layer but was insufficient to prevent resource exhaustion through repeated requests.

RemediationAI

Upgrade n8n to version 1.123.32 (for 1.x users), 2.17.4 (for 2.0-2.17.x users), or 2.18.1 (for 2.18.0 users) as documented in GitHub advisory GHSA-49m9-pgww-9vq6 at https://github.com/n8n-io/n8n/security/advisories/GHSA-49m9-pgww-9vq6. The patches implement client registration limits and disable the endpoint when MCP is turned off at the instance level. For environments where immediate patching is not feasible, implement network-level access controls using firewall rules, reverse proxy ACLs, or VPN requirements to restrict the n8n instance to trusted IP ranges - this effectively prevents unauthenticated remote exploitation but breaks legitimate public integrations and webhooks. Alternatively, reduce the N8N_PAYLOAD_SIZE_MAX environment variable from its default (16MB typical) to a lower value like 1MB to limit per-request memory allocation - this reduces but does not eliminate risk since attackers can still exhaust resources through high-volume small requests, and lowering payload limits may break legitimate workflows processing large datasets. Both workarounds have operational trade-offs and should only serve as temporary bridges to patching.