GitGuardian researchers found 321 live n8n instances accepting API tokens that had been committed publicly to GitHub — and showed how those tokens alone let an attacker move from passive enumeration to raw credential theft without exploiting any software vulnerability.
Scope of the exposure: 4,576 credentials tied to 1,255 hostnames
GitGuardian scanned public GitHub commits for n8n API tokens and extracted every hostname committed alongside each token. The pipeline identified 4,576 unique credentials associated with 1,255 hostnames. Of the 896 instances that were reachable at the time of testing, 321 accepted at least one leaked token — roughly 36% of reachable instances and about 26% of all hostnames the researchers found in commits.
The search also targeted the newer n8n Model Context Protocol (MCP) keys used by AI assistants. Of 372 MCP tokens identified in the same commit set, seven were still valid at the time of testing — roughly 2%.
Why these API tokens can remain usable
An n8n API key is a signed JSON Web Token whose decoded contents include an iat (issued-at) claim and often no exp (expiration) claim. n8n introduced a 30-day default expiration in version 1.78.0 in February 2025, but many tokens found in public commits had been generated without an expiration timestamp. Because the token must also still exist in the instance database to be accepted, a key published months earlier can remain usable until it is explicitly deleted or revoked.
Testing a candidate token requires only a read-only request to the public REST API with the key sent in the X-N8N-API-KEY header; a 200 response confirms the token is accepted, a 401 indicates an invalid or removed token, and a 404 can indicate the public API is disabled. The hostname was often committed beside the token (for example in .env or Claude Code settings files), so attackers do not generally need a separate discovery step.
This site is the portfolio.
OSINTSights runs on Cloudflare Workers, D1, R2, and Vectorize, with an AI pipeline on Hetzner ARM. Nubivance designed, built, and operates it. We do the same for clients.
See what we build →Four practical attack techniques reproduced in a controlled environment
Using a deliberately vulnerable n8n deployment, GitGuardian reproduced four practical attack techniques that require only documented REST API calls and standard HTTP requests — no CVE exploitation or specialized tooling.
- Technique 1 — Enumeration: GET /api/v1/users and GET /api/v1/workflows returned account listings and complete workflow definitions. In the test, an HTTP Request node parameter contained a plaintext GitHub token visible through workflow definitions.
- Technique 2 — Use stored OpenAI credential: GET /api/v1/credentials listed stored credential objects by name and ID. The researchers created and activated a Schedule-triggered workflow that referenced the OpenAI credential by ID; because executions persist outputs, GET /api/v1/executions?includeData=true returned the OpenAI responses in plaintext without ever revealing the credential value itself.
- Technique 3 — Read internal data tables: A Schedule-triggered Data Table node retrieving all rows produced an execution record that exposed names, email addresses, form responses and statuses via GET /api/v1/executions?includeData=true.
- Technique 4 — Exfiltrate the raw credential: An HTTP Request node configured to use a stored n8n credential as its authentication method was pointed at an attacker-controlled listener. When the workflow fired, n8n attached the stored credential value as a Bearer token in the outgoing Authorization header, allowing capture of the raw API key seconds after activation.
GitGuardian noted that deleting a malicious workflow also removes its execution records from the interface, potentially leaving defenders with limited evidence inside n8n itself.
Real-world workflows, blast radius, and hosting patterns
The controlled testing mirrored real findings. GitGuardian found an n8n workflow that automatically backed up its definitions to a public GitHub repository and had an SSH deployment key hard-coded in a node; the repository’s Git history contained earlier workflow versions and the SSH key remained valid. This demonstrates how automation platforms can amplify exposure: workflows sit between databases, source control, cloud services, AI APIs and customer platforms, and a single compromised token can lead to access across multiple systems.
Approximately 30% of the 321 affected instances were hosted on n8n.cloud or similar managed services. Separately, as of March 31, 2026, 58% of scanned instances were running a version affected by at least one known security advisory; several recent CVEs allowed sandbox escape and arbitrary filesystem access, and CVE-2025-68613 (an expression injection 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.
How hosting providers, affected companies, and n8n operators are responding
GitGuardian attempted responsible disclosure with seven organizations: three hosting providers collectively associated with roughly 100 affected instances, and four individual companies. One hosting provider did not respond; three of the four individual companies did not respond. One company with a bug bounty program acknowledged the report, paid a $1,200 bounty, and revoked the credential immediately.
GitGuardian also disclosed issues directly to n8n; 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 GitGuardian’s publication, it had not independently confirmed that the related fixes had been released. GitGuardian updated its n8n API key detector and validity checks and its Public Monitoring already identifies exposed n8n API tokens and notifies affected developers through its Good Samaritan disclosure program.
Revoking an exposed n8n token is necessary but not sufficient. Organizations must determine which workflows, data, and downstream credentials the account could access, review instances for unauthorized changes, and rotate connected credentials where exposure cannot be ruled out. The research shows that with a single leaked token, attackers can enumerate configuration, run stored credentials, read internal data, and — crucially — force n8n to transmit secrets to attacker-controlled infrastructure without exploiting a software vulnerability.
