"monorepo-symlink-test" dependencies malicious

[jaykumarjp]

when we install pm2 it also install 5 level dependency ""monorepo-symlink-test"" which is known as malicious.

steps:
install pm2 globally
use any sca scanner in project directory or
check /usr/local/lib/node_modules/pm2/node_modules/resolve/test/resolver/multirepo/package.json
you can see "monorepo-symlink-test" there which is malicious on synk website

[gdd1984]

Have seen same issue on AWS Inspector showing this CVE when using latest PM2
https://security.snyk.io/vuln/SNYK-JS-MONOREPOSYMLINKTEST-5865510

[eezib-prod]

Have seen same issue on AWS Inspector showing this CVE when using latest PM2
https://security.snyk.io/vuln/SNYK-JS-MONOREPOSYMLINKTEST-5865510

Exactly the same happening to me, AWS says to terminate :(

[avosper-intellaegis]

I submitted issue ticket for this directly w/ resolve project:
browserify/resolve#319

[ljharb]

It's a false positive; if AWS inspector is showing you this then I would seriously discourage relying on it, since keying on the "name" field of a package.json gives you zero signal about whether files are malicious or not.

[eezib-prod]

Hmm it looks someone created this public repo which was originally infected, and your is private. Not only AWS but Google's scanner flagged this.

[ljharb]

The package.json inside resolve just coincidentally happens to have the same "name" value as an entirely unrelated malicious public package. I'd suggest complaining to both AWS and Google, because their scanner is checking something that's useless (the "name" field) instead of checking for the actually malicious code.

[jsifalda]

the information in AWS scanner is somehow misleading. We managed to fix this vulnerability by removing the "read-installed" dependency from your prod container, which was part of the "licence-checker" lib, and that happened to the fix this issue in "resolve" package

[whyayala]

It's a false positive; if AWS inspector is showing you this then I would seriously discourage relying on it, since keying on the "name" field of a package.json gives you zero signal about whether files are malicious or not.

This is your response to every scanning tool that flags this.

I think the idea is to search for known malicious packages in the most obvious place to look. One false positive does not invalidate several scanning tools. You're picking a strange hill to die on when you could simply rename it and stop having people open endless duplicate tickets. You do you though.

[ljharb]

@whyayala yes, that's because it's the correct response.

Any false positives drastically reduce the value of a tool, because noise undermines user trust in the system. It would be far better to have false negatives than to ever have false positives.

[whyayala]

It would be far better to have false negatives than to ever have false positives.

Both reduce value, but a false negative is far more damning to a tools value than a false positive. Especially when you are scanning for security vulnerabilities. A false negative is an attack vector, a false positive is an inconvenience.

For anyone having this issue, another way to remediate it is with a post install script to remove the test folder from resolve.

You can either add this line to your package.json file
"postinstall": "rm -rf $(find . -type d -path \"**/resolve/test\" -maxdepth 10)",
and it'll get ran post npm install, or you can run the command itself at some point during your build process. I would test it before baking it into your process. The main point to take away is you just need to delete the file within that folder to remediate the false positive. I opted to just remove the whole test folder as the maintainer has indicated that nothing in there is used in production.

[ljharb]

That’s not a solution; you just need to update your lockfile, and stop using any broken tools that complain about this.