In an incident that has echoes of the infamous left-pad incident of March 2016—where an open-source maintainer un-published a widely-used NPM package, causing massive disruptions to development workflows and CI/CD pipelines—the NPM package stylus was effectively marked malicious (GHSA-fh4q-jc76-r59p, withdrawn) for a time on July 23, 2025. Fortunately, many organizations have processes and toolchains that reflect lessons form the left-pad incident and were not significantly impacted. But there were still significant disruptions to other open-source projects and workflows that necessarily rely on the public NPM repository.
We followed this development as it was evolving, but what happened? Why? What lessons can developers, security, and operations take from this?
Breakdown of The NPM Stylus Outage
GHSA advisory published flagging ‘stylus’ as malware – this happened because a maintainer account associated with the stylus package published a different, unrelated malicious package. That led to the account being banned and all associated packages — including stylus — being marked as malicious. It’s unclear whether this was an automated action or was taken by a human operator.
NPM generated a 0.0.1-security version of stylus in response, effectively removing stylus from its catalog while holding the namespace to prevent it being used by an opportunistic attacker. For all intents and purposes, stylus was removed
Builds relying on NPM as a package database started breaking, resulting in a developer-facing outage for any organization that relies on using packages directly from NPM, and generating complaints on various forums.
The stylus maintainer team was able to restore service by working with GitHub and NPM to verify that there was never malicious code in the stylus package, after a social media push to bring attention to the problem.
This outage lasted about 12 hours; during that time countless hours were lost as developers relying on NPM to provide stylus, or who blocked the package due to the erroneous malicious content report, were unable to conduct builds. It also provided a window of opportunity for malicious actors to suggest suspicious “workarounds” for stylus being unavailable; fortunately, no major campaign of this sort appears to have been fielded, and to date we don’t have any validated reports of anyone being targeted in this way.
Checkmarx Zero’s supply chain security team was alerted to the malware report shortly after it was made, and we began our own investigation. We concluded that there was no evidence of malicious activity in stylus and ensured that our Malware Protection database correctly reported it as free of known malware.
Zero Research Updates. Subscribe today!
Lessons From The NPM Stylus Incident
Developers and AppSec leaders and practitioners should learn some important lessons from the stylus outage:
Use and manage private package caches
Organizations that set up their own package repositories and configured them to cache packages from NPM either had no outage or had a much shorter one. This configuration allows a lot more control over what packages are available to developers. Even in a permissive configuration — one which automatically adds any requested NPM package versions to the cache for developers to use — organizations can quickly act to remove or block unwanted package versions or retain packages they use internally even if they’re removed from NPM. When stylus was blocked, those organizations were able to analyze the risk and decide to restore their own cached version, getting developers back on track testing and deploying application changes.
Of course, this has a downside too, as it means an organization might fail to block a malicious package as quickly as NPM does. Configuring private package repositories to cache NPM has to be done thoughtfully to ensure that the risks are managed in accordance with the organization’s security posture. But that’s the point: it gives organizations control about what packaging decisions to trust instead of ceding it entirely to NPM or individual package maintainers.
Responsive, knowledgeable security teams matter
Organizations that employ Application Security professionals who can read and understand JavaScript and its related ecosystems were able to quickly review whether the stylus package actually posed risk and have meaningful conversations with developers and DevOps teams about making a response plan. In this case, those organizations rapidly determined that the report of stylus being malicious was incorrect and were able to be good partners in getting their developers quickly unblocked.
Malware reporting has a big impact
Sometimes it takes a mistake to highlight the value of a security activity. The fact that NPM responded quickly to a credible security advisory that claimed stylus was malicious highlights how effective malware reporting can be, and how valuable it is for security researchers to make prompt reports when they discover serious issues. On the flip side, it also highlights the importance of verification prior to reporting issues. Extra care should be taken to insure that reports of malicious content and other critical security issues are accurate and correctly identify both the problem and its proper scope.
What we find and report matters a lot! And that means it’s extremely important to do our best to get it right.