n8n Had Four Critical Security Flaws in Two Weeks. Here’s What Small Business Owners Need to Know.

In the span of two weeks, n8n disclosed four critical security vulnerabilities. One of them carries a CVSS score of 10.0, the highest the scale goes. Another allows attackers to run arbitrary code on your server without ever logging in. A third and fourth, both disclosed March 25, score CVSS 9.4 each and both allow authenticated code execution.

As of late March 2026, roughly 24,700 self-hosted n8n instances remain on vulnerable versions.

If your business runs automations, this is worth understanding. Not because it is cause for panic, but because it illustrates clearly what can happen when automation infrastructure is treated as a set-it-and-forget-it system.

What Happened

The trouble started in early March with CVE-2026-21858, nicknamed Ni8mare by researchers. The vulnerability lives in n8n's webhook handler. An attacker who knows your n8n instance is publicly accessible can send a crafted HTTP request to a webhook endpoint and execute arbitrary code on your server. No credentials required. No authentication. Nothing.

CVSS 10.0 is the ceiling. CISA flagged it as actively exploited in the wild and set a patch deadline for federal agencies. That deadline passed March 25.

A second vulnerability, CVE-2025-68613, rated CVSS 9.9, was disclosed alongside Ni8mare. It allows authenticated users to escalate their access and run code with n8n process-level privileges.

Then on March 25, two more flaws were published: CVE-2026-33660 and CVE-2026-33696. Both CVSS 9.4. Both authenticated code execution on the server.

Four critical or high-severity vulnerabilities in fourteen days. Patched versions exist: 2.14.1 and 2.13.3 for the 2.x branch, and 1.123.27 for older installs. Thousands of instances are still running vulnerable versions.

Why This Is Different From a Typical Bug

Most software bugs are annoying. A vulnerability in your invoicing tool might break a feature. A bug in your scheduling app might cause a double booking. These are recoverable problems with limited blast radius.

n8n is different because of what it touches. It is the connective tissue between your tools. Your CRM, your email platform, your payment processor, your accounting software, your calendar. Every connection between those systems runs through n8n, and every connection requires credentials. API keys. OAuth tokens. Login details.

n8n stores all of them.

A compromised n8n instance does not just expose n8n. It exposes every service connected to it. An attacker who exploits Ni8mare on a vulnerable instance gets access to your n8n process, which means access to every stored credential. That could be your GoHighLevel account, your Stripe keys, your Google Workspace tokens, your Airtable API, anything wired into your workflows.

This is the unique risk of automation infrastructure: when the connective tissue gets compromised, everything downstream goes with it.

Are You Affected?

The first question is whether you are even running self-hosted n8n.

If you are on n8n's cloud platform at app.n8n.cloud, you are not affected. The cloud version is managed and patched at the infrastructure level by n8n. No action required on your end.

If you are running a self-hosted instance on a VPS, a local server, or a cloud provider, you need to check your version today. Open your n8n instance, go to Settings, and find the version number. The patched versions are 2.14.1 for current installs, 2.13.3 for 2.x installs, and 1.123.27 for older installs.

Beyond patching, two additional steps are worth taking regardless of your version status. First, review every credential stored in your n8n instance and rotate any API keys that were active during the exposure window. Credentials that were accessible during a known vulnerability period should be treated as potentially compromised. Second, audit your webhook endpoints. Any webhook that is publicly accessible deserves a second look to confirm it is doing only what you intended.

If you are not technical enough to verify your version, check your endpoint exposure, or rotate credentials without risk of breaking your live workflows, that is exactly what the Vectis n8n Security Audit is for.

What This Tells Us About Automation Infrastructure

Self-hosted automation is not inherently risky. n8n is a powerful platform, and running it on your own infrastructure gives you flexibility that cloud tools cannot match. This story is not an argument against n8n or against self-hosted automation.

But it is an argument against treating automation infrastructure the way most small businesses treat it: install it, connect everything, and move on.

Software has vulnerabilities. That is not unique to n8n. It is true of every piece of software in your stack. What matters is whether someone is paying attention when those vulnerabilities are disclosed. Whether patches get applied. Whether credentials get rotated. Whether your webhook exposure is reviewed periodically.

For most small businesses, that person does not exist on the payroll. The business owner is running crews, managing properties, or handling clients. Watching for CVE disclosures is not in the job description. And so a CVSS 10.0 vulnerability sits unpatched for weeks while the business runs on top of it.

The businesses that will get hurt by this are not the ones who chose automation. They are the ones who set it up and walked away. One compromised instance hands over every connected service's credentials. That is not a recoverable situation over the weekend.

What To Do Right Now

If you are running self-hosted n8n, update immediately. Do not wait. The Ni8mare vulnerability has been public since early March and exploit code exists in the wild.

After patching, rotate your API keys. Every credential stored in n8n during the exposure window should be treated as potentially compromised until you can confirm otherwise. This includes your CRM API key, your email platform token, your payment processor keys, and anything else connected to your workflows.

Then audit your webhooks. Find every publicly accessible endpoint in your n8n instance and confirm it is protected the way you intended. Add IP allowlisting where appropriate. Disable anything you no longer use.

If you are not technical enough to do this without risk of breaking your live automations, do not try to figure it out on your own. Get someone who knows n8n to verify your setup. The window to act is now, not after something goes wrong.

This is also a good moment to ask a broader question: who in your business is responsible for watching your automation infrastructure? If the honest answer is nobody, that is the real gap to close.