Understand filesystem takeover vulnerabilities in NPM JavaScript package manager

First:<p>One package can attack by declaring a malicious executable (bin) with the same name as one from a package that you would intentionally use.<p>Second:<p>If the malicious package is installed globally, it is injected into your regular PATH, and can similarly &quot;hijack&quot; regular commands.<p>-<p>At first I read tfa and said &quot;and? Thats what I expect it to do&quot;. Then I noted:<p>* for a given package installation, a dependencies dependencies bins are available. This is generally counter intuitive.<p>* conflicting bin entries do not generate warnings or errors.<p>On a personal note: - I dont install node modules globally. Wrt development it should stay in repo, and I&#x27;m not a fan of managing system utilities from anywhere other than my distros package manager.. largely because its a PITA (I&#x27;m looking at you Python). - I cant think of any reason why non top level dependencies should have their bin files exposed. That is madness. - if it was just top level files, this would be a meh - I <i>should</i> get a conflict warning but I (or my cocontributors) deliberately installed those packages, so im not too bothered there.

The fact that &quot;bin&quot; files of globally installed dependencies can overwrite each other silently - it&#x27;s an understandable oversight, and I&#x27;ll be glad if npm&#x2F;yarn notifies me in the future.<p>What surprised me was that the &quot;bin&quot; names can be a relative or absolute path, like:<p>&quot;bin&quot;: { &quot;&#x2F;usr&#x2F;bin&#x2F;date&quot;: &quot;.&#x2F;fake-date&quot; }<p>That is scary! I&#x27;m guessing these paths will be sanitized in the newest versions of package managers, but that seems like it was a pretty big security hole.<p>As others have commented, I prefer not to install things globally - mostly locally linked packages of my own. I believe projects should not require or recommend globally installed commands, everything it needs for building should be in its local node_modules folder.

Why would one use such a exploit? - Using a postinstall script to do evil stuff is way more powerful and simpler to use. And thus more dangerous. If I want to hide something I put it in my libraries code (the user installed it, so at some point in time will `require` my code)<p>Depending on code loaded means you trust it.

There seems to be a typo in the blog post -- yarn needs to be updated to 1.21.1, not 1.12.1