Checking n8n Community Nodes: how much trust third-party code deserves

An n8n Community Node is an npm package from someone you don't know, and it runs on the same machine as your access credentials for CRM, accounting and mailbox. Installation takes two minutes, the responsibility stays with you afterward. The question before production use is therefore not a functional question but a supply chain question: who maintains this code, how often, and what happens if nobody cares about it anymore tomorrow.

The pool is large enough that gut feeling isn't enough. The npm registry reports for the package keyword prescribed by n8n 12,022 packages (retrieved August 3, 2026). This is about the extensions, not the n8n core: for that there is the article on security hardening.

What permissions does a Community Node draw on your instance?

A Community Node runs with the same permissions as n8n itself. The n8n documentation on the risks states this without sugarcoating it: Community Nodes have "full access to the machine that n8n runs on, and can do anything, including malicious actions", and every node used has access to the data in your workflows.

That is why installation is tied to roles. On a self-hosted instance, according to the installation documentation only Owner and Admin may install Community Nodes from npm, and the dialog requires active confirmation of the sentence "I understand the risks of installing unverified code from a public source". In addition, n8n maintains a blocklist for packages that are deliberately malicious or deficient to a harmful degree.

That the risk is real and not theoretical has been documented by n8n itself. After the npm worm Shai-Hulud, the company reported in its Security Advisory of November 25, 2025 that the npm packages used in the n8n core were not affected, but two unverified Community Nodes were, whose installation was explicitly advised against.

What does "verified" really mean for n8n Community Nodes?

Verified means: n8n has checked the submitted package against a fixed catalog of security and quality requirements and added it to the node panel. At launch, according to the n8n announcement around 25 nodes, recognizable by a shield icon, from n8n 1.94.0 onward. The verification guidelines also serve as a benchmark for unverified packages:

• No runtime dependencies: every transitive dependency would be an additional foreign publisher in your supply chain.
• MIT license: so that further use and your own continued maintenance remain legally uncontested.
• No access to environment and file system: the code may neither read environment variables nor read or write files.
• Exactly one third-party service per package: no flow-control nodes, no duplicates of existing nodes.
• Passed scan: npx @n8n/scan-community-package must run without errors.
• Verifiable origin: since May 1, 2026, submitted nodes must, according to the submission documentation be published via GitHub Actions with a provenance statement; a publish from a local machine is no longer accepted.

One caveat belongs here: a submitted package is checked at one point in time. The seal does not answer who publishes the version after next.

What review criteria apply before production use?

Six criteria decide, and all six can be answered in a few minutes from public npm metadata, without reading a single line of code. The registry provides the fields time, maintainers, dist-tags, repository and license at registry.npmjs.org/<paketname>.

• Maintenance status: the field time contains every release timestamp. If the last release is more than twelve months old while the connected service has continued to develop its API, the node is on its way out.
• Bus factor: maintainers shows how many people are allowed to publish. A single private maintainer is not a disqualifying factor, but it is a reason to plan the replacement path in advance.
• Adoption: the endpoint api.npmjs.org/downloads/point/last-month/<paketname> returns downloads along with the time period. As a benchmark: the n8n package itself reaches 335,472 downloads there from July 4 to August 2, 2026. With a three-digit monthly figure, hardly anyone finds errors before you do.
• Dependency depth: the dependencies of the package. npm audit checks them against known vulnerabilities. Zero runtime dependencies is the target value.
• Origin and signature: whether repository points to a real, public repository. With npm audit signatures provenance attestations can be checked, meaning proof that the package originates from the stated repository and a traceable CI pipeline.
• Permission scope: which credentials does the node request, and does the scope match the purpose. A node for a single service that asks for broad permissions requires explanation.

What happens if the project is abandoned?

The abandonment of a project does not stand out at first, because the installed version keeps running. It becomes visible at the next n8n update: a Community Node that no longer fits the new n8n version can block the instance from starting, see n8n does not start after the update. A silent maintenance problem then turns into a failure of all workflows within a minute.

The exit plan therefore belongs before the installation. Three points are enough: a named replacement path, usually the built-in HTTP Request node against the same API, because a Community Node usually just makes a REST interface more convenient. A pinned version instead of a moving tag. And the list of affected workflows. The Installation via environment variable helps here: N8N_COMMUNITY_PACKAGES accepts a package name, an optional version and an optional SHA-512 checksum of the resolved tarball, which pins not just the version but the package content itself. In n8n Cloud the question is different, since only verified nodes are available there anyway, see switching from self-hosted to cloud.

How do you limit the risk on the instance?

The default settings of a fresh n8n instance are set to openness, not caution. Five environment variables change that. According to the environment variables documentation the following applies:

• N8N_COMMUNITY_PACKAGES_ENABLED: Default true. Set to false, the instance disables Community Nodes completely, both verified and unverified.
• N8N_UNVERIFIED_PACKAGES_ENABLED: Default true. Set to false, only verified nodes remain usable. The most effective single switch for most mid-market instances.
• N8N_VERIFIED_PACKAGES_ENABLED: Default true. Controls whether verified nodes appear in the node panel.
• N8N_COMMUNITY_PACKAGES_MANAGED_BY_ENV: Default false, from n8n 2.21.0 onward. Set to true, n8n reconciles the installed packages against the configuration on every start and makes the management interface read-only. The node inventory then becomes part of the deployment instead of the result of clicks.
• NODES_EXCLUDE: by default populated with n8n-nodes-base.executeCommand and n8n-nodes-base.localFileTrigger, extendable with any node that should not run.

In the n8n environments we operate for clients at NordFlux, the rule is: unverified Community Nodes are disabled on the production instance, candidates are reviewed on a separate test instance with their own credentials, and no node goes into production until its replacement path is documented. This costs half an hour during setup. More on this on the page about n8n hosting in Germany.

Frequently asked questions about n8n Community Nodes

Are verified n8n Community Nodes safe?

Verified nodes are checked by n8n against a fixed catalog: no runtime dependencies, MIT license, no access to environment variables or file system, exactly one connected third-party service, passed package scan. This significantly lowers the risk, but it does not replace checking the maintenance status, because the verification applies to a submitted package and not to every future version.

Can I use Community Nodes in n8n Cloud?

Only verified ones. Installation from npm, and thus all unverified nodes, is according to n8n documentation possible only on self-hosted instances. Anyone using unverified or self-built nodes must replace them before switching to the cloud.

How can I tell that a Community Node is no longer maintained?

By the field time in the npm metadata at registry.npmjs.org/<paketname>, which contains all release timestamps. A last release that is older than the last major API change of the connected service is the clearest signal.

How do I prevent employees from installing nodes on their own authority?

On self-hosted instances, only Owner and Admin accounts are allowed to install Community Nodes anyway; all other users can only use installed nodes. Anyone who wants to lock down the inventory sets N8N_COMMUNITY_PACKAGES_MANAGED_BY_ENV to true: management in the interface becomes read-only.

What to do if a node in use is reported as compromised?

Exclude the node from loading via NODES_EXCLUDE, stop affected workflows, rotate all credentials the node had access to. n8n publishes such cases in the Security Advisories category on the community forum.