n8n API Token Leak Exposes Hundreds of Automation Servers

GitGuardian discovered thousands of exposed n8n API tokens in public GitHub commits, allowing access to hundreds of live automation servers without exploiting a single software vulnerability.

n8n API token leak

Your automation platform was supposed to save time. It connects your databases to your CRM. It triggers AI agents when customers complain. It moves data between your cloud provider and your source code repository while you sleep.

Here’s the problem. Those API tokens that power this magic? Thousands of them are sitting in public GitHub commits right now. And attackers have figured out exactly how to turn your productivity tool into their perfect backdoor.

The Numbers Are Staggering

GitGuardian researchers didn’t just find a few leaked credentials. They discovered 4,576 unique n8n API tokens exposed across 5,469 public GitHub commits. These weren’t random strings. They mapped back to 1,255 unique hostnames running live automation instances.

When researchers tested accessibility, 896 n8n instances were publicly reachable. Of those, 321 accepted at least one leaked token. That’s 36% of reachable instances. Roughly 26% of all identified hostnames were essentially wide open.

Think about what n8n actually is for a moment. It’s an open-source, low-code workflow automation platform with AI agent support and hundreds of built-in integrations. Its repository has attracted nearly 200,000 GitHub stars. Organizations use it to connect databases, source code repositories, cloud environments, artificial intelligence services, customer support platforms, and internal systems.

This isn’t a forgotten side project. More than 100,000 n8n instances are visible through Shodan. And the security situation is deteriorating fast. Over 50 security advisories have been published since January 2026. As of March 31, 2026, GitGuardian found that 58% of scanned instances were running a version affected by at least one known security advisory.

The Perfect Storm

The vulnerabilities aren’t theoretical. CVE-2025-68613, an expression injection vulnerability scoring 9.9 on the CVSS scale, was added to the U.S. CISA Known Exploited Vulnerabilities catalog on March 11, 2026. This is actively exploited code.

But here’s what makes this exposure particularly dangerous. n8n API keys are signed JSON Web Tokens. Many older tokens contain no expiration claim. They remain valid until manually revoked. n8n only introduced a 30-day default expiration in version 1.78.0 in February 2025. Most exposed tokens were generated before this safeguard existed.

Researchers also identified 372 n8n Model Context Protocol API keys in the same commit set. Seven were still valid at the time of testing. That’s only 2%, but in security, one key is all it takes.

The attacker’s job is disturbingly easy. The instance URL is often committed alongside the token in .env files or Claude Code permission files. Attackers don’t need separate infrastructure discovery tools. You handed them the address and the keys.

Four Ways In

GitGuardian demonstrated four attack techniques in a controlled n8n environment. They used only documented REST API functionality and standard HTTP requests. No CVE exploitation was required.

First, attackers can enumerate users, workflow definitions, and security configurations through read-only API endpoints. They map your entire infrastructure without triggering a single alert.

Second, they create a workflow that references a stored credential, such as an OpenAI API key. They retrieve the execution output to use the credential without ever seeing its direct value. The automation reveals the secrets while appearing to function normally.

Third, they create a workflow with a Data Table node, retrieve all rows, then capture the execution record to exfiltrate table contents. Your customer database becomes their reconnaissance target.

Fourth, and most insidious, they configure an HTTP Request node to use a stored credential as its authentication method while pointing it at an attacker-controlled URL. This causes n8n to transmit the raw credential value in the outgoing Authorization header. The platform literally hands over your secrets.

Attackers can delete these malicious workflows after execution. This also removes associated execution records from the interface. Defenders are left with limited evidence that anything happened at all.

During the research, GitGuardian found a real-world n8n workflow that automatically backed up its own definitions to a public GitHub repository. An SSH deployment key was hard-coded directly into one of its nodes. The exposure was recursive and self-documenting.

The Real-World Response

GitGuardian attempted responsible disclosure with seven organizations, including three hosting providers and four individual companies. One company with a bug bounty program acknowledged the report, paid a $1,200 bounty, and revoked the credential. Most others did not respond.

n8n acknowledged GitGuardian’s reports. They stated they were aware of the issues and planned to address them. But at the time of publication, GitGuardian had not independently confirmed that related fixes had been released.

Approximately 30% of the 321 affected instances were hosted on n8n.cloud or similar managed services. Even managed infrastructure isn’t immune to credential sprawl.

A leaked n8n token is never an isolated credential exposure. Automation platforms sit at the center of an organization’s integrations. A single token provides paths toward source control, databases, cloud services, AI APIs, support platforms, and customer data. You didn’t just leak one password. You potentially leaked access to your entire operational infrastructure.

What You Must Do Now

If you use n8n, you need to act immediately. Revoke any exposed n8n token. Determine which workflows and downstream credentials the account could access. Review your instance for unauthorized changes. Rotate connected credentials where exposure cannot be ruled out.

Your automation platform should work for you, not for whoever finds your API key first. Check your commits. Check your environment files. Before someone else does it for you.

Leave a Comment