Community Nodes Risks

Hi there,

I love the concept of community nodes. Takes me back to the 90’s when Claris / FileMaker opened up their software to additional functionality through plug-ins/extensions, which really boosted it’s potential.

What worries me though, are the security risks …

Is it possible to check these risks, or have some kind of quality assurance system? Or even some kind of Node Store?

I really appreciate the good work all the n8n node developers are doing, and I’m sure that most, if not all of them are trustworthy, but as I see it now, it is only safe to use a community node if you really know the people that made it.

Hey @dickhoning,

You are not wrong there, So we have an internal process where if someone reports a bad node we can block it but as far as I am aware we have no reports. Personally I will only ever install nodes that I can view the source for but the other side of this is any time software is installed on a mobile device or computer there is almost the same level of risk although some companies do have teams of people to review every submission (looking at you :apple:).

There have been some talks about other things we could do in the future but a big part of the community nodes is to allow node developers to create and release a node that almost everyone can use without needing to wait for a review from us which can take some time.

I would love to have something in the nodes tab in n8n that shows Community Nodes that are from trusted community members or ones that we have taken some time to look at and test but I don’t think something like that will happen any time soon.

Hey @Jon

Is there a way of knowing if the NPM package released is the same as the sourcecode on GIT for example?

Hey @BramKn,

Not easily and I guess that is the other potential problem where I could publish one version and commit a different version. The way to get around that would be to maybe install the package in a sandbox and compile the git repo then compare the outputs.

Yeah thats a hassle.
If someone wants to do harm they will do something like that.
Of course a breaking change as described on the docs, isn’t the biggest concern, as you can simply not update if it already works properly or roll back.

1 Like

Totally agree, there are for sure risks involved. But in the end, is it exactly the same with literally every package on npm. With everything you install from npm (including n8n) you install at the same time a thousand other packages which are dependencies or dependencies of dependencies, … and each of them could be malicious. So even if we would start to review the nodes, and mark some of them as checked (which we have planned) it will sadly still not be 100% secure as we would then just review the code of the node but not the code of all the dependencies and their dependencies and so on. Nor would we check if the code in npm is identical with the code in GitHub.


Hi @jan thanks for your explanation. I appreciate that nearly nothing is 100% secure, but at the same time wondering whether there are tools that can scan the node modules for potential vulnerabilities?

And one more question: will npm audit no take (partially) care of this?

Any idea what might be wrong here and how to fix this?

Last login: Thu Nov 10 07:47:34 on ttys005
ecxs@developmentecxscom ~ % n8n --version
ecxs@developmentecxscom ~ % npm audit
# npm audit report

glob-parent  <5.1.2
Severity: high
glob-parent before 5.1.2 vulnerable to Regular Expression Denial of Service in enclosure regex -
fix available via `npm audit fix --force`
Will install [email protected], which is a breaking change
  glob-stream  5.3.0 - 6.1.0
  Depends on vulnerable versions of glob-parent
    help-me  1.0.0 - 1.1.0
    Depends on vulnerable versions of glob-stream
      mqtt  1.14.1 - 4.2.6
      Depends on vulnerable versions of help-me
        n8n-nodes-base  >=0.91.0
        Depends on vulnerable versions of mqtt
          n8n  >=0.96.0
          Depends on vulnerable versions of n8n-nodes-base

6 high severity vulnerabilities

To address all issues (including breaking changes), run:
  npm audit fix --force
ecxs@developmentecxscom ~ %