GitGuardian finds leaked API tokens accepted by 321 n8n instances

GitGuardian researchers identified 4,576 unique n8n API tokens in 5,469 public GitHub commits, associated with 1,255 hostnames. Of 896 instances reachable during testing, 321 accepted at least one leaked token—36% of reachable systems and roughly 26% of all identified hostnames.

The team also found 372 Model Context Protocol keys in the same commit set. Seven remained valid, showing that MCP access for AI assistants represents another, albeit smaller, exposure surface.

Why the tokens remained useful

An n8n API key is a signed JSON Web Token with a public-api audience claim. Older keys often have no expiration claim. n8n introduced a default 30-day lifetime in version 1.78.0 in February 2025, but keys created without an expiry can remain usable until they are deleted or revoked.

The hostname was frequently committed alongside the key in environment files, source code or Claude Code permission files. This pairing removed the need for separate infrastructure discovery. A single read-only request to the workflows endpoint could then confirm whether an instance still recognized the credential.

Access depended on the permissions of the user who created the token. A privileged key could expose users, complete workflow definitions, execution records, data tables and variables. Definitions may contain JavaScript or Python code, SQL queries and secrets placed directly in node parameters.

Documented API functions enabled four attacks

GitGuardian reproduced four techniques in a controlled, fully patched n8n deployment. The researchers used documented REST API functions and standard HTTP requests; they did not exploit a CVE or use specialized tooling.

• Enumerating users, workflows and security configuration.
• Running prompts through a stored OpenAI credential without seeing its value.
• Reading rows from an internal data table through workflow execution output.
• Sending the raw OpenAI credential to an external listener through an HTTP Request node.

The last technique exploited legitimate platform behavior. n8n must decrypt stored credentials when workflows run. A newly created workflow could reference a credential object and direct an authenticated request to an attacker-controlled address, causing the secret to appear in the outgoing authorization header.

The audit endpoint could also identify the running version, potential SQL injection paths, filesystem-capable nodes, unprotected webhooks, unused credentials and installed community nodes. In the hands of a leaked privileged token, that report becomes a map of potential attack paths.

The risk extends across connected systems

Automation platforms connect source repositories, databases, cloud services, AI APIs, support tools and customer data. GitGuardian found a real workflow that backed up definitions to a public GitHub repository while carrying a hard-coded SSH deployment key; the key remained valid in repository history.

Revoking the exposed n8n key is therefore only the first response. Businesses should establish which workflows, records and credential objects the account could access, review the instance for unauthorized changes, and rotate connected credentials when exposure cannot be excluded. The practical impact is determined by every system the automation account could reach, not only by the n8n instance itself.