How to Check If Your n8n Instance Is Exposed to the Internet

Introduction

Self-hosted n8n holds the keys to everything it automates, so an instance that answers on the public internet is a credential store with a front door. Most exposed instances were never meant to be public. A Docker run flag, a rebuilt container, or a missing firewall rule leaves port 5678 open, and internet scanners find it within days. This tutorial shows you how to check your own instance the way an attacker would, using your server, a second network, and the public scanner databases, and how to close the gap if you find one.

Quick answer

Run ss -tlnp on your server: if port 5678 listens on 0.0.0.0, test it from another network with curl. If the editor loads without a login, your instance is exposed, so close it behind a firewall and reverse proxy.

Evidence

The exposure problem is measured, not theoretical. Censys counted 113,926 internet-exposed n8n hosts in its State of the Internet report released October 14, 2026, making n8n the single most exposed AI product on the public internet, and 76% of hosts with a parseable version ran a version affected by at least one recent critical vulnerability (Censys State of the Internet). Exposed AI systems overall grew 63% in nine months, to nearly 268,000.

The vulnerability that makes exposure dangerous has a name and a number. CVE-2025-68613 is a remote code execution flaw in n8n’s expression evaluation engine, scored CVSS 9.9, affecting versions 0.211.0 through 1.120.3 and patched in 1.120.4, 1.121.1, and 1.122.0. CISA added it to the Known Exploited Vulnerabilities catalog on March 11, 2026, which confirms active exploitation. Criminal IP’s scan found 83,602 n8n instances directly reachable from the public internet, identified by the n8n editor page title alone.

n8n’s own documentation frames the fix as account hygiene, not just network rules. Its user management best practices say: “n8n recommends that owners create a member-level account for themselves,” because owners can see all workflows but there is no way to see who created a particular workflow. The same docs note that webhook paths must be unique across the entire instance, and that n8n generates a long random value for the webhook path by default. Read the full guidance in the n8n security documentation, and check the variables that control exposure in the n8n environment variables reference.

Prerequisites

• SSH access to the server running n8n, or access to its Docker host.
• A second network to test from, such as a phone on mobile data or a different Wi-Fi network. Testing from the same network as the server proves nothing, because local traffic often bypasses the firewall.
• Your server’s public IP address or domain name, and the n8n version you run. Find the version in the editor under Settings, or run n8n --version inside the container.
• A free Shodan or Censys account, only if you want to check the scanner databases. Both offer free searches with an account.

Step-by-step guide

Step 1: See what your server actually listens on

Log in to the server and list listening ports. This is the ground truth, because it shows what n8n bound to, regardless of what you intended.

ss -tlnp | grep 5678

Read the local address column. 127.0.0.1:5678 means n8n listens on localhost only, which is what you want behind a reverse proxy. 0.0.0.0:5678 means it listens on every interface, including the public one, which is exposure. If you run Docker, check the port mapping too, because Docker can publish a port even when n8n itself binds to localhost inside the container.

docker ps --format '{{.Names}} {{.Ports}}'

A mapping like 0.0.0.0:5678->5678/tcp publishes the editor to the world. A mapping like 127.0.0.1:5678->5678/tcp keeps it local. This is the most common cause of accidental exposure, and it survives restarts because it lives in the compose file or run command.

Step 2: Check the firewall rules, not just the port

A listening port is only reachable if the firewall lets traffic through, so verify the firewall state on the server.

sudo ufw status verbose

Look for a rule that allows 5678. On a correctly set up instance, only ports 22, 80, and 443 are open, and 5678 is absent or explicitly denied. If you use a cloud provider, check the provider firewall or security group separately, because it sits in front of the server firewall and can expose the port even when ufw on the server denies it.

Step 3: Test reachability from another network

Now test from outside. Disconnect from the server network, switch your phone to mobile data, and run the test from there, or use a machine on a different network:

curl -s -o /dev/null -w "%{http_code}\n" --max-time 10 http://YOUR-SERVER-IP:5678/

A 200 means the editor answers on the public internet, and your instance is exposed. A timeout or 000 means the connection never arrived, which is the result you want. Also test the HTTPS domain, because a reverse proxy can expose the editor on port 443 even when 5678 is closed:

curl -s -o /dev/null -w "%{http_code}\n" --max-time 10 https://n8n.yourdomain.com/

A 200 here is expected if you serve n8n through a proxy. What matters is the next step: whether the page demands a login.

Step 4: Test what an anonymous visitor actually sees

Reachability alone is not the full story. Fetch the editor page without logging in and look at what comes back.

curl -s http://YOUR-SERVER-IP:5678/ | head -c 500

If the response contains a sign-in form or redirects to a login page, the editor is behind authentication, which is the minimum bar. If it loads workflow data, the editor UI, or an owner setup screen, anyone on the internet gets the same. An owner setup screen is the worst case: no account exists yet, and the first visitor can create the owner account and take over the instance. Create the owner account before the hostname is public, and turn on two-factor authentication, as n8n’s docs recommend.

Also test one webhook URL the same way, with a harmless POST, to confirm what a stranger can trigger:

curl -s -o /dev/null -w "%{http_code}\n" -X POST https://n8n.yourdomain.com/webhook-test/your-path

A 200 or 404 tells you the webhook endpoint is live, which is normal. The point of this test is to know which endpoints exist, not to panic about webhooks being reachable.

Step 5: Search the scanner databases for your own host

Shodan and Censys scan the whole internet continuously, so they already know whether your instance answers publicly. With a free account, search for your public IP on either service and look for an n8n page title or banner.

If your host appears with an n8n banner, it is indexed and findable by anyone running the same search, including attackers who automate exactly this query. If it does not appear, that is a good sign but not proof, because scanners may not have visited since your last change.

Step 6: Check your version against known critical flaws

Exposure matters more when the version behind it is vulnerable. Check the running version in the editor, under Settings, or from the command line:

docker exec n8n n8n --version

Compare it with the CVE-2025-68613 range: versions 0.211.0 through 1.120.3 are affected, and the fix landed in 1.120.4, 1.121.1, and 1.122.0. If your version falls in the affected range, patching is urgent. If you run an older 1.x version, check the n8n security advisories on GitHub, because several critical flaws were patched across 2025 and 2026, and scanners fingerprint versions precisely for this reason. Our n8n update guide walks through a safe upgrade with a backup first.

Step 7: Close the gap if you are exposed

If any test above shows exposure, fix it in this order. First, stop publishing the editor port. In your Docker Compose file, change the port mapping to bind localhost only:

ports:
  - "127.0.0.1:5678:5678"

Then restart the container and repeat Step 1 to confirm the mapping changed. Second, deny the port at the firewall:

sudo ufw deny 5678/tcp
sudo ufw reload

Third, serve n8n only through a reverse proxy on ports 80 and 443 with HTTPS, and set the webhook URL explicitly so n8n generates correct links:

N8N_WEBHOOK_URL=https://n8n.yourdomain.com/
N8N_HOST=n8n.yourdomain.com
N8N_PROTOCOL=https

Note that N8N_WEBHOOK_URL replaced WEBHOOK_URL in n8n 2.35.0, and the older variable still works as a deprecated alias. Fourth, confirm the owner account exists and two-factor authentication is on, then re-run Steps 3 and 4 from the outside network to prove the fix.

Troubleshooting

The port test fails from outside, but Censys still lists my instance

Scanner data is historical. Censys and Shodan keep the last snapshot they captured, and a listing can stay visible for weeks after you close the port. Check the scan date on the listing. If the live curl test from another network times out and the listing predates your fix, the instance is closed and the listing is stale. Do not reopen anything to “fix” a stale listing.

The editor loads, but login fails with a cookie error over HTTP

n8n uses secure cookies by default, which browsers only send over HTTPS. Accessing the editor over plain HTTP can show the login page and then refuse to sign you in. This is expected behavior, not a bug, and it is a sign you should be using HTTPS anyway. Put n8n behind a reverse proxy with a valid certificate and access it over HTTPS. Only set N8N_SECURE_COOKIE=false for a local-only test, and never for a public instance.

n8n answers on IPv6 while IPv4 looks closed

A firewall rule that blocks port 5678 on IPv4 does nothing for IPv6 if the server has a public IPv6 address and n8n listens on it. Run ss -tlnp again and look for a :::5678 line, which means the port listens on all IPv6 interfaces. Add matching IPv6 firewall rules, or bind n8n to localhost on both stacks, and test the IPv6 address from another network the same way you tested IPv4, because scanners check both.

I patched n8n, but Shodan still shows the old version

Version banners are snapshots too. Shodan records the version string it saw on its last scan, and it does not re-scan immediately after you upgrade. Confirm the live version with docker exec n8n n8n --version on your own server, which is the only number that matters for your security. The public listing will update on the scanner’s next pass, usually within days to weeks.

My reverse proxy returns 200, but the editor shows a blank page

A blank editor behind a proxy usually means the proxy is not passing the headers n8n needs, or the webhook and host variables point at the wrong address. Check that the proxy forwards X-Forwarded-For, X-Forwarded-Host, and X-Forwarded-Proto, and that N8N_HOST and N8N_WEBHOOK_URL match the public domain exactly, including the trailing slash on the webhook URL. Restart the container and hard-refresh the editor after changing variables.

FAQ

Is it legal to search for my own n8n instance on Shodan or Censys?

Yes, searching for a host you own is legitimate. Both services scan the public internet continuously and sell the results, so checking what they already recorded about your own IP is no different from checking your own listing in a phone book. Do not scan or probe hosts you do not own.

Port 5678 is closed from the outside. Am I safe?

Mostly, but not completely. A closed 5678 means the editor is not directly reachable on that port, but check the rest too: webhooks are public by design, a reverse proxy can leak the editor on 443, and IPv6 can expose a service that IPv4 firewall rules never covered. Run the full check below, not just the port test.

My webhooks have to be public. Does that mean my instance is exposed?

No, public webhooks are normal and expected. A webhook URL is a single public endpoint that triggers one workflow. Exposure means the editor, the settings pages, or the API are reachable, because those hand over credentials and workflow control. A public webhook plus a locked editor is the intended setup.

How often should I re-check exposure?

Check after every change to the server, the firewall, the reverse proxy, or the n8n container, and re-check on a schedule, at least monthly. Exposure usually appears after an innocent change, such as a rebuilt container that publishes port 5678 again, not during the original install.

Do n8n Cloud users need this check?

No. n8n hosts and patches Cloud instances, and the editor is behind n8n’s own authentication. This guide is for self-hosted instances on your own server, VPS, or home lab, where you own the firewall and the port mapping.

Censys still lists my instance weeks after I closed the port. Is it still exposed?

Probably not. Scanner databases keep historical snapshots, so a listing can outlive the exposure by weeks. Confirm with a live test from another network, and check the scan date on the listing. If the live test fails to connect and the listing date predates your fix, the listing is stale history, not a live hole.

Conclusion

Checking exposure takes ten minutes and three tools you already have: ss on the server, curl from another network, and a free scanner search. The numbers make it worth doing: Censys found 113,926 exposed n8n hosts, and three in four of those with a readable version ran software with a known critical flaw. If your check comes back clean, put a monthly reminder on it, because exposure usually returns through a rebuilt container, not a new attack. If it comes back exposed, bind the port to localhost, close it at the firewall, and serve n8n through HTTPS only, then verify from the outside again. Next, read our complete n8n guide for the full self-hosting setup, harden further with our self-hosted n8n security hardening guide, and keep your instance patched with our n8n update guide.

Frequently asked questions