Npm audit fails

General
1

When running npm audit with the latest node-red version (2.0.5) it cannot fix all issues:

> npm audit fix
[...]
up to date in 4.834s

76 packages are looking for funding
  run `npm fund` for details

fixed 0 of 3 vulnerabilities in 772 scanned packages
  3 vulnerabilities required manual review and could not be updated
>> npm audit
                                                                                
                       === npm audit security report ===                        
                                                                                
┌──────────────────────────────────────────────────────────────────────────────┐
│                                Manual Review                                 │
│            Some vulnerabilities require your attention to resolve            │
│                                                                              │
│         Visit https://go.npm.me/audit-guide for additional guidance          │
└──────────────────────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High          │ Arbitrary File Creation/Overwrite via insufficient symlink   │
│               │ protection due to directory cache poisoning using symbolic   │
│               │ links                                                        │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ tar                                                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=4.4.16 <5.0.0 || >=5.0.8 <6.0.0 || >=6.1.7                 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ node-red                                                     │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ node-red > @node-red/runtime > @node-red/registry > tar      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/1779                            │
└───────────────┴──────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High          │ Arbitrary File Creation/Overwrite via insufficient symlink   │
│               │ protection due to directory cache poisoning using symbolic   │
│               │ links                                                        │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ tar                                                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=4.4.18 <5.0.0 || >=5.0.10 <6.0.0 || >=6.1.9                │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ node-red                                                     │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ node-red > @node-red/runtime > @node-red/registry > tar      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/1780                            │
└───────────────┴──────────────────────────────────────────────────────────────┘
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High          │ Arbitrary File Creation/Overwrite on Windows via             │
│               │ insufficient relative path sanitization                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ tar                                                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=4.4.18 <5.0.0 || >=5.0.10 <6.0.0 || >=6.1.9                │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ node-red                                                     │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ node-red > @node-red/runtime > @node-red/registry > tar      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/1781                            │
└───────────────┴──────────────────────────────────────────────────────────────┘
found 3 high severity vulnerabilities in 772 scanned packages
  3 vulnerabilities require manual review. See the full report for details.

How can I fix these high severity vulnerabilities?

2

We will be publishing new 1.x and 2.x releases today that address this.

3

Thanks for pushing an update so quickly. Can npm audit fix the upcoming security issues now?

4

No. You will need to install the new version of Node-RED in the usual manner.

5

It would be a great feature, if the user can update security related issues themselves. Why wait for a release of Node-RED, when a minor version of a dependency have to be updated, only?

6

Yes, the user is free to manually fix things if they wish, but as the screenshot you posted shows , npm can't fix them automatically, and there is no way of telling if forcing the update will break something else, as usually the dependency is buried within some other dependency.

7

As long as Node-RED pins all versions and don't allow npm to update dependent packages "Compatible with version" (See semver), the user won't be able to do so, I guess.

8

I think that experience shows that forcing audit updates will often break things in a way that is pretty well impossible to debug.

9

I agree, that the packages should be locked somehow. But banning the user to update compatible versions does not contradict with it, from my perspective. Updating may break something, but running a version with known security flows is already broken.

10

Luckily its all open source so you can update whatever you want as often as you want.

11

I think (though not certain) that npm audit fix may update to versions that are not consistent with the settings in package.json. It treats your instruction to fix it as permission to override package.json. That is why it may break things.

12

But it needs a deeper knowledge, if package.json does not allow updates.

13

As does fixing the code when you randomly update packages to latest.

14

Can you explain what you mean by that?

15

I think what the op is saying node-red ships with exact semantic versions specified in the package deps and therefore doesn't permit any patch or minor updates without an audit fix or modifying package.json

16

Ah, yes, if talking specifically about node-red rather than other modules.

17

Having played with Node.js for many years now, I can safely say that I would never allow the npm audit to "fix" anything. At least unless I really knew the thing it was fixing and what packages were relying on it.

No matter how hard you try maintain good semantic versioning, it is always prone to mistakes and often to interpretation as well.

I rely on GitHub extensions to tell me if any of my dependencies have problems and need updating and I grab the latest version of dependencies when I do a new version of my own nodes. Anything else is going to bite you in the nether regions at some inopportune moment and should be avoided.

18

I agree fully, running npm audit fix can break your software/nodes, especially when running unattended and automatically. On the other hand, if have to review every detected problem, your users will have a bad time, when your on vacation or tangled in other stuff.

If you update your dependencies (not matter how), you'll have to test the changes. After updating your dependencies, you could test your software with Github Actions (or antoher CI/CD tool) automatically. If your tests pass, your nodes are working. So from my point of view, an automated update process requires an automated testing step. If you have that, npm audit fix is a piece of cake.

Users of node-red need to test their flows, after updating node-red anyway. They could rely on the locked set set of modules (via package-lock.json) and have the ability to use npm audit fix. I see no reason why this feature is hold back from them.

19

Remember that node red makes use of many modules that are not under the control of the node red team. If one of those is updated and five minutes later a user runs audit fix then they would get that update before anyone has time to run any tests.

20

How to fix the following stuff?

┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High          │ Incorrect Comparison in axios                                │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ axios                                                        │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=0.21.2                                                     │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ node-red                                                     │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ node-red > node-red-admin > axios                            │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://github.com/advisories/GHSA-cph5-m8f7-6c5x            │
└───────────────┴──────────────────────────────────────────────────────────────┘