n8n: leaked API tokens still opened 321 live instances

Taking over an automation platform does not always require a CVE. GitGuardian identified 4,576 unique n8n API tokens associated with 1,255 hostnames in public GitHub history. Of the 896 instances reachable during testing, 321 still accepted at least one disclosed token.

An automation identity often has a larger reach than an individual employee account. n8n connects CRM systems, databases, email, cloud services and AI providers. A valid token may do more than open a console: it can allow an attacker to create or run workflows that use credentials already stored by the platform.

Where the tokens came from

Researchers found conventional .env files, scripts and sample configurations, but also a newer route: AI-tool permission files. When a developer approves a curl command containing an n8n URL and key, the complete command can land in .claude/settings.json or an equivalent file. These files do not always receive the .gitignore treatment reserved for recognised secret files.

Some older n8n keys had no expiry field. A token committed months ago could therefore remain valid unless an administrator explicitly deleted it from the instance. Removing the value from the current branch is insufficient because it remains in Git history and forks.

GitGuardian’s research demonstrated four classes of action through the documented API: user and workflow enumeration, execution-data access, use of stored credentials, and secret exfiltration through an attacker-controlled HTTP node. Encryption at rest does not protect the credential store from an authorised workflow because the platform must decrypt a key before using it.

Why a fully patched server is not enough

This is not memory corruption or an authorisation bypass. The server receives a correctly signed token and performs permitted operations. A WAF and vulnerability scanner may see nothing abnormal. The valuable detection fields are token identity, source address, workflow creation and activation, changes to credential bindings and new HTTP destinations.

n8n’s built-in audit endpoint can identify dangerous nodes, open webhooks and weak configuration. It is a remediation tool for the owner, but for somebody holding a leaked privileged token it can also become a prioritised map of the next attack stage.

Response plan

1. Scan complete repository history, gists, issues and CI logs for N8N_API_KEY, instance addresses and complete HTTP commands.
2. Revoke discovered keys in n8n; merely creating a replacement does not remove the old token’s rights.
3. Review API logs from the first public commit and look for workflow changes, new executions and unfamiliar source addresses.
4. Determine which credentials, data tables and downstream systems the compromised principal could reach, then rotate those secrets too.
5. Disable the public API when it is unnecessary, or constrain it with VPN access, mTLS and address allowlists.
6. Require short expiry, one token per process and a minimum permission scope.
7. Add pre-commit secret scanning and include AI-agent configuration files in the policy.

Designing automation tokens safely

The strongest model does not use one instance-owner key for every integration. Each workflow should receive a separate identity, scope limited to required operations and a short lifetime. Where a downstream service supports OIDC or workload identity, n8n can exchange an attested identity for temporary credentials instead of storing a long-lived secret. This also makes each request attributable to one process.

Detection has to recognise valid API syntax. Useful signals include a token’s first use from a new ASN, creation of an HTTP node targeting a new domain, bulk reads of execution history or a workflow run outside its usual window. Logs should bind the token to its owner, workflow, scope, source address and configuration change. An alert based only on failed authentication will never see an attacker who holds a valid key.

Facts and conclusions

The figures 4,576, 1,255, 896 and 321 are a point-in-time research result, not a live count of every exposed deployment. A valid token confirms access but does not prove criminal use.

Breachroad’s conclusion is to govern an automation token as a privileged machine identity. Training for IT and development teams helps close new leak locations, while a cloud security assessment can trace the actual reach of integrations and downstream secrets.