On September 8, 2025, part of the software packages in the world’s largest repository, npm, was compromised. The attackers gained access in the most ordinary way: a targeted phishing attack successfully broke into the account of a respected contributor. The security community quickly uncovered the attack, which kept the consequences minimal. But for a brief moment, the digital supply chain that underpins the entire software ecosystem turned against business.
The attackers focused on maintainers of popular packages. One of them received a phishing email from a fake domain, which at first glance looked like an official request to update two-factor authentication. He fell for it, and the attackers gained access to his account. They then inserted malicious code into 18 well-known packages.
These libraries see billions of downloads each month and form the foundation of thousands of other projects, which dramatically increased the potential impact. The malware was designed to target crypto wallets: it intercepted web API calls and changed wallet addresses so that money meant for users or businesses was redirected to the attackers.
The spread was fast and massive. Automated CI/CD pipelines pulled the infected versions into tens of thousands of builds Vercel confirmedthat more than 70 teams had already integrated the malicious versions before the problem was spotted. Within hours of the first distribution, warnings began to circulate, and the maintainer known as Junon deleted nearly all of the compromised packages. The repository admin blocked his account, but later the same day it was restored and the packages were cleaned of malicious code. Financial losses were estimated at around USD 970 — a trivial sum compared to what might have happened if the attack had lasted longer.
As a direct response to the npm incident, GitHub announcedthat it will strengthen authentication and publishing processes. For local publishing, it will require two-factor authentication (2FA) and short-lived granular tokens valid for only seven days. At the same time, it is introducing mandatory trusted publishing directly from CI/CD pipelines using OpenID Connect (OIDC).
You’re Only as Strong as Your Weakest Supplier
When the software supply chain is breached, the consequences don’t stop at financial losses or stolen crypto wallets. The real problem is that attackers gain access directly to the base code relied upon by countless companies and end users — from communications and manufacturing to logistics, transport, and service delivery. Your product or service could be weaponized in an attack without you even realizing it.
Compromised code often ends up on darknet forums, for example in China or Russia, where it becomes a “product for rent” for other criminals to use in phishing campaigns, data theft, or ransomware. At that point, your reputation no longer matters — your code has become part of the cybercrime ecosystem, traded like a commodity.
The legal and regulatory risks are also significant. If it turns out your product shipped with compromised code and attackers used it to access personal data, you could face fines under GDPR or similar laws. In practice, this means not only financial penalties but also long-term loss of trust from clients and partners.
The npm attack highlights an uncomfortable truth: institutions and companies are only as secure as their weakest supplier. This holds true even for suppliers buried deep within your software. Supply chain compromises bring several major risks:
- Reputačné riziko – If your app contains compromised code, customers won’t care that it “wasn’t your fault.” They see your brand as endangering their money or data. And reputation can vanish in seconds.
- Regulačné riziko, – In the EU, for example, the Cyber Resilience Act makes it clear that companies must know and control what’s inside their software.
- Finančné riziko, – Attacks can directly reroute customer funds. Even if direct losses are small, the costs of legal disputes and incident response can be huge.
- Prevádzkové riziko – CI/CD pipelines are great for speed, but if malicious code enters the chain, it spreads within hours, not days.
Improving Security Isn’t Rocket Science
At Binary Confidence, we face these risks daily across industries. Our mix of SOC monitoring, GRC services, and CISO advisory is designed to help companies not just during incidents, but also in building resilience beforehand. Supply chain attacks can be mitigated in several ways, and proven practices exist that significantly reduce risk:
The “minimum release day” rule
Attackers often strike right after updates are published. Many teams have CI/CD set to update immediately after release. Adding even a short delay before deploying new versions gives the community and security teams time to spot malicious code.
Avoiding the very latest version by default
For routine maintenance, it’s often safer to stay 1–2 versions behind and deploy those already tested by time — unless a high-severity vulnerability forces immediate action. The key is to monitor security channels, mailing lists, and CVE databases so you know when to wait and when to act.
Verifying suppliers and packages
Beyond delaying releases, it’s critical to check where packages come from and whether they’re maintained by trusted contributors. Automated tools can monitor integrity and reputation, but best practice combines these with in-house monitoring and SOC oversight.
If you suspect your systems have been targeted or you want to proactively strengthen your cyber defenses, reach out to us. We know who we’re dealing with. And we know how to fight back. We were the first company in Slovakia to provide SOC services, and we’ve been actively protecting against cyber threats for years. We monitor hacker groups closely, stay connected to intelligence databases and analysis networks, and follow channels that help uncover cybercriminals.
The project funded through grant agreement number 101145856 is supported by the European Cybersecurity Competence Centre.
