Published on 31 July 2026
A single import in your code – and a trojan takes over your developer's machine. That's exactly what happened to two widely used npm packages on 28 July 2026: @joyfill/components and @joyfill/layouts. For a few hours, attackers smuggled malicious beta versions into the npm registry (the central software directory for JavaScript and Node.js projects). Anyone who included one of these versions in their build or test process risked the complete compromise of their system – without a click or a deliberate execution being necessary.
The packages are downloaded around 16,000 times per week under normal circumstances. They are embedded in many applications without companies being consciously aware of it. Security researchers attribute the attack to the North Korean threat actor "PolinRider" – the same group also behind the infamous "Contagious Interview" campaign. This article explains what happened, whether you might be affected, and what concrete steps you need to take now.
On 28 July 2026, attackers published manipulated beta versions of the two legitimate npm packages. Specifically affected are:
These versions contained a highly obfuscated, five-stage malware chain. What makes it particularly dangerous: the malicious code is not triggered via a so-called postinstall script (a script that runs automatically after installation), but already when the package is merely imported into a Node.js project – for example via require() or import.
This means: a single unit test, a bundler run, starting the development server, or a production deployment is enough to trigger the malware. Varun Sharma from the security vendor StepSecurity puts it succinctly:
"The code is compiled into the package entry bundles and executes the moment a project imports the package: a unit test, a bundler run, a dev server or a production deploy." – Varun Sharma, StepSecurity
The Socket Research Team additionally warns:
"The @joyfill/layouts version should be considered capable of arbitrary code execution in the context of any process that loads it. This includes development environments, CI runners, test tooling, server-side rendering and builds." – Socket Research Team
At least: the maintainers reacted quickly. From 13:57 UTC they made clean versions available, and around 21:00 UTC the malicious versions were removed from the npm registry. But be careful: the malicious packages may still be present in caches, mirrors, and already-created build images. The window was short, but real.
The attack is remarkably sophisticated in its structure and runs through five stages. We explain them as simply as possible:
A9-0135-3), the malware selects the appropriate control server (command-and-control server, C2 for short), for example at the IP address 166.88.134.62.npm/lib/cli.js) – a worm-like behaviour that enables spreading to further projects.Why this elaborate detour via the blockchain? The SafeDep team explains it like this:
"The attack delays the HTTP C2 beacon until stage 2 and routes it through two rounds of blockchain queries before the C2 server URLs are even set ... This makes detection at early stages via network monitoring considerably harder." – SafeDep Team
In short: the attackers hide their control infrastructure behind legitimate blockchain traffic, so that classic security tools barely become suspicious.
In principle, any company is at risk whose developers or build systems pulled one of the named malicious versions during the short window on 28 July 2026. Particularly in focus are:
Important to understand: the attack does not target normal website visitors, but developers and the systems on which software is built. That's precisely why it is so dangerous – via stolen credentials the damage can quickly spread to your entire cloud infrastructure. This form of attack is called a supply chain attack: you yourself are not attacked directly, but rather a building block in your software supply chain.
To put the scale into perspective: according to reports, the PolinRider campaign comprises at least 108 malicious packages across the npm, Packagist, Go and Chrome platforms. Amazon Threat Intelligence also confirms the connection:
"Amazon Threat Intelligence has linked several recent compromises of popular Node Package Manager (NPM) libraries to the same DPRK-affiliated threat actor." – Amazon Threat Intelligence
Go through these four steps – ideally together with your technical team or service provider:
package-lock.json, yarn.lock and pnpm-lock.yaml (files that record exactly which package versions were installed) for the versions 0.1.2-2773.beta.* and 4.0.0-rc24-2773-beta.*.166.88.134.62, 23.27.13.43, 198.105.127.210 or 23.27.202.27, as well as for API calls to api.trongrid.io or bsc-dataseed.binance.org.npm/lib/cli.js) for suspicious code injections with markers such as /*C250617A*/.%USERPROFILE%\.npm (Windows) or /tmp/.npm (Linux/macOS).If you find signs of a compromise – or even just suspect you are affected – act immediately according to these steps:
@joyfill/layouts@0.1.1 and @joyfill/components@4.0.0-rc24. "Pinning" means that exactly this version is used and not automatically updated.The incident is not just an IT security problem, but can also trigger data protection obligations. The deployed infostealer OmniStealer harvests credentials and sessions comprehensively – including to cloud services and databases. This makes a leak of personal data (such as customer or employee data) very likely.
This gives rise to two central obligations:
Document the entire incident thoroughly – from discovery through the measures taken to recovery. In an emergency, this documentation is decisive vis-à-vis the supervisory authority.
The severity of this incident is critical. The risk for small and medium-sized companies is particularly high, because the attack requires no deliberate user interaction after installation – it triggers during the completely normal build or test process. A successful attack leads to complete takeover of the developer's machine and potentially your entire cloud infrastructure via stolen credentials.
The case shows once again how vulnerable modern software supply chains are. You probably use dozens or hundreds of third-party packages without ever having seen their code. This is precisely where attackers strike. That's why: automated security checks of your dependencies, pinning versions and a vigilant eye on unusual network traffic are not optional extras, but mandatory.
The compromise of @joyfill/components and @joyfill/layouts was active for only a few hours, but was highly dangerous. Because the malicious packages can persist in caches and build images, the threat is not eliminated with their removal from npm. Check your lockfiles now, remove compromised versions completely, pin to clean versions and, if you have any suspicion, consistently rotate all credentials. Don't forget the 72-hour notification deadline under the GDPR, in case personal data could be affected.
If you are unsure whether and to what extent your company is affected, seek professional support early. In an incident of this category, every hour counts – and a swift, structured approach decides whether a security incident becomes a total loss.