Malicious n8n Community Node Flagged in npm Malware Wave

On July 30, 2026, a malicious npm package named n8n-nodes-trust-me-im-totally-safe was flagged as critical in the supplychainattack.org incident catalog. The name is the point. It follows n8n's community node convention, the n8n-nodes- prefix that n8n uses to discover and install third-party workflow integrations. A poisoned n8n community node is not an ordinary dependency. It runs inside an automation server that usually holds API keys, OAuth tokens, and database credentials for every system a team has wired together. That is why this one is worth a closer look, and why it landed alongside a batch of other malicious npm packages caught the same day.

What happened

Automated npm malware scanning surfaced n8n-nodes-trust-me-im-totally-safe as containing malware, and it was recorded as a critical incident on July 30, 2026. The package uses the naming scheme n8n requires for community nodes, so it would appear as an installable integration to anyone browsing or searching for nodes from an n8n instance.

At the time of writing, no vendor writeup with file hashes or command-and-control domains had been published, so the exact payload behavior is not yet publicly documented. That gap is normal for a package caught within hours of appearing. The safe assumption is straightforward: treat the package as fully malicious, and treat any instance that installed it as compromised until you can prove otherwise.

The joke name suggests this could be a proof of concept or a deliberately obvious test rather than a quiet, long-lived campaign. That does not change the risk. npm and n8n do not judge intent. A package that executes attacker-controlled code inside your automation server is dangerous whether the author meant it as research or theft.

Why n8n community nodes are a supply chain risk

n8n is a self-hostable workflow automation platform. Teams use it to connect SaaS APIs, cloud providers, databases, and internal services, then run those connections on a schedule or via webhooks. Community nodes extend it with integrations that n8n does not ship itself, and they are distributed as npm packages.

To be discoverable as a community node, a package must use the n8n-nodes- prefix (or a scoped @scope/n8n-nodes- name) and declare the n8n-community-node-package keyword in its package.json. That low bar is the whole attack surface. Anyone can publish a package that matches the convention, and it becomes something an operator can install with a couple of clicks.

The reason the blast radius is larger than a typical library comes down to where the code runs. n8n stores credentials for the services it connects to, and community node code loads into the same process. Code running there can read those stored credentials, reach any internal network the server can reach, and trigger existing workflows. One malicious node can turn into broad credential theft and lateral movement, not just a single compromised build.

The wider npm malware wave on July 30

The n8n node did not show up alone. The catalog logged several other critical npm entries the same day, including litespeed-cache, a package reusing the name of the very popular LiteSpeed Cache WordPress plugin, and test2221. Two AI-agent themed packages were also flagged, @ai-plus/de-agent and @ai-plus/de-agent-sdk.

The day before, on July 29, scanners caught a cluster of AI-agent packages such as @ai-agent-node/agent-node and related names. None of this is a single coordinated operation. It is the steady background rate of npm malware: dozens of throwaway packages per day, some typosquats, some brandjacks, some plugin-shaped lures like the n8n node. Detection is catching them quickly, but the checks still have to happen in your own dependency tree, not just in a scanner's feed.

Who is affected

The primary exposure is self-hosted n8n instances that allow community node installation and pulled this package. If an operator installed it and used the node in a workflow, assume the process had a chance to run attacker code.

npm users who added the package directly to a project are also affected, though that is a narrower group because the name is specific to n8n. Managed n8n Cloud tenants are lower risk where community node installation is restricted to a verified set, but confirm your own configuration rather than assuming it.

How the attack works

There are two points where an npm package can execute code, and both matter here. The first is install time, through lifecycle scripts such as preinstall and postinstall that run when the package is added. The second is import or run time, when the module is loaded and, in n8n's case, when the node actually executes inside a workflow.

n8n loads community node code into its own process when the node is used, so even a package that skips install scripts still gets code execution the moment an operator runs a workflow that references it. The common goals in this class of package are consistent: read environment variables and credential stores, send them to an external endpoint, or pull down a second-stage payload. The specific behavior of this package is not documented publicly yet, so do not rely on a particular indicator. Rely on the fact that it ran, or could have run, with access to your secrets.

How to check your n8n community nodes

In the n8n UI, open Settings, then Community nodes, to list what is installed. For self-hosted instances, community nodes live in the n8n user folder, which defaults to ~/.n8n/nodes. Inspect it directly:

cat ~/.n8n/nodes/package.json
ls ~/.n8n/nodes/node_modules
grep -R "n8n-nodes-trust-me-im-totally-safe" ~/.n8n/nodes 2>/dev/null

For any general npm project, check whether the name is present in your tree or lockfile:

npm ls n8n-nodes-trust-me-im-totally-safe
grep -n "n8n-nodes-trust-me-im-totally-safe" package-lock.json

If none of those return a match, this specific package is not installed. That does not clear you of the other names flagged the same day, so grep for those too if you run AI-agent or WordPress-adjacent tooling.

Remediation

If you find the package, work through these steps in order.

Remove the node. In n8n, use Settings, then Community nodes, and uninstall it. On a self-hosted host you can also remove it from the user folder:

cd ~/.n8n/nodes
npm uninstall n8n-nodes-trust-me-im-totally-safe

Rotate every credential stored in the affected n8n instance. That means API keys, OAuth tokens, database passwords, and webhook secrets. Assume all of them leaked, because the node ran in a process that could read them.
Rebuild the host if you cannot rule out a second-stage payload. Uninstalling the package does not undo anything it already executed.
For plain npm projects, remove the dependency, delete node_modules, and reinstall from a clean lockfile. If you need to inspect first, install with scripts disabled:

npm ci --ignore-scripts

Reduce future exposure. n8n exposes an environment setting, N8N_COMMUNITY_PACKAGES_ENABLED, to turn off community node installation entirely; set it to false if you do not use community nodes. Where you do use them, prefer verified nodes and an allowlist. npm v12 also blocks lifecycle install scripts by default, which helps at install time, though it does not stop code that runs when a node executes.

FAQ

Is n8n-nodes-trust-me-im-totally-safe safe to use?

No. It is flagged as malware in the supplychainattack.org catalog as of July 30, 2026. Do not install it, and if you already did, remove it and rotate the credentials stored in that n8n instance.

How do I know if I am affected by the n8n community node malware?

Check Settings, then Community nodes, in the n8n UI, and inspect the ~/.n8n/nodes folder on self-hosted instances. Grep your package-lock.json for the package name in any npm project. If the name is absent, this package is not installed, but keep checking for the other names flagged the same day.

Can a malicious n8n community node steal my credentials?

Yes, potentially. n8n stores credentials for the services it connects to, and community node code runs in the same process, so it can read those secrets and reach systems the server can reach. That is why credential rotation, not just uninstalling, is the right response.

Does npm v12 stop this kind of attack?

Only partly. npm v12 blocks install scripts by default, which closes the install-time path. n8n loads node code at runtime, so a malicious community node can still execute when the node runs in a workflow. Disabling install scripts is useful, but it is not a complete defense for the n8n case.