Invisible npm malware pulls a disappearing act – then nicks your tokens A new supply chain attack dubbed PhantomRaven has flooded the npm registry with malicious packages that steal credentials, tokens, and secrets during installation. The packages appear safe when first downloaded, making them particularly difficult for security apps to identify. According to researchers at Koi, the campaign has …
The mechanism at play here is the use of urls as package dependencies; e.g.
"dependencies": {
"ui-styles-pkg": "http://packages.storeartifact.com/npm/unused-imports"
}
npm will happily install these. And nobody has scanned them.
Such modules can, occasionally, be useful in a leaf package. But they shouldn't be allowed in a public registry. (At least, not without a lot of oversight.)
QED
I'm confused. The article stated that the packages hasd "no dependencies", but your explanation is clearly a dependency of a type that could be easily detected (explicit unknown url). Does this vuln depend on automatic version upgrades which introduces depencies in a way that evades scanning?
The article also states the execution takes place during the installation, rather than when the software is executed by the user. Package managers don't purposely run the software, I think, so there is a step I don't understand.
Bleeping computer> "The mechanism fetches packages and executes them automatically when running ‘npm install’, and requires no user interaction."
So it seems! Yikes. This is on the package manager, isn't it? I suppose they are all promiscuous like that.
I wonder if DENO has taken a different approach.
I don't use npm BUT I assume that the dependency is supposed to point to a package or something (something.pkg !!!???) ... pun intended !!!
Using a URL appears to be allowed, it is not counted as a package dependency (!!!???) ... because no *.pkg is specified.
This means a URL is executed, instead of a package install, and it fetches something which is 'automagically' executed in turn !!!
It look like a bug to me, as stated.
It should sanitise the 'thing' in that position in the file and if it is not a (*.pkg) it should flag an error not execute it blindly.
Question:
Does this mean that if you put a 'command line' in the same position in the file ... would it execute that !!!???
:)
No, you can't have a command line.
Typically, the field contains a version. And npm uses that to find a matching version of the package in the registry.
But it can also be an url to tell npm where to retrieve it. npm supports git urls, so that can sometimes be useful in an application package - where you want a particular fork instead of the main branch. It also support local files via file: urls which, again, can be useful.
But I wouldn't expect npm to admit packages with these in, except in exceptional circumstances. It's not something I've ever seen.
This is the type of attack that worries the heck out of me when building source packages that rely on npm or pypi or the like. The build-system sees npm as a dependency and then pulls in npm and the dependent packages as part of an automated build. As a package maintainer performing test builds or a user building from source, you are compromised before you know it.
The only saving grace is most OS level build systems like Arch's makepkg can build in a clean chroot (makechrootpkg), mitigating some of the damage, but the only people that setup and take advantage of the additional steps to setup a chtoot build environment are package maintainers and a few advanced users. These "fetch on-demand" installers provide a wide-open attack path for miscreants to exploit that have shown themselves incapable of being made safe.
I keep notes on npm and pypi compromises, mostly from stories on the Register, and it doesn't seem much more than a month goes by in between revelations of a new compromise in either of them. Yes, I'm old, and likely a curmudgeon, but I'm of the opinion the only way to ensure sources are safe is to include the checksumed source, not "fetch on-demand" schemes as part of source-packages. Otherwise, without the ability to validate the sources before the build begins, we will be playing the game of exploit whack-a-mole forever.
>> The article stated that the packages hasd "no dependencies", but your explanation is clearly a dependency of a type that could be easily detected
Yes! The problem, according to the link (https://www.koi.ai/blog/phantomraven-npm-malware-hidden-in-invisible-dependencies) is that 'automated security system, these packages show "0 Dependencies."'
Which is nuts. It is just as easy to flag this as "This package has external dependencies. BEWARE".
There is also an obvious problem here: because the dependency package is fetched individually per install rather than stored for download, security scanners cannot easily detect that it is malware. Pseudo logic: if $clientip is in @knownsecurityscanners { send benign file } else { send malware }.
The packages should be marked as having external dependencies. Then it is in the hands of the people who download it.
So, there's a hole in npm's security model that one can drive an aircraft carrier through.
What to do about it? Block npm from using URLs as dependency sources? Most package managers I've seen will recursively satisfy dependencies. But only from the top level repository or some list of approved sites (mirrors, etc.) I see some talk about this URL thing as being a "neat feature" in some cases. But it may be too dangerous to remain. Particularly as miscreants have discovered and used this loophole.
To all the innocent devs who used this as a shortcut for doing cool stuff without the overhead of checking code into a repository: Sorry. It might just have to go.
People blindly installing a package or whatever, without any checking what it actually does. Because the 'community' checks it, doesn't it. Except, no, the community frequently does not check it.
>> Instead, it's dynamically retrieved during installation, leaving no obvious trace in the source files.
>> PhantomRaven demonstrates how sophisticated attackers are getting at exploiting blind spots in traditional security tooling
I'd argue that some people just install things without checking. That will always be the case. It also makes a good case for outbound firewall rules, default to block, which would show a bit more of what is going on. Years ago, I read some uninformed advice who wrote you don't need to block outbound traffic because you have that 'under your control'. Nice.
Next up, .vimrc files using curl or git to install a load of nice-looking themes. But how many people check what it actually being downloaded?
Some people seem to equate 'developer' with being somehow a bit more clever. Some are, but there's a lot of 'copy from Stack Overflow' developers out there. See here: https://www.theregister.com/2025/09/29/postmark_mcp_server_code_hijacked/.
The task used to be called "computer programming" - which, despite all the tedium in actually writing code to do things that had probably been done many times before, needed an understanding not only of the language but also the underlying concepts.
Now that skill has been replaced with choosing prewritten packages, gluing them together with code copy-and-pasted from Stack Overflow, and asking AI to polish it into a finished product. With a human probably having looked at less than a tenth of the code, if that.
Yes, a finished product drops out in the end - which relies on the integrity and security of the black boxes being stuck together. Sadly, this instance (as well as many others) demonstrates that it is not possible to assure that, or even to know where to start checking.
Your overall description covers how 'Vibe Coding' works ... only the Stack Overflow 'searching' is already done and encoded into the 'AI' that will 'help' you to 'write' your code !!!
GIGO but with a overconfident 'AI' to convince you you are getting the very best code that 100% does what you asked for !!!
FFS !!!
^'cheap at half the price' ==> for non-English speakers, YES it is nonsense 'word by word', look it up on google to make sense of it !!!
:)
... does it seem I am the only one who believes automatically downloading and installing/executing code which the programmer has never seen, let alone reviewed, is an unjustifiable security risk?
Sure, it's "useful". So was Microsoft Active Desktop. You could do all sorts of cool things with it. Problem was, so could everyone else.
Because there's no other way. Even in the days of C, you downloaded libraries other people had written and trusted it. You didn't have the time or the skill to vet these things. And probably blindly ran ./configure && make
But the library would have had a good reputation or you looked at the web site and the author seemed like they were for real and so you trusted them. It's that trust mechanism that has been broken. People are now trusting npmjs.org; they are not living up to that trust in every case. Although 99% of the time the only danger is a bit of lousy coding.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
