# Your n8n Token Is a Master Key — and Someone Just Found It in a Public Repo
Researchers have found live n8n API tokens exposed in public repositories and configuration files, giving anyone who found them programmatic access to running workflow automation instances — and everything those workflows connect to.
That last part is the thing that matters.
---
## Automation Tools Are Credential Aggregators, Not Just Apps
n8n has become the self-hosted darling of technical teams who want Zapier-level automation without the Zapier price tag. Engineering teams run it internally to wire together Slack with Jira, push database exports to S3, sync CRMs with billing systems, and a hundred other things. Each of those connections stores credentials. OAuth tokens, API keys, database passwords, webhook secrets — all of it lives in the n8n credential vault, accessible via the platform's API.
So when an API token leaks, attackers aren't just getting into n8n. They're getting the keys to every service that team has ever automated. The token is the front door; the credential vault is the armory.
This isn't a theoretical blast radius. An attacker with a valid n8n API token can:
One token. Every connection. That's the exposure.
---
## How These Tokens Get Loose
The pattern is familiar. Developers spin up a self-hosted n8n instance, generate an API token for programmatic workflow management or CI integration, and that token ends up somewhere it shouldn't — a .env file committed to a repo, a docker-compose config pushed to GitHub, a hardcoded value in a deployment script.
What makes n8n specifically dangerous in this scenario is the deployment profile of its typical user. This isn't a Fortune 500 company with a secrets management pipeline and a security team scanning every commit. This is a 10-person startup, a solo developer, or an internal ops team that deployed n8n on a DigitalOcean droplet at 11pm because they needed to automate something by morning. Security hygiene in those conditions is variable, to put it generously.
The n8n documentation covers API authentication, but the gap between "documented correctly" and "implemented correctly in every deployment" is where most incidents live.
---
## The Infrastructure Map Problem
Here's a detail that tends to get lost in breach coverage: even if an attacker can't immediately extract credentials in plaintext, the workflow configurations themselves are intelligence.
A company's n8n instance is essentially a diagram of their internal architecture, written in JSON. You can see which Postgres databases exist, what their connection strings look like, which third-party APIs they use, how data flows between systems, and where sensitive operations happen. For a threat actor doing reconnaissance ahead of a more targeted attack, that's extraordinarily useful — even before a single credential is touched.
This mirrors the risk profile of CI/CD system breaches. When CircleCI disclosed a credential-scraping incident in early 2023, the severity wasn't just "some tokens leaked." It was that CircleCI had visibility into thousands of customers' secrets, pipeline configurations, and internal infrastructure. Automation and pipeline tools are attractive targets precisely because they're designed to touch everything.
---
## What Defenders Should Do Right Now
If your organization runs n8n, the remediation checklist is short but non-negotiable:
n8n in env files and Docker configs, or use a tool like TruffleHog against your git historyIf you're running n8n on a cloud VPS with the API accessible from 0.0.0.0:5678, you have a bigger problem than just the token.
---
## HackWire Analysis
The n8n exposure fits a pattern we've been watching accelerate for the past two years: automation infrastructure as a supply chain attack surface. As teams have shifted toward low-code and no-code workflow tooling, they've concentrated enormous credential density into single systems that were often deployed by developers, not security engineers — and thus inherited a developer's operational posture rather than a security team's.
The critical thing mainstream coverage is missing here is the asymmetric intelligence problem. A compromised n8n token doesn't just let an attacker steal credentials. It lets them *understand your organization* in ways that most breaches don't. They can read your workflows and infer which databases matter, which third-party SaaS you depend on, and where the highest-value data movements happen. That's pre-attack intelligence, not just opportunistic access.
This also intersects with the self-hosted boom. The same teams running n8n for "privacy" reasons — to avoid putting data through Zapier or Make's cloud — often skip the operational security discipline that cloud platforms enforce by default (token rotation policies, audit logs, access controls). Privacy through self-hosting is a valid choice. But it shifts the security burden entirely to the deployer, and a lot of teams don't fully reckon with that.
Watch for this pattern to intensify as more teams adopt tools like n8n, Windmill, and Activepieces. The attack surface isn't the tools themselves — it's the accumulated credential mass they represent, sitting behind whatever authentication their deployer chose to configure.
— HackWire Editorial
---
## Related Coverage