Leaked n8n API Tokens Exposed Live Instances to Credential Theft

Summary

Researchers discovered that hundreds of n8n automation platform instances were exposed to credential theft due to API tokens being leaked in public GitHub commits. Attackers could leverage these tokens to access sensitive data and downstream credentials without exploiting software vulnerabilities, impacting workflows connected to databases, cloud environments, and AI services.

Full text

Leaked n8n API Tokens Exposed Live Instances to Credential Theft The Hacker NewsAug 05, 2026AI Security / DevSecOps 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="http://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

Indicators of Compromise

• cve — CVE-2025-68613

Entities