GitHub commits are, for many developers, an archive of working configurations, but sometimes they also contain sensitive data. That’s again the case with n8n API tokens: security researchers found tokens that had been stored publicly in commits and were able to log in to n8n instances without exploiting a software flaw.
The risk goes beyond “a token was leaked.” If someone has an n8n token with sufficient privileges, they can view workflow definitions, retrieve executions, and—depending on the settings—use stored downstream credentials or expose the underlying values. In this article, you’ll see what was found and what you can do today to reduce the risk.
What was discovered in GitHub?
The researchers collected n8n API tokens that had been present in public GitHub commits since April 2025. They then linked each token to the corresponding n8n hostname and tested with a read-only REST request to determine whether the token was still accepted by that instance.
The scan revealed 4,576 unique credentials tied to 1,255 hostnames. In total, 896 instances were reachable at the time of testing, and 321 instances accepted at least one leaked token.
In practice, leaked tokens enabled authenticated access to roughly 36% of the reachable instances that were tested. For the hostnames, the figure was around 26%.
Why n8n is such an attractive target
n8n is an open-source (low-code) workflow automation platform with many built-in integrations. Organizations use it to connect applications, for example for:
- databases and internal systems
- source code repositories and CI/CD-like processes
- cloud environments and APIs
- AI services
- customer support and other business platforms
Workflows consist of nodes that process data, execute code, or connect externally using stored references such as API keys, tokens, and database passwords.
Those tokens are encrypted “at rest” with a master secret (N8N_ENCRYPTION_KEY), but n8n still needs to decrypt and use them when a workflow runs. If an attacker logs in using the right n8n API tokens, they can cause workflow actions to run under the authority of the user who created the token.
How do tokens stay usable, even after you created them?
An n8n API key is a signed JSON Web Token that includes, among other claims, an “aud” claim: public-api. More important than the structure alone is whether the key still exists and remains valid within the n8n database.
There’s also the question of whether an expiration date is present. In earlier versions, a default “30-day” expiration term was introduced. Tokens generated without an exp claim can therefore still be accepted months later, until someone explicitly revokes or removes them.
What can an attacker do with an authenticated n8n token?
The impact depends on the permissions of the user behind the token. Many of the tokens found in the research appeared to come from instance owners or administrators, meaning the potential access was relatively broad.
The researchers explicitly note that the public REST API (within the rights of the authenticated account) can expose, among other things:
- User information (depending on role)
- Workflow definitions including node configurations
- Credential metadata (name/type/sharing, but not necessarily the actual secret values)
- Workflow execution history
- Data from datatables visible to that user
- Variables and their contents (often only for owners/admins)
Workflow definitions are particularly sensitive because they can contain complete node configurations. If developers put a token or API key directly into a node parameter (instead of via n8n’s credential store), it can suddenly become visible in the interface—and through the REST API as well.
The credential endpoint doesn’t always return the underlying secret value. But combined with the right permissions, an attacker can still run workflows that use stored credentials, or have data “come back” through execution records.
The audit endpoint as a roadmap for attackers
n8n has an audit endpoint that, with a valid token, can generate a security report. For a legitimate administrator, that’s useful for review and hardening. For an attacker, it becomes a kind of priority list of potential entry points.
In practice, the audit output can highlight, among other things:
- possible SQL injection weaknesses in workflows
- nodes with filesystem access
- unprotected webhooks
- the running n8n version (to map to known issues)
- unused credentials
- high-risk or community-installed nodes
- enabled security features, allowlists, and blocklists
- telemetry and other configuration information
Four attack techniques without a CVE exploit
An important detail: the researchers demonstrated the risks in a controlled n8n environment without a CVE exploit or specialized tooling. They only needed standard HTTP requests, leveraging legitimate n8n REST functionality.
Their test workflow included three intentional weaknesses: a web form that stored input in a data table, an OpenAI node that used a stored credential, and an HTTP Request node that used GitHub with a token stored in the node parameters.
Technique 1: mapping the instance
With an authenticated token, they could enumerate without changing workflows. For example, GET /api/v1/users returned a small set of accounts (owner, active users, and a pending registration).
After that, GET /api/v1/workflows turned out to be enough to obtain full workflow definitions. In the example, one workflow contained a GitHub token in plaintext inside an HTTP Request node.
Technique 2: using a stored OpenAI credential
Through GET /api/v1/credentials, they could find credential objects (name/type/id) without directly seeing the secret value.
Then they created a new workflow with a Schedule trigger and an OpenAI node that referenced the credential by ID. Because the schedule trigger automatically fired—and later, using GET /api/v1/executions?includeData=true, they retrieved the full execution data—the result of the OpenAI node could be viewed in plaintext. So they didn’t need to steal the token itself in order to have the prompts executed.
Technique 3: reading a data table via workflow execution
Here too, the pattern worked with a Schedule trigger and a Data Table node. By subsequently fetching execution data with includeData=true, they received the table rows back in plaintext in the execution record.
This produced sensitive data, such as names, email addresses, form responses, and processing statuses. Afterwards, they removed the workflow again; depending on how the organization reviews incidents, that can limit the evidence within n8n.
Technique 4: exfiltrating the raw credential by “forwarding” it
The most advanced step was actually leaking the underlying secret value. The trick was that an HTTP Request node can use a stored n8n credential as the authentication method, while the request goes to an attacker-controlled endpoint.
By starting a listener and activating a workflow that used the OpenAI credential as a Bearer token to that listener, the researchers could receive the real API key as soon as n8n made the outbound request.
Afterward, they removed the workflow again to reduce traces inside the interface.
What does this say about “real-world” workflows?
The demonstration wasn’t purely theoretical. In the research data, realistic patterns were also observed that resembled the lab setup.
For example: a workflow that automatically backed up to a public GitHub repository, with an SSH deployment key placed directly in a node. The Git history contained earlier versions of the workflow, and the key remained valid in those versions too. In other words, the workflow effectively published itself—and thus sensitive configuration and credentials with every run.
Why this goes beyond n8n alone
The biggest danger is that n8n doesn’t exist in isolation. The platform acts as a link between multiple systems. If an attacker gains access to the right workflow context via n8n API tokens, they can, in one move:
- view source and workflow definitions
- retrieve execution data
- use stored credentials towards third parties
- potentially expand downstream account and API access
That means the “blast radius” isn’t defined only by the n8n instance, but by everything connected to it: repositories, databases, cloud services, AI APIs, and internal customer data.
What you can do: practical measures
If you use n8n, it’s wise to treat this as credential exposure with potential cascading effects. The steps below help reduce the likelihood of misuse and limit the impact.
1) Revoke and rotate any leaked or suspicious tokens immediately
Don’t treat a compromised n8n API token as “a small incident.” Start with revocation. Then rotate any secrets used by workflows.
2) Assess what permissions the token had
Check especially whether the token could read workflows, read data tables, request executions, or run new workflows. The higher the permissions, the greater the risk of exfiltration.
3) Look for hard-coded secrets in workflow parameters
Watch for workflow definitions where tokens are set directly in node parameters. In that case, an attacker may still see the value via read-only APIs, or retrieve it via execution output.
4) Review audit and security settings
Use the (legitimate) audit report to identify which configurations deserve extra attention: webhooks, allowlists/blocklists, nodes with higher privileges, and unused credentials.
5) Also consider external representations like backups
If workflow definitions are automatically written back to GitHub or backed up, “code review” or .gitignore protection may be insufficient. Check whether hostnames and tokens have ever appeared together in commits.
Conclusion
The discovery of n8n API tokens in public GitHub commits shows that credential theft doesn’t always begin with exploiting a vulnerability. With a valid, privileged token, an attacker can use n8n through normal REST functionality to expose workflow definitions, execution data, and sensitive connections to other systems.
Revocation and rotation are necessary, but just as important is a broader assessment: which workflows could do what, where hard-coded secrets are located, and which downstream systems are at risk due to n8n’s integrations.
By recognizing that chain early, you reduce the chance that one leaked token turns into a larger breach through automation.
Related reading: Gitea vulnerability: read unauthenticated files and ChainDrop: 400+ infected NPM packages provide additional context on how exposure in development pipelines and integrations can feed into real compromises.
Source: https://thehackernews.com/2026/08/leaked-n8n-api-tokens-exposed-live.html
