top of page
perceptive_background_267k.jpg

Leaked n8n API Tokens Exposed Live Instances to Credential Theft

Published:

5 augustus 2026 om 12:35:29

Alert date:

5 augustus 2026 om 14:07:09

Source:

thehackernews.com

Click to open the original link from this advisory

Identity & Access, Data Breach & Exfiltration, Web Technologies, Enterprise Applications

GitGuardian researchers discovered 4,576 unique n8n API credentials associated with 1,255 hostnames exposed in public GitHub commits. Of these, 321 live n8n instances were found to be actively accepting the leaked API tokens. Researchers demonstrated four distinct attack methods that could be used to exploit these exposed credentials without needing to exploit any software vulnerability. The attack vectors enable unauthorized access to sensitive data and downstream credentials stored within n8n workflows. n8n is a workflow automation platform that often integrates with numerous third-party services, making credential exposure particularly dangerous. The findings highlight the ongoing risk of secrets being inadvertently committed to public repositories. Organizations using n8n are urged to audit their GitHub commits and rotate any exposed API tokens immediately.

Technical details

GitGuardian researchers scanned public GitHub commits and identified 4,576 unique n8n API tokens across 5,469 commits associated with 1,255 hostnames. Of 896 publicly reachable instances, 321 (36%) accepted at least one leaked token. n8n API keys are signed JWTs with 'aud': 'public-api' claims; older versions lacked expiration ('exp') claims, meaning tokens remained valid indefinitely until explicitly revoked. n8n introduced a 30-day default expiration in version 1.78.0 (February 2025). Tokens and hostnames were frequently committed together in .env files or Claude Code settings files (.claude/settings.json, .claude/settings.local.json). Four attack techniques were demonstrated using only standard REST API calls and HTTP requests — no CVE exploitation required: (1) Enumeration via GET /api/v1/users, /workflows, /credentials, /executions, /variables, /audit endpoints to map users, workflow definitions, hard-coded secrets, and security weaknesses; (2) Using stored OpenAI credentials by creating a workflow with a Schedule trigger referencing the credential by ID, then retrieving execution output via GET /api/v1/executions?includeData=true to run arbitrary prompts; (3) Reading internal data tables by creating a workflow with a Schedule trigger and Data Table node, then retrieving all rows through execution records; (4) Exfiltrating raw credential values by configuring an HTTP Request node to use a stored credential as Bearer token authentication pointed at an attacker-controlled listener, causing n8n to transmit the raw API key. Deleting malicious workflows also removes associated execution records, limiting forensic evidence. Additionally, 372 n8n MCP (Model Context Protocol) API tokens were found, of which 7 (2%) remained valid. As of March 31, 2026, 58% of scanned instances ran versions affected by at least one known security advisory. CVE-2025-68613 (CVSS 9.9, expression injection) was added to CISA's KEV catalog on March 11, 2026.

Mitigation steps:

1. Immediately revoke any n8n API tokens that may have been committed to public or private repositories. 2. Upgrade n8n to version 1.78.0 or later to enforce 30-day token expiration by default. 3. Audit all public GitHub repositories for exposed n8n API keys, MCP tokens, hostnames, and environment files (.env, .claude/settings.json, .claude/settings.local.json). 4. Review n8n instance audit logs and execution history for unauthorized workflow creation, activation, or deletion. 5. Rotate all credentials stored within n8n (API keys, database passwords, OAuth tokens) where exposure cannot be ruled out. 6. Review workflow definitions for hard-coded secrets in node parameters and move them to n8n's encrypted credential store. 7. Restrict n8n API access by disabling the public API if not needed, or limiting it to specific IP ranges. 8. Ensure n8n instances are not publicly reachable via Shodan or similar scanners unless strictly necessary; implement firewall rules and authentication. 9. Apply all available n8n security patches, especially for CVE-2025-68613 (CVSS 9.9) which is actively exploited. 10. Add .env and .claude/settings.local.json to .gitignore to prevent future accidental commits. 11. Use secret scanning tools (e.g., GitGuardian) to continuously monitor repositories for credential leaks. 12. Implement least-privilege API token policies — avoid using instance owner/admin tokens for integrations. 13. Monitor n8n instances for unexpected outbound HTTP requests that could indicate credential exfiltration workflows.

Affected products:

n8n (all versions prior to 1.78.0 lacking token expiration)
n8n (versions affected by security advisories as of March 31
2026 — 58% of scanned instances)
n8n.cloud (managed service)
n8n self-hosted instances

Related links:

Related CVE's:

Related threat actors:

IOC's:

X-N8N-API-KEY header used in HTTP requests to /api/v1/workflows, /api/v1/users, /api/v1/credentials, /api/v1/executions, /api/v1/audit, /api/v1/variables, /api/v1/data-tables, JWT tokens with 'aud': 'public-api' and 'iss': 'n8n' claims without 'exp' field exposed in GitHub commits, Environment variable patterns: N8N_API_KEY, N8N_URL, N8N_MCP_URL, N8N_WEBHOOK_BASE_URL in public repositories, .claude/settings.json and .claude/settings.local.json files containing n8n API keys and hostnames in public repositories, .env files containing N8N_URL and N8N_API_KEY committed to public GitHub repositories, Unexpected workflow creation or activation on n8n instances, Unexpected execution records referencing stored credentials, Outbound HTTP requests from n8n instances with Authorization: Bearer headers to external/unknown URLs

This article was created with the assistance of AI technology by Perceptive.

© 2025 by Perceptive Security. All rights reserved.

email: info@perceptivesecurity.com

Deze website toont informatie afkomstig van externe bronnen; Perceptive aanvaardt geen verantwoordelijkheid voor de juistheid, volledigheid of actualiteit van deze informatie.

bottom of page