OverDoS Executive Summary

The Checkmarx Zero team has discovered vulnerabilities in n8n, most notably an unauthenticated denial-of-service flaw that allows attackers to take down any internet-facing n8n instance (or indeed any instance an attacker can connect to). Tracked as CVE-2026-42236, this vulnerability has been assigned a High severity rating with a CVSS 4.0 base score of 8.7 (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). We refer to this specific vulnerability as “OverDoS”.

Alongside OverDoS, we also identified a moderate-severity Open Redirect, tracked as CVE-2026-42230, with a CVSS 4.0 base score of 5.1 (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:L/VI:N/VA:N/SC:L/SI:N/SA:N).

CVEs were published on 26. April 2026. Both issues were reported to n8n and patched promptly; our thanks to the n8n team for their exemplary handling of these issues.

Vulnerable versions:

• < 1.123.32
• < 2.18.1
• < 2.17.4

Patched versions:

Users should upgrade to one of the following patched versions:

• >= 1.123.32
• >= 2.18.1
• >= 2.17.4

Note: No setting or feature toggle mitigates this issue; for internet-facing instances, upgrading is the only fix. If upgrading is not immediately possible, restrict network access to the instance (e.g., VPN, SSO-gated reverse proxy, or IP allowlist).

Exploiting n8n OverDoS: quick video demo

Let’s start with a quick demo showing how the database size increases as unauthenticated requests are sent to the server, leading eventually to a filled database and a non-responsive instance, denying further service. This is what it looks like to exploit OverDoS:

Technical Analysis of OverDoS and Open Redirect vulnerabilities

Checkmarx Zero routinely researches popular open-source tools and frameworks including n8n, a widely used no-code workflow automation framework. (We’ve previously published a stored XSS stemming from a CSP sandbox bypass in the n8n system, for example.)

In one of our recent projects, we uncovered a high-severity unauthenticated Denial of Service (DoS) vulnerability, a moderate-severity Open Redirect flaw, and a few additional risks that organizations adopting n8n should be aware of. All of them trace back to an overly permissive feature that allows MCP clients to connect to an n8n instance: Dynamic Client Registration (DCR).

Dynamic Client Registration (DCR)

In a typical OAuth setup, registering a client is a manual job: an administrator provisions each client on the authorization server in advance, exchanging credentials and metadata out of band before the client can authenticate anyone. That works fine when you know your clients ahead of time — but this process doesn’t hold if you want clients to onboard themselves at runtime.

That’s the gap Dynamic Client Registration (DCR), defined in RFC 7591, was designed to fill. The short version is that any client can register itself against the authorization server by sending a POST request to a server endpoint (often, a publicly-accessible one), with a JSON payload describing itself (including parameters like redirect_uris, client_name, grant_types, and so on).

Just Flexible Enough to Snap Back in Your Face

Every property that makes DCR useful is also a potential entry point for an attacker’s payload.

The user input sent to that public endpoint is reused across the server’s flows. It gets persisted in a database, rendered in consent screens, used to redirect the user to attacker-supplied links, and more. Every one of those touchpoints is a place where attacker-controlled metadata can be weaponized if it isn’t tightly handled. The specifications themselves leave most of this to the implementer — rate limiting, URI validation, and endpoint authentication. All of which is a polite way of saying that every DCR-enabled server is on its own, and implementing any of those wrong (or not at all) is exactly what attackers look for.

n8n Implementation

n8n provides a DCR endpoint as part of it’s MCP (Model Context Protocol) features. It exposes MCP OAuth client registration endpoint on every default instance — and, crucially, the MCP enable/disable toggle that operators use to “turn the feature off” doesn’t block registration. It only prevents use. The endpoint stays open, anonymous, and writable whether the MCP feature is enabled or not.

The only things standing between an attacker and arbitrary writes to the database are two settings: a cap on request body size (via the N8N_PAYLOAD_SIZE_MAX environment variable, which has a 16MB default value), and a per-IP rate limit of 10 requests every 5 minutes. Multiply those together, and a single IP can shovel ~160 MB of attacker-controlled metadata into storage every five minutes.

And that per-IP restriction becomes useless as an anti-DoS measure the moment an attacker reaches for cloud infrastructure, connects via rotating VPNs, or any of the dozen other simple ways attackers can make their connections come from multiple IPs. Disk and memory are the limits; nothing in the registration path enforces a real ceiling.

OverDoS Vulnerable Blast Radius

A single Shodan query — http.title:"n8n.io - Workflow Automation" — returns just over 70,000 publicly reachable n8n instances, and that number is a floor, not a ceiling.

Every one of these instances is vulnerable by default. The bug doesn’t require a misconfiguration to trigger; the registration endpoint ships exposed, anonymous, and writable on a fresh install. And at the time of disclosure, there’s no operator-side mitigation that meaningfully shrinks that number.

Beyond OverDoS: Open Redirects and Scamming Users

The DoS is the loudest thing the registration endpoint hands an attacker, but it isn’t the only thing.

Open Redirect on Deny

Remember the attacker-controlled redirect_uri from the registration payload? n8n honors it on approval — that’s the OAuth flow doing its job. But it also honors it on deny. So the handleDeny handler sends the user to the same registered URI in both cases. Approved? You go to the attacker. Refused? Yep, still go to the attacker. There’s no third door.

const handleDeny = async () => {
	try {
		const response = await consentStore.approveConsent(false);
		window.location.href = response.redirectUrl;

The fix is as simple as changing one line: on deny, redirect to the n8n dashboard. There’s no reason to honor a destination chosen by the party that the user just declined to trust.

Dressing Up the Consent Dialog

Clicking Allow grants the MCP full access to the user’s workflows — that’s the consent flow working. The interesting question is everything that happens before the click.

And there’s a cheap move an unauthenticated attacker can pull. The client_name is attacker-supplied and rendered directly in the consent dialog. And so is the icon — n8n derives it through a simple substring match against a list of known integrations. Drop “Claude” into the client name field, and your malicious client shows up in the consent dialog with Anthropic’s logo next to it.

const clientIcon = computed(() => {
	const clientName = clentDetails.value?.clientName?.toLowerCase() ?? '';
	if (ANTHROPIC_CLIENTS.some((name) => clientName.includes(name))) {
		return 'anthropic';
	} else if (LOVABLE_CLIENTS.some((name) => clientName.includes(name))) {
		return 'lovable';
	} else {
		return 'mcp';
	}
});

This isn’t a bug in the strict sense. It’s the DCR pattern paying out exactly what it promises: whatever metadata the client supplies, the server trusts and renders. It doesn’t take much imagination to see how this plays into a social engineering attack—one that ends with an attacker listing and executing the victim’s workflows.

Could AI security tools find the OverDOS vulnerability?

No zero-day analysis today feels complete without asking what AI tools would find on the same target. The CVE had been public for two weeks at the time of running these tests, which may affect their accuracy — but here’s what Claude Opus and Codex 5.5 found when reviewing this code.

Claude Opus

We previously pointed Opus at the full n8n repository and asked it to find vulnerabilities — it missed this one. We wanted to see whether it could catch the issue when directed at the specific module and controller where the vulnerability lives.

/Security-Review the OAuth Controller

With a more focused scope, it succeeded:

/Security-Review the MCP Module

With the controller-level scan working, we widened the scope to the full MCP module. Opus still caught the issue:

Codex 5.5

Security Analysis at the Controller Level

At the controller level, Codex 5.5 (with extra-high reasoning) flagged the issue. I — and the n8n team — disagree with Codex on the severity rating given the massive potential impact, but the vulnerability was correctly identified:

Security Analysis at the MCP Module Level

With the same settings but a widened scope to the module-level scan, Codex flagged the DCR pattern as a social engineering risk (phishing via the consent screen) but missed the DoS vulnerability:

Credit to the n8n team’s partnership

One thing worth repeating: n8n takes security seriously. This is our third report to them, and every time the team has been responsive, communicative, and quick to ship fixes.

Disclosure Timeline

Open Redirect — CVE-2026-42230

• Feb 23, 2026 — Reported to n8n
• Mar 4, 2026 — Report acknowledged
• Apr 22, 2026 — Fix implemented and verified
• Apr 26, 2026 — CVE-2026-42230 assigned

Denial of Service — CVE-2026-42236

• Mar 5, 2026 — Reported to n8n
• Mar 17, 2026 — Report acknowledged
• Apr 22, 2026 — Fix implemented and verified
• Apr 26, 2026 — CVE-2026-42236 assigned