The recent discovery by GitGuardian researchers highlights a growing threat to automation platforms: exposed n8n API tokens residing in public code repositories. By scanning millions of GitHub commits, the team uncovered over 4,500 distinct credentials linked to more than 1,200 hostnames, with roughly one‑third of the reachable instances accepting at least one leaked token. This figure translates to a quarter of all identified n8n deployments being potentially vulnerable to credential theft without the need to exploit a software flaw. The scale of the exposure underscores how easily development practices can unintentionally broadcast privileged access, turning a seemingly innocuous commit into a gateway for attackers. Organizations that rely on n8n for orchestrating workflows must now reassess their secret‑management pipelines, because a single token can unlock a cascade of downstream systems. The findings serve as a stark reminder that credential hygiene is as critical as patch management in modern cloud‑native environments. Moreover, the incident illustrates that attackers no longer need to hunt for zero‑day vulnerabilities when legitimate credentials are already available in the wild, shifting the defensive focus toward detection, revocation, and continuous monitoring of exposed secrets.
Credentials often leak when developers place configuration files directly into version control without proper exclusions. The research identified two prevalent patterns: classic .env files that contain the n8n hostname alongside the API key, and newer Claude Code permission files where users embed both the instance URL and token inside an approved curl command within .claude/settings.json or .claude/settings.local.json. Because these settings files are not typically covered by standard .gitignore rules, they can be committed unintentionally, exposing the token to anyone with repository access. Beyond these examples, the token appeared under a variety of custom variable names such as N8N_API_KEY, AUTOMATION_TOKEN, or workflow‑specific labels, making detection reliant on pattern‑matching rather than a single known key. This diversity of naming conventions means that automated secret‑scanning tools must be flexible enough to catch variations while avoiding false positives. Teams should therefore enforce pre‑commit hooks that scan for any string resembling a JWT with the public‑api audience claim, and educate engineers on the risks of hard‑coding secrets in any text file that enters the repository.
n8n occupies a privileged position in many technology stacks because it acts as a glue layer that connects disparate systems such as databases, source‑control repositories, cloud providers, AI services, and customer‑support platforms. Its low‑code interface allows teams to build complex workflows quickly, but this convenience also means that a single compromised credential can provide an attacker with a foothold into multiple downstream environments. When an API token with administrative privileges is leaked, the attacker gains the ability to read workflow definitions, inspect stored credential metadata, and even trigger arbitrary executions that can reach out to external endpoints. This amplifies the potential impact far beyond the automation platform itself, turning a credential leak into a conduit for data exfiltration, privilege escalation, or lateral movement. Consequently, organizations that treat n8n merely as an internal tool may underestimate the breadth of risk, whereas a holistic view that considers every integrated system is essential for effective threat modeling and risk mitigation.
From a cryptographic standpoint, an n8n API key is a signed JSON Web Token that carries an audience claim set to ‘public‑api’. The token includes an issued‑at timestamp (iat) but, in many older versions, lacks an expiration claim (exp), meaning the token remains valid until it is explicitly removed from the server’s database. Starting with version 1.78.0, released in February 2025, n8n introduced a default 30‑day lifetime for newly generated keys, yet a substantial portion of the tokens discovered in the research predated this change and therefore carried no built‑in expiry. Unlike self‑contained JWTs that can be validated solely by signature verification, n8n requires the token to still exist in its internal store; a leaked key remains dangerous as long as the instance has not revoked it. This reliance on server‑side state creates a window of exposure that can stretch for months or even years if administrators forget to rotate or delete old keys, underscoring the importance of maintaining an up‑to‑date inventory of active API credentials.
The first step for an attacker who obtains a leaked token is to verify its validity against the target instance. A simple HTTP GET request to the /api/v1/workflows endpoint, with the token supplied in the X‑N8N‑API‑KEY header, returns a 200 response if the credential is still recognized, thereby confirming authenticated access without altering the system. Once validated, the same endpoint reveals the complete definitions of all workflows available to the token’s owner, including the configuration of each node. If a developer has inadvertently placed a secret directly inside a node parameter rather than using n8n’s encrypted credential store, that value appears in plaintext within the workflow JSON. This read‑only exposure already provides a wealth of information, such as internal API endpoints, hard‑coded keys, or configuration details that can be leveraged for further attacks. Importantly, these actions require no privileged exploits; they rely exclusively on documented REST API functionality that is accessible to any authenticated user.
In the controlled demonstration, the researchers began by calling the workflows endpoint and received a list of nine workflow definitions. One of these workflows contained an HTTP Request node whose parameters included a GitHub personal access token in clear text. Because the token was embedded as a literal string rather than referenced from a credential object, the API returned it verbatim, granting the attacker immediate access to a source‑control repository. This scenario illustrates a common anti‑pattern where developers treat workflow nodes as a convenient place to store secrets, bypassing the platform’s built‑in protection mechanisms. The lesson here is twofold: first, organizations should enforce a policy that all secrets must be managed through n8n’s credential store, and second, automated workflow reviews should scan node configurations for any values that resemble tokens, keys, or passwords. By catching such misplacements early, teams can prevent the leakage of high‑value assets that would otherwise be exposed through a simple API call.
The second technique showed how an attacker could leverage a stored credential without ever seeing its raw value. After retrieving the list of credentials via the /api/v1/credentials endpoint—which only returns metadata such as name, type, and identifier—the team created a new workflow containing a Schedule trigger and an OpenAI node configured to reference the stored credential by its internal ID. When the workflow executed, n8n decrypted the credential, used it to authenticate against the OpenAI API, and returned the model’s response. By subsequently querying the executions endpoint with the includeData flag, the researchers obtained the full output of each node, including the plaintext response from the OpenAI call. This approach required only two API calls: one to start the workflow and another to fetch the execution log. It demonstrates that possession of a valid n8n token enables an attacker to piggyback on any integrated service for which credentials are stored, effectively turning the automation platform into a proxy for unauthorized access to external APIs.
The third method mirrored the second but targeted internal data stores instead of external services. Using the same Schedule trigger, the researchers added a Data Table node set to retrieve all rows from a table containing customer contact information, form submissions, and processing statuses. Upon execution, the workflow produced a detailed record that persisted in n8n’s execution history. By calling the executions endpoint with includeData=true, the attacker extracted the complete dataset, which included names, email addresses, questionnaire answers, and internal flags. Four rows were exfiltrated in the test, but the technique scales to any size of table accessible to the workflow’s permissions. This highlights a risk that is often overlooked: even if an organization never stores credentials in plaintext, the ability to run arbitrary queries against internal data stores can lead to significant data leakage. Defenders should therefore restrict workflow permissions to the minimum necessary, audit which workflows have access to sensitive tables, and monitor execution logs for unexpected data‑export patterns.
The final technique demonstrated how an attacker could obtain the actual secret value of a stored credential, rather than merely using it indirectly. The researchers set up an external HTTP listener and constructed a workflow with a Schedule trigger and an HTTP Request node. The node was configured to authenticate using the stored OpenAI credential, but instead of sending the request to OpenAI’s endpoint, the URL was pointed at the attacker’s listener. When the workflow fired, n8n inserted the decrypted credential value as a Bearer token in the Authorization header of the outgoing request, which the listener captured in real time. This method effectively turns any outbound HTTP request node into a conduit for credential exfiltration, provided the workflow has permission to use the credential and to make arbitrary HTTP calls. Defenders can mitigate this risk by disabling outbound HTTP requests from workflows that do not require them, implementing network‑level egress controls, and employing runtime monitoring that flags unusual outbound connections originating from n8n instances.
The laboratory findings were corroborated by discoveries in live environments during the research. One notable example involved a workflow designed to automatically back up its own definitions to a public GitHub repository. Within that workflow, an SSH deployment key had been hard‑coded directly into a node parameter, meaning that each execution pushed the key into the repository’s history. Because the repository was public, the SSH key remained accessible to anyone who cloned the repo, granting persistent access to the source‑control server. The researchers observed that earlier versions of the workflow retained the same key, indicating that the secret had been exposed for an extended period without detection. This case exemplifies how automation platforms can amplify blast radii: a single misconfigured node not only leaks the immediate secret but also disseminates it across integrated systems, creating multiple avenues for compromise. Organizations must therefore treat workflow backup processes with the same scrutiny as any other code‑deployment pipeline, ensuring that secrets are never embedded in version‑controlled artifacts.
When the researchers attempted responsible disclosure, they contacted seven organizations whose instances were found to be vulnerable. Only one entity operated a formal bug bounty program; it acknowledged the report, awarded a $1,200 bounty, and revoked the compromised credential immediately. The remaining six either did not respond or provided only cursory acknowledgments without remediation. In parallel, GitGuardian engaged directly with n8n’s security team, which confirmed awareness of the issue and indicated that fixes were planned, though independent verification of released patches was pending at the time of publication. The analysis also showed that roughly 30 % of the affected instances were hosted on n8n.cloud or comparable managed offerings, suggesting that even customers who rely on the vendor’s hosted service are not immune to credential leakage stemming from client‑side misconfigurations. This mixed response landscape highlights the need for clear communication channels, standardized disclosure processes, and timely patch distribution across both self‑hosted and SaaS deployments.
To mitigate the risk posed by exposed n8n tokens, organizations should adopt a multi‑layered defense strategy. First, immediately revoke any token discovered in public commits and rotate all downstream credentials that might have been accessed, assuming compromise until proven otherwise. Second, enforce the principle of least privilege by reviewing the roles and permissions associated with each API key, ensuring that accounts used for automation possess only the rights necessary for their specific workflows. Third, integrate automated secret‑scanning tools into the CI/CD pipeline that can detect JWT‑style tokens with the public‑api audience claim, including variants lacking expiration claims, and block commits that contain them. Fourth, enable logging and monitoring of n8n API usage, setting alerts for anomalous patterns such as sudden spikes in workflow creation, execution of outbound HTTP requests, or repeated accesses to the credentials endpoint. Finally, conduct regular workflow audits to verify that secrets are stored exclusively in the encrypted credential store and that no node contains hard‑coded keys or tokens. By combining technical controls with disciplined development practices, companies can significantly reduce the likelihood that a leaked API token translates into a material breach.