4,576 leaked n8n API tokens put 321 live instances at risk
GitGuardian: 4,576 leaked n8n API tokens; 321 instances (~36%) accepted them. Adversaries can trigger workflows to exfiltrate stored creds with no CVE exploit.
In brief
- GitGuardian scanned public GitHub commits and found 4,576 exposed n8n API tokens and 1,255 hostnames; 896 instances were publicly reachable and 321 (~36%) accepted leaked tokens.
- Accepted leaked tokens let adversaries enumerate users, retrieve workflows, trigger executions and exfiltrate stored credentials or data; 58% of instances ran versions with known advisories, raising operational risk.
- Leaders should inventory exposed tokens and reachable instances, revoke compromised API keys, assess affected workflows and downstream credentials, apply n8n security updates, and monitor repositories for further leaks.
The problem
GitGuardian's scan of public GitHub commits found 4,576 exposed n8n API tokens and 1,255 hostnames; 896 instances were publicly reachable and 321 (≈36% of reachable instances) accepted leaked tokens. Those tokens give attackers the ability to enumerate users and workflows and to trigger executions that can exfiltrate stored credentials and data without exploiting a CVE—while 58% of instances run versions with known advisories, including CVE‑2025‑68613 (CVSS 9.9), materially raising the risk of lateral compromise and downstream credential theft.
Why this happens
GitGuardian’s scan found 4,576 exposed n8n API tokens and 1,255 hostnames; 896 instances were publicly reachable and 321 (~36%) accepted leaked tokens. Those API keys are signed JWTs (many older ones lacked exp and remain valid until removed from the n8n database); when a key is accepted the platform’s API lets an authenticated caller enumerate users and workflows and create/activate workflows. In practice an attacker can add a Schedule trigger + nodes that reference stored credentials or read data tables, let the workflow run, then retrieve execution records (or have the workflow POST secrets to an attacker listener) — and because workflows and their execution records can be deleted, evidence can be removed. With 58% of scanned instances running versions with known advisories (including CVE‑2025‑68613), the operational blast radius and chance of lateral compromise rise materially. Teams frequently under‑estimate this because they treat a leaked API key as lower risk when no CVE is required or when the /api/v1/credentials endpoint does not directly return secret values. That assumption misses the platform mechanism: legitimate features (activating workflows, scheduled runs, HTTP Request nodes) can be abused to surface or transmit secrets without any vulnerability exploit. The concrete buyer consequence is measurable — revoke exposed tokens, inventory reachable instances and workflows, rotate downstream credentials that could be accessed, and patch/configure instances (token expiry, API restrictions, node allowlists) to reduce blast radius and compliance exposure.
Framework
Revoke and rotate tokens
Identify and immediately revoke any exposed n8n API tokens, rotate downstream credentials reachable by those tokens, and enforce short token TTLs and mandatory expirations; prioritize keys tied to public commits. Doing this cuts active attacker access—GitGuardian found thousands of leaked tokens and hundreds of live instances accepting them—reducing immediate blast radius and lateral compromise risk.
Secrets in source control
Scan public and private repositories for committed n8n hostnames and API keys, remove sensitive files from history (or rotate if removal is impractical), and add pre-commit/CI secret scanning to prevent future leaks. The research shows tokens and hostnames were frequently committed together (e.g., .env and .claude files), so preventing commits is the highest‑leverage control.
Patch and harden instances
Inventory internet‑reachable n8n instances, prioritize upgrades for versions with published advisories (including CVE‑2025‑68613), disable public API when not required, and enable node allowlists/blocklists and API access restrictions. With >50 advisories and 58% of scanned instances vulnerable, patching and configuration changes materially lower the chance of downstream compromise.
Detect and respond to abuse
Instrument logging and external alerting for unexpected workflow creation/activation, scheduled triggers, executions with includeData=true, and deletions; run hunt queries for workflows that call unknown external endpoints and block suspicious outbound destinations. Because attackers can trigger workflows to exfiltrate stored credentials and then delete evidence, fast detection and containment is essential to limit data loss and preserve forensic trails.
How to get started
- Revoke all API tokens found in public commits; log token IDs and revocation timestamps.
- Inventory internet-reachable n8n hostnames and record version, public API status, and exposed-token acceptance.
- Rotate downstream credentials reachable by compromised accounts and force rotation for high-risk integrations.
- Patch all internet-reachable n8n instances to fixed versions or apply vendor-recommended mitigations.
- Enable logging and alerts for workflow creation, activation, executions includeData=true, external POST destinations.
Risks & trade-offs
Strategic zoom-out
GitGuardian’s discovery (4,576 exposed n8n API tokens, 1,255 hostnames, 896 reachable instances and 321 accepting leaked tokens) reframes workflow automation as a high‑blast‑radius infrastructure component: because many tokens lacked expirations and n8n workflows can be activated to read or exfiltrate secrets (and attackers can delete evidence), operators must treat API keys and instance visibility as first‑order operational controls. Practically, that means shifting governance to measurable token lifecycle policies (enforce token TTL ≤30 days as introduced in n8n v1.78.0, revoke known‑leaked tokens within 24–72 hours), an inventory of internet‑reachable instances with acceptance status recorded, and a patch cadence that reduces vulnerable instances (58% in the scan) on a 30–90 day remediation horizon. Investment priorities should favor automated repository scanning, CI/pre‑commit blocking of env/credential commits, hardening of public API exposure, and detection rules for unexpected workflow creation/activations and includeData executions; measurable outcomes are simple — zero public token acceptance, 100% token TTL enforcement, and a documented reduction in vulnerable internet‑facing versions within the next 12–24 months.
Next steps we recommend
Immediately inventory public GitHub commits and internet‑reachable n8n hostnames to identify accepted tokens, revoke those API keys within 24–72 hours, and log revocation timestamps; then rotate downstream credentials and record which workflows could access them for prioritized remediation.