GitGuardian researchers found 321 n8n instances accepting API tokens exposed in public GitHub commits and demonstrated four ways attackers could use them to access sensitive data and downstream credentials without exploiting a software vulnerability.
We scanned public GitHub commits for exposed n8n API tokens and identified 4,576 unique credentials associated with 1,255 hostnames. Of the 896 instances reachable at the time of testing, 321 accepted at least one leaked token.
That means leaked credentials provided authenticated access to 36% of the reachable instances we tested, or roughly 26% of all hostnames identified in the commits.
The implications extend well beyond n8n. Organizations use the automation platform to connect databases, source code repositories, cloud environments, artificial intelligence services, customer support platforms, and other internal systems. A sufficiently privileged n8n token can expose workflow definitions and execution data, allow attackers to use stored credentials, and, in some configurations, enable them to extract the underlying credential values.
To measure the potential blast radius, we reproduced four practical attack techniques in a controlled n8n environment. Each required only documented REST API functionality and standard HTTP requests. No CVE exploitation or specialized tooling was necessary.
Why n8n is a high-value target
n8n is an open-source, low-code workflow automation platform with AI agent support and hundreds of built-in integrations. Organizations use it to connect internal tools, automate pipelines, implement business logic, and orchestrate API integrations across their technology stacks.
The platform can be self-hosted or deployed through n8n.cloud, and its open-source repository has attracted nearly 200,000 GitHub stars.
An n8n instance runs workflows composed of nodes. Some nodes trigger workflows on a schedule or through webhooks, while others transform data, execute code, or connect to external services using stored credentials such as API keys, tokens, and database passwords.
Those credentials are encrypted at rest using a master secret called N8N_ENCRYPTION_KEY. But n8n still needs to decrypt and use them whenever a workflow runs. An attacker with sufficient API privileges may therefore be able to reference those credentials in new workflows and make the instance use them on the attacker's behalf.
With more than 100,000 instances visible through Shodan and more than 50 security advisories published since January 2026, n8n has attracted the same attention as other high-value integration platforms.
As of March 31, 2026, 58% of the instances we scanned were running a version affected by at least one known security advisory. Several recent CVEs allowed attackers to escape execution sandboxes and gain arbitrary read or write access to the host filesystem.
CVE-2025-68613, an expression injection vulnerability with a CVSS score of 9.9, was added to the U.S. Cybersecurity and Infrastructure Security Agency's Known Exploited Vulnerabilities catalog on March 11, 2026, confirming exploitation in the wild.
Leaked API tokens create a separate risk. An attacker does not necessarily need to exploit an n8n vulnerability if a valid credential already provides authenticated access to the instance.
We found 321 instances accepting leaked tokens
GitGuardian Public Monitoring scans public sources for exposed credentials. For this research, we collected every n8n API token it had identified in public GitHub commits since April 2025.
Our pipeline extracted the n8n hostname committed alongside each token, sent a read-only validation request to the associated instance, and recorded the response.
The scan produced:
| Stage |
Count |
| Unique API tokens |
4,576 |
| GitHub commits containing tokens |
5,469 |
| Unique hostnames extracted |
1,255 |
| Publicly reachable instances |
896 |
| Instances accepting a leaked token |
321 |
The 321 confirmed instances represent approximately 36% of the 896 reachable instances and 26% of all 1,255 hostnames identified in the commits.
We ran the same process against n8n Model Context Protocol API keys found in the same commit set. MCP tokens allow AI assistants to call n8n workflows through the Model Context Protocol, making them a newer exposure surface than the REST API.
Of 372 MCP tokens identified, seven were still valid at the time of testing, or roughly 2%.
Why leaked n8n tokens can remain valid
An n8n API key is a signed JSON Web Token with an "aud": "public-api" audience claim. A decoded token looks like this:
{
"sub": "efdf9cca-049a-46aa-afdc-172f0824f6cb",
"iss": "n8n",
"aud": "public-api",
"jti": "aac8a7a8-c8c4-4855-8e8b-2806e90b16e1",
"iat": 1781551662
}
The token records its issuance time in the iat claim. Older n8n API keys frequently contain no exp claim defining when they expire.
n8n introduced a 30-day default expiration in version 1.78.0 in February 2025, but many of the tokens found during the research had been generated without an expiration date. A key committed to GitHub months earlier could therefore remain usable until someone explicitly deleted or revoked it.
In practice, n8n API keys behave differently from self-contained JWTs that can be validated using their signatures alone. The key must also still exist in the n8n database. A token exposed in GitHub remains dangerous as long as the instance continues to recognize it.
Testing a candidate token requires one read-only request with the key passed through the X-N8N-API-KEY header:
curl -s -o /dev/null -w "%{http_code}" \
-H "X-N8N-API-KEY: <token>" \
https://n8n.example.com/api/v1/workflows
GET /api/v1/workflows returns workflow definitions available to the authenticated user.
A 200 response confirms that the token is accepted. A 401 indicates that the token is invalid, has been removed from the database, or failed signature verification. A 404 can indicate that the public API is disabled on the instance.
The request makes no changes to the target instance.
The instance URL is often committed beside the token
An n8n API key is useful only when an attacker can identify the instance that accepts it. In public GitHub commits, however, the hostname and token frequently appear together.
A .env file is one common example:
N8N_URL="https://n8n.redacted.cloud:5678"
N8N_API_KEY="eyJhREDACTEDPWw4"
We also found a newer pattern associated with Claude Code permission files.
Claude Code can store permitted shell commands in .claude/settings.json or .claude/settings.local.json. When users configure Claude Code to interact with n8n, they may place both the instance URL and API key directly inside an approved curl command.
Bash(curl -s "https://automation.redacted.fr/api/v1/workflows" \
-H "X-N8N-API-KEY: eyJhREDACTEDegE")
These settings files can then be committed to a repository without the same .gitignore safeguards that developers commonly apply to .env files.
The same hostname-and-token pairing appeared under several other variable names, including:
N8N_MCP_URL
N8N_WEBHOOK_BASE_URL
process.env.N8N_URL
os.getenv("N8N_HOST", "...")
Because the hostname was usually available in the same commit as the token, our pipeline did not require a separate infrastructure discovery step.
What an authenticated n8n token exposes
An n8n API token provides access according to the permissions of the user who created it. In practice, many of the exposed tokens appeared to belong to instance owners or administrators, likely because those were the users configuring the integrations and committing the keys.
Depending on the account's role, the public REST API may expose:
GET /api/v1/users: Usernames, email addresses, account creation dates, and pending invitations. Some information is restricted to instance owners.GET /api/v1/workflows: Full workflow definitions, including node configuration, JavaScript or Python code in Code nodes, SQL queries, and secrets hard-coded in workflow parameters.GET /api/v1/credentials: Credential names, types, and sharing information, but not the underlying values. This endpoint is restricted to owners and administrators.GET /api/v1/executions: Workflow execution history. Adding ?includeData=true may return the complete input and output payload from each run.GET /api/v1/data-tables: Rows from tables visible to the authenticated user.GET /api/v1/variables: Variable names and their contents. This endpoint is restricted to owners and administrators.
Workflow definitions create the most immediate exposure because the API returns complete node configurations. If a developer placed an API key or token directly in a node parameter rather than using n8n's credential store, the value may appear in plaintext.
The credential endpoint itself does not return stored secret values. However, as our controlled tests demonstrate, an attacker with permission to create and execute workflows may be able to reference a stored credential and make n8n use or transmit it.
The audit endpoint provides an attack map
n8n's audit endpoint can provide an authenticated user with a security report for the instance:
curl -H "X-N8N-API-KEY: $JWT" \
-d "{}" \
-H "Content-Type: application/json" \
https://$N8N_INSTANCE/api/v1/audit
The response may identify:
- Potential SQL injection exposures in workflows
- Nodes with filesystem access
- Unprotected webhooks
- The running n8n version, which can be matched against known CVEs
- Unused credentials
- High-risk or community-installed nodes
- Enabled security features
- Node allowlists and blocklists
- Telemetry settings
For a legitimate administrator, this information supports security reviews. For an attacker holding a leaked privileged token, it can provide a prioritized map of the instance's most promising attack paths.
Four attack techniques against a fully patched instance
GitGuardian did not perform the following exploitation techniques against exposed third-party systems. We reproduced them in a controlled n8n deployment built specifically for the research.
The test workflow contained three deliberate weaknesses:
- A web form stored submissions in a data table accessible through authenticated workflows.
- An OpenAI node processed each submission using a stored credential object.
- An HTTP Request node published the output to GitHub using a token hard-coded in its node parameters.
Using that environment, we demonstrated four techniques, progressing from passive enumeration to active credential exfiltration.
![]() |
| Example n8n workflow |
Technique 1: Enumerating the instance
GET /api/v1/users returned four accounts: the instance owner, two active users, and one pending registration.
GET /api/v1/workflows returned nine complete workflow definitions. In the target workflow, the parameters of an HTTP Request node contained a GitHub token in plaintext.
This first technique required no workflow modification. The exposed information was already available through read operations permitted to the authenticated account.
Technique 2: Using a stored OpenAI credential
GET /api/v1/credentials listed every stored credential object, including one named "OpenAI account." The endpoint revealed its name, type, and identifier, but not the API key itself.
We created a workflow with a Schedule trigger and an OpenAI node referencing the credential by its ID, then activated it.
Two tricks make this work. The Schedule trigger automatically fires after roughly 10 seconds, giving the workflow time to complete. GET /api/v1/executions?includeData=true then retrieves the complete execution record. Because n8n persists every node's full output, the OpenAI response appears in plaintext.
We successfully ran arbitrary OpenAI prompts using the instance's stored credential without ever seeing its value.
Technique 3: Reading the data table
The same two tricks apply.
We created a workflow with a Schedule trigger and a Data Table node configured to retrieve all rows, then activated it. GET /api/v1/executions?includeData=true returned the execution record seconds later, with every row in plaintext.
Four rows were exfiltrated, including names, email addresses, form responses, and processing statuses.
The workflow was then deleted.
Technique 4: Exfiltrating the raw OpenAI credential
The fourth technique went beyond using a stored credential and extracted its underlying value.
We started an HTTP listener, then created a workflow with a Schedule trigger and an HTTP Request node.
The key trick is that the HTTP Request node can use a stored n8n credential as its authentication method while sending requests to any URL. We configured the node to use the stored OpenAI credential and pointed it at our listener.
When the workflow fired, n8n attached the credential value as a Bearer token in the outgoing Authorization header. The listener captured the raw API key seconds after activation.
The workflow was then deleted.
Together, these techniques show how an attacker can progress from a leaked n8n token to broader credential and data exposure using legitimate platform functionality:
- Enumerate users, workflows, and security configuration.
- Identify stored credential objects and hard-coded secrets.
- Use stored credentials without viewing their values.
- Read data available to workflows.
- Cause n8n to transmit a stored credential to attacker-controlled infrastructure.
Deleting the malicious workflow also removed the associated execution records from the interface, potentially leaving defenders with limited evidence to investigate.
Real-world workflows showed similar weaknesses
The controlled demonstration was not based on a purely theoretical configuration. During the research, we found real n8n instances containing similarly exposed patterns.
One workflow automatically backed up its own definitions to a public GitHub repository. An SSH deployment key had been hard-coded directly into one of its nodes.
The repository's Git history contained earlier versions of every workflow, and the SSH key remained valid.
The workflow was effectively publishing its own sensitive configuration and credentials each time it ran.
The case illustrates why workflow automation platforms can create unusually large blast radii. They sit between multiple systems, process sensitive data, and routinely authenticate to external services. A weakness in one workflow can expose access far beyond the automation platform itself.
Responsible disclosure produced limited responses
Finding a valid exposed credential is only the first step. The risk remains until the affected organization revokes it and addresses any downstream exposure.
We attempted responsible disclosure with seven organizations:
- Three hosting providers collectively associated with approximately 100 affected instances
- Four individual companies
One hosting provider did not respond. Three of the four individual companies also did not respond.
One company operated a bug bounty program, acknowledged the report, paid a $1,200 bounty, and revoked the credential immediately. That combination of recognition and rapid remediation was the exception.
GitGuardian also made several disclosures directly to n8n during the research. n8n acknowledged the reports, said it was aware of the issues and planned to address them, and subsequently closed the reports. At the time of publication, GitGuardian had not independently confirmed that the related fixes had been released.
Approximately 30% of the 321 affected instances were hosted on n8n.cloud or similar managed services.
GitGuardian Public Monitoring already identifies exposed n8n API tokens and notifies affected developers through the company's Good Samaritan disclosure program. The findings also led GitGuardian to update its n8n API key detector and validity checks to improve detection accuracy.
Takeaways
A leaked n8n token is not an isolated credential exposure. A sufficiently privileged token can expose workflow definitions, hard-coded secrets, execution data, and internal tables. It can also allow an attacker to use stored credentials or, by creating a workflow that sends them to an external endpoint, extract their underlying values.
No CVE or specialized tooling was required in our controlled tests. A few standard HTTP requests were enough to move from an exposed token to sensitive data and downstream credential access. An attacker could then delete the workflow and its associated execution records, leaving defenders with limited evidence inside n8n itself.
Revoking the exposed n8n token is the first step, but it may not be the last. Organizations should determine which workflows, data, and downstream credentials the account could access, review the instance for unauthorized changes, and rotate connected credentials where exposure cannot be ruled out.
Automation platforms create a particularly large blast radius because they sit at the center of an organization's integrations. A single token can provide a path toward source control, databases, cloud services, AI APIs, support platforms, and customer data. The risk is defined not only by the n8n instance, but by every system connected to it.
About the author: Guillaume Valadon is a Staff Cybersecurity Researcher at GitGuardian, the secrets visibility and intelligence platform for securing the credentials that let code, machines, and AI agents access systems and act as trusted identities. Because attackers do not need to break in when they can log in with a valid credential, GitGuardian finds the secrets that matter across the whole secrets surface, inside and outside the perimeter, whether they are vaulted, stored, or leaked. It reveals their context and blast radius, then drives remediation at scale before one credential becomes a breach path. Trusted by 600,000+ developers and enterprises, including Snowflake, ING, BASF, Datadog, Qlik, Euronext, and Orange.
Found this article interesting? This article is a contributed piece from one of our valued partners. Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.
