The Discovery
In January 2026, a systematic Shodan scan targeting common automation platform ports revealed something that should concern every organization running AI agent workflows: over 42,000 publicly accessible automation instances sitting on the open internet without any form of authentication.
These are not obscure services running on forgotten VMs. They are production workflow engines -- the same platforms that businesses rely on to process payments, sync customer data, send emails, and orchestrate multi-step AI agent pipelines. And they are wide open.
The breakdown tells a story about how the industry builds automation: n8n leads the count because it is self-hosted and often deployed with default Docker configurations that expose port 5678 to all interfaces. Webhook endpoints from Zapier and Make scenarios come next -- these are functional URLs that accept and process data from anyone who knows the address. Custom orchestrators built on LangChain, CrewAI, and similar frameworks round out the count, often running Flask or FastAPI servers with no auth middleware at all.
This is not a collection of isolated incidents. It is a systemic failure in how the automation industry approaches deployment security.
Why This Matters
The instinct is to dismiss these as dashboards -- read-only views that expose some configuration data but nothing actionable. That instinct is wrong. These are full execution environments. Every exposed instance is a live control panel for business-critical workflows.
An exposed n8n instance, for example, gives an attacker immediate ability to:
- Read all workflow configurations including hardcoded API keys, database connection strings, OAuth tokens, and webhook secrets stored in credential nodes
- Modify existing workflows to intercept data in transit, inject malicious processing steps, or redirect outputs to attacker-controlled endpoints
- Execute arbitrary code through Code nodes and Function nodes that provide full Node.js runtime access on the server
- Pivot into the internal network by using the instance's network position to scan and access services that are not directly exposed to the internet
Analysis of a randomized sample of 500 exposed instances found that the average exposed instance contained credentials for 4.7 connected services -- meaning a single exposed workflow engine typically provides access to nearly five additional systems. Stripe keys, SendGrid API tokens, PostgreSQL connection strings, AWS IAM credentials, and Slack bot tokens were the most commonly found credential types.
An exposed workflow engine is not a single vulnerability -- it is a credential store, a code execution environment, and a network pivot point rolled into one. Compromising one instance typically grants access to 4-5 additional services through stored credentials.
Three Attack Scenarios
To understand the real-world impact, consider three attack patterns that we have observed being used against exposed automation instances.
Credential Harvesting
An attacker discovers an exposed n8n instance on port 5678 via Shodan. They navigate to the workflow editor, which loads without any login prompt. Within seconds, they can see every workflow on the instance. They export the workflow JSON files, which contain the full configuration of every node -- including credential references. By navigating to the Credentials section (also unauthenticated), they extract hardcoded API keys for Stripe, SendGrid, a PostgreSQL database, and an AWS account with S3 and SES permissions. Total time from discovery to full credential extraction: 3 minutes. The attacker never needs to write a single line of exploit code.
Workflow Manipulation
An attacker finds a workflow engine powering an e-commerce company's payment processing pipeline. Rather than stealing credentials outright, they take a subtler approach. They add a single webhook node to an existing payment workflow -- configured to silently POST a copy of every transaction payload (including customer names, email addresses, and payment amounts) to an external server. The modification is buried inside a sub-workflow that the workflow owner rarely inspects. The malicious node processes data alongside the legitimate workflow for weeks before anyone notices the additional HTTP request in the execution logs.
Lateral Movement
An attacker uses a Code node on the exposed instance to run network reconnaissance. Because the workflow engine runs inside the organization's infrastructure -- often on the same Docker network or VPC as production databases and internal APIs -- the attacker can scan internal IP ranges that are invisible from the public internet. They discover an unpatched PostgreSQL instance on an internal subnet, connect using credentials found in the workflow engine's credential store, and exfiltrate customer records. The workflow engine, intended as a productivity tool, becomes the beachhead for a full infrastructure compromise.
The Root Cause
The question is not whether these platforms have security features -- most of them do. n8n supports basic authentication, OAuth, and LDAP. Make and Zapier enforce authentication on their cloud offerings by default. The question is why 42,000 instances ended up on the internet without those features enabled.
The answer comes down to four converging failures:
- Docker default configurations expose all ports. The standard
docker-compose.ymlfor most self-hosted platforms maps internal ports to0.0.0.0, meaning every network interface on the host. Developers who deploy on cloud VMs with public IPs are unknowingly exposing their instances to the entire internet - Quick development setups never get secured. Engineers spin up workflow instances for prototyping with authentication disabled. The prototype works, becomes production, and nobody goes back to enable auth. The "temporary" deployment becomes permanent
- No built-in auth on many orchestrators. Custom AI agent frameworks built on LangChain, CrewAI, or AutoGen often expose API endpoints via Flask or FastAPI with zero authentication middleware. The developer assumes "this is an internal tool" and skips auth entirely
- "Internal tool" mindset on public infrastructure. Developers treat self-hosted tools as inherently private, even when they are running on cloud VMs with public IP addresses. The mental model of "my laptop" does not translate to "an EC2 instance with a public IP"
Analysis of the exposed instances' hosting metadata revealed that 73% were running on major cloud providers -- AWS (34%), Google Cloud (22%), and Azure (17%). These are not forgotten servers in a closet. They are actively managed cloud deployments that simply lack the authentication step.
How to Check If You're Exposed
Before assuming you are not one of the 42,000, run through this checklist. It takes less than 10 minutes and could save you from a breach that takes months to recover from.
- Run
nmap -p 5678,443,80 your-server-ipfrom an external machine to check whether n8n's default port is accessible from outside your network - Search Shodan for your organization's IP ranges using
org:"Your Company"or your ASN to see what services are visible to the internet - Audit every
docker-compose.ymlin your infrastructure for port mappings like"5678:5678"without corresponding firewall rules restricting source IPs - Verify that your reverse proxy (Nginx, Caddy, Traefik) requires authentication before forwarding requests to automation services
- Enable n8n's built-in authentication by setting
N8N_BASIC_AUTH_ACTIVE=truealong withN8N_BASIC_AUTH_USERandN8N_BASIC_AUTH_PASSWORDenvironment variables - Replace public port exposure with VPN or Tailscale access so that automation tools are only reachable from your private network
# Quick check: is your n8n exposed?
nmap -p 5678 your-server-ip
# Search Shodan for your org's exposure
shodan search "n8n" --fields ip_str,port,org
# Audit Docker compose for exposed ports
grep -rn "5678:5678" /path/to/docker-compose*.yml
# Enable n8n basic auth (add to .env)
N8N_BASIC_AUTH_ACTIVE=true
N8N_BASIC_AUTH_USER=admin
N8N_BASIC_AUTH_PASSWORD=your-strong-password
# Better: use Tailscale instead of public ports
tailscale up --accept-routes
What We Teach in the Workshop
This article covers what is happening and why. In our 2-day AI Security Workshop, we go further. Module 2 is dedicated to agent infrastructure hardening -- you will actually scan for exposed services in your own environment, configure authentication and network isolation, and set up continuous monitoring to catch configuration drift before it becomes a breach.
Participants walk away with a hardened deployment template, a security audit checklist customized to their stack, and hands-on experience fixing the exact misconfigurations described in this article.
Secure Your AI Agent Infrastructure
Join our 2-day hands-on workshop and learn how to find, fix, and prevent exposed automation workflows in your environment.
Register for Workshop