PhantomRaven Attack Exploits NPM’s Unchecked HTTP URL Dependency Feature

An example of RDD in a package's dependencies list. It's not even counted as a 'real' dependency. (Credit: Koi.ai)
An example of RDD in a package’s dependencies list. It’s not even counted as a ‘real’ dependency. (Credit: Koi.ai)

Having another security threat emanating from Node.js’ Node Package Manager (NPM) feels like a weekly event at this point, but this newly discovered one is among the more refined. It exploits not only the remote dynamic dependencies (RDD) ‘feature’ in NPM, but also uses the increased occurrence of LLM-generated non-existent package names to its advantage. Called ‘slopsquatting’, it’s only the first step in this attack that the researchers over at [Koi] stumbled over by accident.

Calling it the PhantomRaven attack for that cool vibe, they found that it had started in August of 2025, with some malicious packages detected and removed by NPM, but eighty subsequent packages evaded detection. A property of these packages is that in their dependencies list they use RDD to download malicious code from a HTTP URL. It was this traffic to the same HTTP domain that tipped off the researchers.

For some incomprehensible reason, allowing these HTTP URLs as package dependency is an integral part of the RDD feature. Since the malicious URL is not found in the code itself, it will slip by security scanners, nor is the download cached, giving the attackers significantly more control. This fake dependency is run automatically, without user interaction or notification that it has now begun to scan the filesystem for credentials and anything else of use.

The names of the fake packages were also chosen specifically to match incomplete package names that an LLM might spit out, such as unused-import instead of the full package name of eslint-plugin-unused-imports as example. This serves to highlight why you should not only strictly validate direct dependencies, but also their dependencies. As for why RDD is even a thing, this is something that NPM will hopefully explain soon.

Top image: North American Common Raven (Corvus corax principalis) in flight at Muir Beach in Northern California (Credit: Copetersen, Wikimedia)

This Week In Security: The Shai-Hulud Worm, ShadowLeak, And Inside The Great Firewall

Hardly a week goes by that there isn’t a story to cover about malware getting published to a repository. Last week it was millions of downloads on NPM, but this week it’s something much more concerning. Malware published on NPM is now looking for NPM tokens, and propagating to other NPM packages when found. Yes, it’s a worm, jumping from one NPM package to another, via installs on developer machines.

It does other things too, like grabbing all the secrets it can find when installed on a machine. If the compromised machine has access to a Github account, a new repo is created named Shai-Hulud, borrowed from the name of the sandworms from Dune. The collected secrets and machine info gets uploaded here, and a workflow also uploads any available GitHub secrets to the webhook.site domain.

How many packages are we talking about? At least 187, with some reports of over 500 packages compromised. The immediate attack has been contained, as NPM has worked to remove the compromised packages, and apparently has added filtering code that blocks the upload of compromised packages.

So far there hasn’t been an official statement on the worm from NPM or its parent companies, GitHub or Microsoft. Malicious packages uploaded to NPM is definitely nothing new. But this is the first time we’ve seen a worm that specializes in NPM packages. It’s not a good step for the trustworthiness of NPM or the direct package distribution model.

Continue reading “This Week In Security: The Shai-Hulud Worm, ShadowLeak, And Inside The Great Firewall”

This Week In Security: NPM, Kerbroasting, And The Rest Of The Story

Two billion downloads per week. That’s the download totals for the NPM packages compromised in a supply-chain attack this week. Ninety-nine percent of the cloud depends on one of the packages, and one-in-ten cloud environments actually included malicious code as a result of the hack. Take a moment to ponder that. In a rough estimate, ten percent of the Internet was pwned by a single attack.

What extremely sophisticated technique was used to pull off such an attack? A convincing-looking phishing email sent from the newly registered npmjs.help domain. [qix] is the single developer of many of these packages, and in the midst of a stressful week, fell for the scam. We could refer to the obligatory XKCD 2347 here. It’s a significant problem with the NPM model that a single developer falling for a phishing email can expose the entire Internet to such risk. Continue reading “This Week In Security: NPM, Kerbroasting, And The Rest Of The Story”

This Week In Security: Npm Timing Leak, Siemens Universal Key, And PHP In PNG

First up is some clever wizardry from the [Aqua Nautilus] research team, who discovered a timing attack that leaks information about private npm packages. The setup is this, npm hosts both public and private node.js packages. The public ones are available to everyone, but the private packages are “scoped”, meaning they live within a private namespace, “@owner/packagename” and are inaccessible to the general public. Trying to access the package results in an HTTP 404 error — the same error as trying to pull a package that doesn’t exist.


The clever bit is to keep trying, and really pay attention to the responses. Use npm’s API to request info on your target package, five times in a row. If the package name isn’t in use, all five requests will take the expected amount of time. That request lands at the service’s backend, a lookup is performed, and you get the response. On the flipside if your target package does exist, but is privately scoped, the first request returns with the expected delay, and the other four requests return immediately. It appears that npm has front-end that can cache a 404 response for a private package. That response time discrepancy means you can map out the private package names used by a given organization in their private scope.

Now this is all very interesting, but it turns into a plausible attack when combined with typosquatting and dependency confusion issues. Those attacks are two approaches to the same goal, get a node.js deployment to run a malicious package instead of the legitimate one the developer intended. One depends on typos, but dependency confusion just relies on a developer not explicitly defining the scope of a package.

Continue reading “This Week In Security: Npm Timing Leak, Siemens Universal Key, And PHP In PNG”

This Week In Security: NPM Vandalism, Simulating Reboots, And More

We’ve covered quite a few stories about malware sneaking into NPM and other JavaScript repositories. This is a bit different. This time, a JS programmer vandalized his own packages. It’s not even malware, perhaps we should call it protestware? The two packages, colors and faker are both popular, with a combined weekly download of nearly 23 million. Their author, [Marak] added a breaking update to each of them. These libraries now print a header of LIBERTY LIBERTY LIBERTY, and then either random characters, or very poor ASCII art. It’s been confirmed that this wasn’t an outside attacker, but [Marak] breaking his own projects on purpose. Why?

It seems like this story starts back in late 2020, when [Marak] lost quite a bit in a fire, and had to ask for money on Twitter. Edit: Thanks to commenter [Jack Dansen] for pointing out an important detail that was missing. Marak was charged for reckless endangerment, and was suspected for possible terrorism aspirations, as bomb-making materials were found in his burned-out apartment. Two weeks later, he tweeted that billions were being made off open source devs’ work, citing a FAANG leak. FAANG is a reference to the big five American tech companies: Facebook, Apple, Amazon, Netflix, and Google. The same day, he opened an issue on Github for faker.js, throwing down an ultimatum: “Take this as an opportunity to send me a six figure yearly contract or fork the project and have someone else work on it.”
Continue reading “This Week In Security: NPM Vandalism, Simulating Reboots, And More”

This Week In Security: Printing Shellz, Ms-officecmd, And AI Security

Researchers at f-secure have developed an impressive new attack, leveraging HP printers as an unexpected attack surface. Printing Shellz (PDF) is a one-click attack, where simply visiting a malicious webpage is enough to get a shell and reverse proxy installed to a printer on the same network. The demo below uses a cross-site printing (XSP) attack to send the malicious print job to the printer without any further interactions.
Continue reading “This Week In Security: Printing Shellz, Ms-officecmd, And AI Security”

ua-parser-js compromised

Supply Chain Attack: NPM Library Used By Facebook And Others Was Compromised

Here at Hackaday we love the good kinds of hacks, but now and then we need to bring up a less good kind. Today it was learned that the NPM package ua-parser-js was compromised, and any software using it as a library may have become victim of a supply chain attack. What is ua-parser-js and why does any of this matter?

In the early days of computing, programmers would write every bit of code they used themselves. Larger teams would work together to develop larger code bases, but it was all done in-house. These days software developers don’t write every piece of code. Instead they use libraries of code supplied by others.

For better or worse, repositories of code are now available to do even the smallest of functions so that a developer doesn’t have to write the function from scratch. One such registry is npm (Node Package Manager), who organize a collection of contributed libraries written in JavaScript. One only need to use npm to include a library in their code, and all of the functions of that code are available to the developer. One such example is ua-parser-js which is a User Agent Parser written in JavaScript. This library makes it easy for developers to find out the type of device and software being used to access a web page.

On October 22 2021, the developer of ua-parser-js found that attackers had uploaded a version of his software that contained malware for both Linux and Windows computers. The malicious versions were found to steal data (including passwords and Chrome cookies, perhaps much more) from computers or run a crypto-currency miner. This prompted GitHub to issue a Critical Severity Security Advisory.

What makes this compromise so dangerous is that ua-parser-js is considered to be part of a supply chain, and has been adopted even by Facebook for use in some of its customer facing software. The developer of ua-parser-js has already secured his GitHub account and uploaded new versions of the package that are clean. If you have any software that uses this library, make sure you’ve got the latest version!

Of course this is by no means a unique occurrence. Last month Maya Posch dug into growing issues that come from some flaws of trust in package management systems. The art for that article is a house of cards, an apt metaphor for a system that is only as stable as the security of each and every package being built upon.