GitGuardian researchers discovered 321 live n8n automation platform instances that accepted API tokens leaked on GitHub. No software exploit was needed. The tokens were valid, publicly committed to repositories, and granted full access to workflow definitions and stored credentials.
This wasn't a vulnerability in n8n's code. It was a widespread credential management failure.
What Happened
GitGuardian's team scanned GitHub for exposed n8n API tokens and tested them against reachable instances. Out of 896 instances they could reach, 321 accepted the leaked tokens, granting unauthorized access. The researchers could view workflow definitions, access stored credentials, and potentially pivot to connected services.
n8n has over 100,000 instances visible through Shodan, suggesting the actual exposure could be much larger than what GitGuardian tested.
Timeline
The research didn't document a single incident with a clear timeline. Instead, it revealed an ongoing exposure pattern:
- Ongoing: Developers commit n8n API tokens to public GitHub repositories.
- Ongoing: These tokens remain valid indefinitely (before version 1.78.0).
- Research window: GitGuardian identified 896 reachable instances and tested them.
- Result: 321 instances (35.8%) accepted the leaked tokens.
- December 2024: n8n released version 1.78.0 with 30-day default token expiration.
The lack of a specific incident timeline is itself telling. This isn't about one breach on one day. It's about continuous, undetected exposure.
Which Controls Failed
Credential lifecycle management. Before version 1.78.0, n8n API tokens had no default expiration. Once created, they worked forever unless manually revoked. Your team might create a token for testing, commit it accidentally, and it's valid until someone notices and takes action.
Secret scanning. Organizations running these 321 instances weren't monitoring GitHub for their own credentials. If you don't know your API token is public, you can't revoke it.
Least privilege access. n8n API tokens granted broad access to workflow definitions and stored credentials. There was no way to scope a token to specific workflows or limit what it could read.
Audit logging and alerting. The instances that accepted these tokens likely had no alerts configured for API access from unexpected IP addresses or geographic locations. Unauthorized access went unnoticed.
What the Standards Require
PCI DSS v4.0.1 Requirement 8.3.9 states: "If passwords/passphrases are used as authentication factors to meet Requirement 8.3.1, they are changed at least once every 90 days." While this specifically addresses passwords, the principle extends to any authentication credential. API tokens are authentication factors. They need rotation policies.
NIST 800-53 Rev 5 IA-5(1) requires organizations to "enforce minimum password complexity" and "enforce password minimum and maximum lifetime restrictions." Again, the control family applies to API tokens. You need defined lifetimes.
ISO/IEC 27001:2022 Annex A.9.3.1 (management of privileged access rights) requires that "the allocation and use of privileged access rights shall be restricted and controlled." An API token with full workflow access is a privileged credential. It needs the same controls you'd apply to admin accounts: expiration, monitoring, and least privilege.
SOC 2 Type II CC6.1 (logical and physical access controls) requires entities to "implement logical access security measures to protect against threats from sources outside its system boundaries." If you're running n8n and claiming SOC 2 compliance, you need to demonstrate that your API tokens can't be used by unauthorized parties, even if leaked.
Lessons and Action Items
Implement token expiration immediately. If you're running n8n, upgrade to version 1.78.0 or later to get the 30-day default expiration. If you're running any automation platform or internal tool that issues API tokens, enforce expiration policies. 30 days is reasonable for production tokens. 7 days for development and testing.
Scan GitHub for your credentials. GitGuardian offers a free tier. So does GitHub's secret scanning for public repositories. Set up automated scanning for your organization's tokens, API keys, and credentials. Don't wait for a researcher to tell you your secrets are public.
Scope your tokens. If your platform supports it, create tokens with the minimum necessary permissions. A token for a CI/CD pipeline shouldn't have access to view all workflows and credentials. It should only be able to trigger specific workflows.
Log and alert on API token usage. Configure your automation platform to log API authentication attempts. Alert on:
- API access from new IP addresses
- API access outside your organization's geographic regions
- High-volume API calls that deviate from baseline
- API tokens that haven't been used in 90+ days (these are orphaned and should be revoked)
Treat API tokens like production credentials. Your developers know not to commit database passwords to GitHub. They need to treat API tokens the same way. Add pre-commit hooks that reject commits containing tokens. Use environment variables or secret management systems like HashiCorp Vault or AWS Secrets Manager.
Audit your current tokens. Right now, log into your n8n instance (or any automation platform you're running) and list all active API tokens. For each one:
- Who created it?
- When was it last used?
- What does it have access to?
- Does it need to exist?
Revoke anything you can't answer those questions about.
The 321 instances that accepted leaked tokens didn't fail because of a zero-day exploit or sophisticated attack. They failed because API tokens were treated as configuration details instead of credentials. Your team can fix this today.
