The recent discovery by GitGuardian researchers highlights a startling reality: over three hundred live n8n instances were accessible using API tokens that had been inadvertently committed to public repositories. This exposure affected roughly one‑third of the reachable systems scanned and underscores a growing trend where automation platforms become unintentional gateways to an organization’s most sensitive assets. Unlike traditional software vulnerabilities that require exploitation of a flaw, these attacks rely solely on the presence of valid credentials, making the threat surface far broader and often overlooked in standard vulnerability management programs. The scale of the issue is amplified by the sheer number of n8n deployments—self‑hosted and cloud‑based—that connect to databases, source control, AI services, and customer‑support tools, creating a dense web of trust that a single leaked token can traverse.
n8n’s popularity stems from its low‑code, visual workflow builder that enables teams to stitch together disparate systems without deep programming expertise. With hundreds of pre‑built nodes and support for AI agents, the platform has become a central nervous point for many enterprises seeking rapid integration and orchestration. However, this centralization also means that a compromised n8n account can inherit the permissions of its creator, often an administrator or DevOps engineer who configures the myriad connections. Consequently, a leaked token does not merely grant access to workflow definitions; it can unlock the ability to invoke any integrated service that the user is authorized to call, effectively turning the automation engine into a proxy for credential theft and data exfiltration.
Credentials find their way into public repositories through several common patterns. Developers frequently store n8n API keys in .env files for local testing, forgetting to add these files to .gitignore before pushing changes. A newer vector emerged from Claude Code permission files, where users embed the instance URL and API key directly inside approved curl commands within .claude/settings.json or .claude/settings.local.json. Because these JSON settings are less likely to be excluded by default ignore rules, they slip into commit histories alongside the token. In both cases, the hostname and token appear together in the same commit, eliminating the need for attackers to perform separate infrastructure discovery and reducing the barrier to exploitation.
From a technical standpoint, an n8n API token is a signed JSON Web Token (JWT) bearing an “aud”: “public-api” claim. While the JWT signature can be verified independently, the platform additionally checks whether the token still exists in its internal database—a design that means a token remains valid until explicitly revoked, regardless of any expiration claim. Older versions of n8n did not include an expiration timestamp by default, and even after the introduction of a 30‑day default expiry in version 1.78.0, many tokens found in the wild predated this change, leaving them usable indefinitely. This reliance on server‑side state rather than pure stateless validation creates a lingering risk window that attackers can exploit long after the original commit.
The first attack technique demonstrated by the researchers is pure enumeration. By presenting a leaked token in the X‑N8N‑API‑KEY header and issuing a GET request to /api/v1/workflows, an attacker receives a complete list of workflow definitions accessible to the token holder. Because the API returns the full node configuration, any secrets that were hard‑coded directly into workflow parameters—rather than stored in n8n’s encrypted credential vault—appear in plaintext. This passive step requires no modification of the target instance and immediately reveals valuable intelligence, such as embedded API keys, database connection strings, or internal service endpoints that can be leveraged for further intrusion.
Building on enumeration, the second technique shows how an attacker can weaponize stored credentials without ever seeing their values. Using the same privileged token, the adversary creates a new workflow that references an existing credential (for example, an OpenAI API key) by its internal identifier. A Schedule trigger ensures the workflow runs automatically after a brief delay, and the workflow invokes the external service using the stored credential. By subsequently querying the execution endpoint with includeData=true, the attacker retrieves the full output of the workflow, which includes the service’s response—such as generated text from OpenAI—in clear text. This method allows the abuse of trusted integrations to perform unauthorized actions, like generating malicious content or scraping data, while keeping the underlying secret hidden from the attacker’s view.
The third technique extends the previous idea to internal data stores. Instead of calling an external AI service, the attacker configures a workflow with a Data Table node set to pull all rows from a table that n8n uses for internal bookkeeping or application data. After triggering the workflow via the Schedule node, the execution endpoint again returns the complete dataset, exposing personally identifiable information, form submissions, or processing statuses. In the researchers’ test, four rows containing names, email addresses, and form answers were exfiltrated in seconds. Because the workflow is deleted after the data pull, the execution records vanish from the user interface, limiting forensic evidence and making detection reliant on logs outside of n8n’s UI.
The fourth and most sophisticated technique illustrates how an attacker can extract the raw value of a stored credential. By setting up an external HTTP listener and configuring an HTTP Request node to use a stored n8n credential as its authentication method, the attacker causes n8n to attach the credential value as a Bearer token in the outgoing Authorization header when the workflow runs. The listener captures this header, obtaining the secret in its entirety—such as an actual OpenAI API key—without needing to break any cryptographic protection. This approach leverages the platform’s legitimate ability to use stored secrets for outbound calls, turning a feature designed for secure integration into a conduit for credential theft. The workflow’s deletion after execution further obscures the attacker’s trail.
Beyond the laboratory, the researchers discovered real‑world instances that mirrored these risky patterns. One workflow was programmed to back up its own definitions to a public GitHub repository each time it executed. Within that workflow, an SSH deployment key had been hard‑coded into a node parameter, meaning every run pushed the secret key into the repository’s history. The key remained valid across commits, effectively publishing privileged access to the organization’s servers with each automation cycle. Such findings illustrate how workflow automation can amplify risk: a single misconfigured node can transform a routine backup job into a continuous leak of critical infrastructure credentials.
The blast radius of a compromised n8n token extends far beyond the platform itself. Because n8n orchestrates connections to databases, source‑control systems, cloud providers, AI APIs, ticketing tools, and customer‑relationship platforms, an attacker who gains privileged API access can pivot laterally across these environments. For example, a token that permits reading workflow definitions might reveal a hard‑coded AWS secret key, which could then be used to spin up malicious EC2 instances or exfiltrate S3 buckets. Similarly, exposed credentials for a CI/CD pipeline could enable the injection of malicious code into build artifacts. The interconnected nature of modern stacks means that the impact of a single leaked token is measured not by the n8n instance alone but by the sum of all trusted integrations it touches.
Response to the disclosed findings highlighted both challenges and opportunities in securing automation platforms. Out of seven organizations contacted, only one—operating a bug bounty program—acknowledged the report, paid a bounty, and promptly revoked the token. The remaining entities either did not respond or offered delayed feedback, underscoring a gap in incident response maturity for credential‑centric threats. GitGuardian’s own updates to its n8n API key detector and validity checks demonstrate how proactive monitoring can reduce exposure windows, but the onus remains on organizations to enforce rigorous secret hygiene, enforce .gitignore policies, and adopt automated scanning of both code and configuration repositories.
Organizations seeking to mitigate this risk should treat n8n API keys as high‑value secrets and apply a defense‑in‑depth strategy. First, implement mandatory secret scanning across all repositories, with particular attention to .env files, Claude Code settings, and any JSON or YAML configuration that might harbor tokens. Second, enforce short‑lived tokens or require regular rotation, leveraging n8n’s built‑in expiration where possible and supplementing with automated revocation workflows. Third, adopt the principle of least privilege when creating API keys, limiting them to the specific workflows or folders they need rather than granting global admin rights. Fourth, monitor execution and audit logs for anomalous workflow creation or unexpected outbound requests, and retain those logs outside the n8n UI to safeguard against tampering. Finally, conduct periodic red‑team exercises that simulate token leakage to validate detection and response capabilities, ensuring that a compromised credential cannot become a stepping stone to a broader breach.