Leaked n8n API Tokens: Validating the Risk of Automated Workflows
Just caught the latest report from GitGuardian regarding exposed n8n API tokens. It’s a textbook example of how supply chain security often fails at the developer hygiene level rather than through complex software exploits. They managed to identify 4,576 unique credentials in public GitHub commits, with a concerning number of those—over 300 instances—still active and accepting requests.
The real danger here isn't just accessing the n8n dashboard; it's the potential for downstream credential theft. Since n8n is often used to glue together SaaS apps, databases, and internal tools, a single leaked API key can be a skeleton key for the entire infrastructure. Attackers can list workflows, view credentials stored in the credential store, and pivot to other systems without triggering a traditional vulnerability alert.
If you're running n8n, especially in a SaaS context, you should be hunting for public exposure immediately. I tossed together a quick KQL query to identify potential n8n traffic in our proxy logs, looking for unauthorized webhook calls or dashboard access:
NetworkEvent
| where Url contains "n8n" or RemotePort == 5678
| project Timestamp, SrcIp, DstIp, Url, StatusCode
| where StatusCode in (200, 401, 403)
| summarize count() by SrcIp, Url
Beyond detection, how is everyone handling secret management for low-code automation tools? Are you relying on environment variables and pre-commit hooks, or have you managed to integrate proper external secret managers (like HashiCorp Vault or AWS Secrets Manager) into your n8n workflows?
This is exactly why we enforce pre-commit hooks across all our repos. A simple truffleHog scan can catch 90% of these accidental commits before they ever hit the remote.
trufflehog --regex --entropy=False /path/to/repo
However, the hardest part is fixing the existing leaks. Once a key is on GitHub, you have to assume it's compromised. For anyone using n8n, I'd recommend generating an 'Audit' report immediately to see which workflows actually utilize API keys and rotating them. Don't just revoke the key; check the workflow execution logs to see if that key was used recently by an unknown IP.
From a pentester's perspective, finding a tool like n8n exposed is like hitting the jackpot. It's not just the data inside n8n; it's the connections it holds. I've seen instances where the n8n service account had read/write access to S3 buckets containing sensitive customer backups because 'it was easier for the workflow.'
If you can't isolate the automation server in a private subnet, at least use distinct, least-privilege service accounts for every workflow. Never use the main admin API key for webhooks. And definitely disable the 'Editor' and 'Owner' API access on public endpoints if you can help it.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access