The Problem

A couple of days ago there was a fairly major vulnerability injected into several low-level packages, in this case the debug package (supply chain attack). We were exposed to this compromise via a global install of pm2 into our app's docker container.

For more details on the vulnerability:

• (RESOLVED) Version 4.4.2 published to npm is compromised debug-js/debug#1005
• A helpful write up of the issue: https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised

It took us a while to understand how this version of debug was installed. When we install our app's dependencies via npm ci all the versions are locked down in the package-lock.json file. However, we were running an additional npm install pm2 -g command in the docker container. I've learnt that the dependencies of this aren't locked and that the package-lock.json is excluded/ignored in published npm packages. Therefore at install time the package.json is used to determine the packages and it had the following range: "debug": "^4.3.7" which therefore accepted the latest v4 minor version i.e. 4.4.2 which had the compromise in.

Solution(s)

npm-shrinkwrap.json

TIL that for CLI packages, like pm2, npm recommends publishing the package with an npm-shrinkwrap.json file which is not ignored and will lock down the versions of the dependencies.

Taking a quick look, I can see pm2 used to have an npm-shrinkwrap.json file and it was removed in v2.1.4. One tricky bit is that pm2 won't want the npm-shrinkwrap.json file for use as a JS library because that will prevent dependent applications from specifying overrides for transitive dependencies.

Fixed versions

An alternative solution, might be to pinned the versions in the package.json file and exclude ranges. This would avoid any issues with pm2 used as a CLI or library (vs the shrinkwrap method above). However, it may require more maintenance overhead of updating dependencies and publishing new versions of pm2. Before hand you could avoid that as the latest changes could be pulled in automatically.

Conclusion

Sorry to put more work on your plate when the issue wasn't in your package. Though, hopefully, any remedy made to address this will help future proof from similar exploits.