Leaked n8n API Tokens Exposed 321 Live Instances

GitGuardian found 321 reachable n8n instances still accepting API tokens exposed in public GitHub commits. The accepted keys could reveal workflows, executions, variables, data tables, and information about stored credentials. This was not a software exploit: a valid leaked key was enough to cross the API boundary.

The researchers identified 4,576 unique n8n API tokens across 5,469 commits and associated them with 1,255 hostnames. Of 896 instances that were reachable during validation, 321 accepted at least one exposed token. Operators should revoke a leaked n8n key immediately, but they also need to determine what the key could reach and rotate any connected secret that may have been used through a workflow.

What the n8n token study found

The 321 figure describes keys that validated when the research was performed; it does not prove that all 321 instances were maliciously accessed. It does show that deleting a secret from the current branch or making a repository private does not invalidate a token copied from Git history.

Why revoking the n8n token is only step one

An accepted API key can expose more than an instance name. The documented API surface includes users, workflow definitions and execution data. Depending on permissions and configuration, a workflow can also reveal data tables, variables, credential names and credential types. The research team’s controlled tests went further: an actor who can create or alter a workflow may be able to make n8n use a stored credential without first displaying its value.

That distinction matters. A secret can be abused through an automation even when its plaintext never appears in the API response. An unauthorized workflow could send an authenticated request to an external system, read business data, or forward data elsewhere. One exposed workflow in the dataset even contained a hardcoded SSH deployment key and copied itself to a public repository.

Revocation closes the leaked n8n API session, but it cannot undo an earlier workflow change or invalidate downstream OAuth grants, cloud keys, database passwords, webhook secrets, or deploy keys. The same response principle applies after a developer-token theft in the Keyv npm incident: first contain the active mechanism, then rotate credentials and inspect repository or workflow changes.

Where the leaked keys remained exposed

GitGuardian traced tokens to public commits, including environment files and AI-assistant configuration such as .claude/settings.json. Removing the line in a later commit does not erase earlier Git objects, forks, clones, caches, or automated secret indexes. Treat every committed production token as compromised even when the repository’s current view looks clean.

Older n8n API keys may also remain valid for a long time. The research notes that the 30-day default expiry arrived in n8n 1.78.0 in February 2025, while keys created under earlier behavior may have no expiration claim. An expiration policy reduces future exposure, but it does not replace revocation of a known leak.

Four evidence states responders should separate

1. Token present in a repository. The secret is public or was public, but the related instance may be gone or inaccessible.
2. Token still validates. The key reaches a live instance and must be revoked, but validation alone is not proof of malicious use.
3. Unauthorized access is visible. Logs show unknown API calls, account access, workflow reads, or execution retrieval.
4. Workflow or downstream abuse occurred. An attacker created or modified automation, ran a credential-backed action, exported data, or used a connected secret outside n8n.

Record the highest state supported by evidence. Calling every repository exposure a confirmed breach overstates the facts; stopping at “the key was revoked” can understate the operational damage.

Incident response checklist for an exposed n8n key

1. Preserve evidence before cleanup. Save repository history, n8n audit output, reverse-proxy and application logs, execution history, user lists, and current workflow metadata.
2. Revoke every exposed n8n API or MCP token. Do not wait for a repository-history rewrite. Remove stale keys and confirm that the old values no longer authenticate.
3. Search the full Git history. Check all branches, tags, pull-request refs, forks, build artifacts, backups, and developer clones—not only the default branch.
4. Audit the instance as an owner. Run the official n8n security audit and review users, active and disabled workflows, executions, variables, data tables, community nodes, and instance settings.
5. Compare workflow changes. Look for unfamiliar HTTP Request nodes, new webhooks, changed destinations, disabled validation, new schedules, or exports to external endpoints.
6. Map credentials reachable through affected workflows. Include OAuth grants, cloud accounts, databases, email, chat, source control, SSH, webhooks, and internal APIs.
7. Rotate connected secrets at their source. Revoking only the n8n credential record may leave an upstream provider token valid. Revoke or rotate it with the provider and review its access logs.
8. Check downstream activity. Correlate the exposure window with identity, cloud, database, source-control, mail, and network-egress logs.

A similar boundary appears after arbitrary file exposure: patching Rails CVE-2026-66066 does not make previously readable secrets private again. In both cases, containment and credential rotation are separate jobs.

How to prevent another n8n secret leak

• Store production keys in a managed secret store or protected CI variables, not in workflow exports, source files, examples, shell history, or AI-tool settings.
• Use short expirations and least privilege. Maintain an owner-reviewed inventory of automation identities and their connected services.
• Keep source-control repositories private unless public disclosure is intentional, and scan every commit before it leaves the organization.
• Prefer OAuth where n8n supports it, then revoke the grant at the upstream provider when exposure occurs.
• Review community nodes and restrict instance access, outbound network paths, and who can create credential-backed workflows.
• Run n8n’s security audit regularly and alert on new users, credentials, workflows, schedules, and unusual execution destinations.

References

1. The Hacker News. “Leaked n8n API Tokens Exposed Live Instances to Workflow and Credential Theft.” Reporting GitGuardian research, published August 5, 2026; accessed August 5, 2026. research report.
2. n8n. “Security audit.” n8n documentation; accessed August 5, 2026. official audit documentation.
3. n8n. “Security.” n8n security guidance; accessed August 5, 2026. official security guidance.