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)
Sounds like I need to block NPM at the firewall.
Or make your developers liable for their shit.
NPM was a mistake
It is a mistake built on a much bigger mistake called JavaScript….
Yep.
but but how will I know if a number is even or not without “isEven” package?
You could implement some algorithm for finding even numbers and then precompute a list of even numbers from 0 to 4294967296. Insert them into database and you can then use simple SQL query
SELECT [Number].[DecimalValue] FROM [Number] INNER JOIN [EvenNumber] ON [Number].[ID] = [EvenNumber].[ID] WHERE [EvenNumber].[IsEven] = 1 and [EvenNumber].[Value] = YOUR_NUMBER_HEREPrecomputing all even numbers for floats will probably be more difficult because for each number there can be many combinations of after-comma values.
You can save some space by only store the number you need. ;)
I think it has something to do with if a number is divisible by 0…
or was it 1… ?
Whatever…, that’s why we have packages, so that programmers can focus on the important stuff…
/s
Divided by 2 without a remainder. X MOD 2 = 0.
isOdd = ( number & 0x00000001 );