Many malware attacks against open-source software components have compromised thousands of software packages and repositories, but the practical damage these attacks have caused organizations is harder to quantify. The longer-term and indirect costs of these attacks may prove most significant for organizations. Open-source components and software have long been a well-established source of threat activity. The widespread use, combined with the broad variance in how well-supported different projects are, in part thanks to the community maintenance inherent to many of them, means severe vulnerabilities (and threat campaigns) can sometimes slip through the cracks. The devastating Log4Shell vulnerability from 2021 comes to mind, as does the more recent React2Shell from late last year.[1]
In recent months, a new supply chain threat has emerged against the open-source community; attackers are unleashing self-propagating malware on component libraries and targeting downstream victims with infostealers. The most famous recent example of this is Shai-hulud, a worm targeting NPM projects that would take hold when a victim downloads a poisoned component. Once on a victim machine, the malware used its access to infect components the victim maintains, then self-publishes poisoned versions. Downstream victims would face the same fate. The Shai-hulud worm had multiple successors that stole credentials and impacted a wide range of users.
See: https://redskyalliance.org/xindustry/five-cyber-threats-that-defined-security-in-2025
Another well-known supply chain threat is GlassWorm, which is technically neither a worm nor self-propagating. However, it has targeted swaths of developer credentials since last fall. When a developer downloads a poisoned Open VSX component, GlassWorm then steals credentials and cryptocurrency wallets. The attacker can manually use their access to compromised developer accounts to publish malicious versions and spread further infections.
The scope of the damage from these attacks remains unclear. An early supply chain attack in this wave against developer Qix saw 18 popular NPM components poisoned, which in total were downloaded more than 2 billion times each week. Defenders acted quickly, and the attack fizzled out, but various Shai-hulud waves saw hundreds of software packages and thousands of repositories poisoned for a period.
Omer Kidron, enterprise security consultant at cyber readiness and incident response firm Sygnia, points out that download numbers aren't everything. "The hype around supply chain incidents often focuses on raw download numbers, but a realistic view of damage is about impact inside the affected organization: what was executed, where it was executed, and what it exposed," Kidron says. "A malicious package downloaded a million times does not mean a million companies were compromised, but it does signal potential distribution into many building and developer environments."
Darren Meyer, security research advocate at Checkmarx Zero, tells Dark Reading that many attacks from these large-scale campaigns were either stopped or quickly mitigated. The attacks against Chalk and other components stemming from the compromise of developer Qix, for example, were rapidly contained thanks to the maintainer's quick response and transparent communication with the community. Shai-hulud, meanwhile, was impactful but contained relatively quickly because NPM, GitHub, and others worked to stop the spread.
Harm and cost are not always measured in direct compromise, however. Meyer says Checkmarx assesses harm and cost in three ways. The first is primary harm, where there's a direct, significant compromise. This happens but is rare at scale, partially because of clumsy attackers (the Qix attack is an example, he says) and partially because of defenders' rapid response. Secondary harm, where the damage is low but developers must spend time and resources to clean up, is more common. And indirect harm, where employees must spend resources defending against emerging threats, whether they're vulnerable or not, is even more common.
"When there is known malicious content, organizations still have to engage in some level of incident response. At minimum, security teams must assess the risk posed to their organization, both by trying to understand the threat itself, and by investigating whether there is evidence of impact to their organization," he says. "This response effort is expensive, not only because of the actual time and money invested by responders, but because of the disruption it causes to the organization."
Christopher Jess, senior R&D manager at application security vendor Black Duck, calls this the costly verification tax. "Even when an incident is caught quickly, engineering and security teams still must answer uncomfortable questions fast: 'Were we exposed? Which pipelines pulled it? Which developer endpoints installed it? Which credentials might be at risk? That drives emergency triage, hunting across logs, re-running builds, validating artifacts, rotating credentials, and sometimes rebuilding trust in release processes," Jess writes in an email. "Because these campaigns target the developer tool chain, the potential blast radius is outsized, including source access, signing keys, cloud credentials, and the ability to taint downstream releases."
Another consideration is long-term, lasting damage from these incidents. Sygnia's Kidron explains that the impact of a compromise like credential theft occurs over a longer time scale. If the issue has not been adequately contained, attackers can sell access or use it for follow-on activity later. "In practice, damage unfolds across time frames. Immediately within hours to the first few days after exposure, the primary risk is credential exposure: these campaigns are designed to execute inside developer and CI/CD paths where tokens and secrets are accessible," he says. "When those secrets leak, the downstream harm is not abstract; the attacker can use them (or sell them) to authenticate as the victim and access private repositories, pull data, tamper with code, trigger builds, publish packages, access cloud resources, or perform actions “on behalf” of legitimate identities."
The containment process, as mentioned, can then take weeks to address, even if the primary damage was minor. This can, and frequently does, delay other planned deliverables and releases. While many supply chain attacks are rapidly stopped thanks to community detection, registry takedowns, and improved scanning, Jess says, these incidents act as a reminder that acting fast matters, whether it's rotating credentials after a breach or checking for indicators of compromise (IOCs) in an ongoing campaign.
"The takeaway for leaders is to enforce the best practices developed over decades," Jess writes in an email. "Don't blindly trust open-source code, reduce what an install/build can access, prefer short-lived/least-privilege credentials, tighten package/extension controls (allowlisting and internal mirrors), and add continuous monitoring so you can prove impact rapidly."
This article is shared at no charge for educational and informational purposes only.
Red Sky Alliance is a Cyber Threat Analysis and Intelligence Service organization. We provide indicators-of-compromise information via a notification service (RedXray) or an analysis service (CTAC). For questions, comments, or assistance, please contact the office directly at 1-844-492-7225 or feedback@redskyalliance.com
- Reporting: https://www.redskyalliance.org/
- Website: https://www.redskyalliance.com/
- LinkedIn: https://www.linkedin.com/company/64265941
Weekly Cyber Intelligence Briefings:
REDSHORTS - Weekly Cyber Intelligence Briefings
https://register.gotowebinar.com/register/520742825132167612
[1] https://www.darkreading.com/application-security/shai-hulud-hidden-cost-supply-chain-attacks
Comments