Your Website Runs on Code Nobody at Your Company Wrote. In 2026, That's a Problem.

On March 31, 2026, for about three hours, one of the most popular pieces of code on the internet turned into malware. Axios — a library that handles web requests inside an estimated 174,000 other packages and roughly 100 million downloads a week — was hijacked through a compromised maintainer account. Anyone who installed it during that window got a working remote-access trojan bundled in for free, silently, with no warning, no popup, nothing that looked different from a normal software update.

Google later attributed the attack to a financially motivated North Korean hacking group. It wasn't the only incident. It wasn't even close to the biggest one this year.

If you run a business with a website, an app, or any piece of custom software, there's something important to understand: you almost certainly didn't write most of the code your site runs on. A typical modern web app is built from dozens or hundreds of small, pre-written building blocks — called packages or dependencies — pulled from a public library called npm. Your developer wrote the parts specific to your business. Everything else — handling logins, formatting dates, sending network requests, processing payments — is borrowed code, written and maintained by strangers, often unpaid volunteers, all over the world.

That system is why software gets built fast and cheap. In 2026, it's also become the single most attacked part of the internet that almost no business owner has heard of.

What a "Supply Chain Attack" Actually Is

A regular hack targets you directly — someone tries your password, finds a hole in your server, tricks an employee into clicking a link. A supply chain attack skips you entirely. Instead, the attacker breaks into a piece of software that thousands of companies already trust and use, and lets that trust do the work. One poisoned building block, installed automatically by developers everywhere who have no reason to suspect it, and the attacker inherits access to every business built on top of it — instantly, at scale, with a single break-in.

Security researchers at Sonatype tracked more than 454,600 new malicious open-source packages published in 2025 alone, pushing the total ever blocked past 1.2 million — a 75% jump from the year before. 2026 has kept that pace. This isn't a rare, freak event. It's become a routine, industrialized part of how modern web software gets attacked.

The 2026 Timeline (So Far)

Laid out plainly, the frequency is what should give any business owner pause:

• March 31 — Axios. A compromised maintainer account pushed malware into one of the most-used JavaScript libraries in existence, reaching an estimated 174,000 downstream packages before it was caught roughly three hours later.
• May 14 — node-ipc. A foundational communication library with over 10 million weekly downloads shipped three simultaneous malicious versions, each carrying a credential-stealing payload.
• May 28–29 — Two separate campaigns in the same week. One impersonated internal corporate software packages at real companies to trick developers into installing malware by mistake. Another published 14 fake packages designed to steal cloud and CI/CD credentials specifically.
• June 1 — A Red Hat namespace. Attackers compromised an employee's account and pushed malicious code through legitimate, verified build pipelines — meaning the packages carried valid authenticity certificates while secretly containing malware.
• June — A new worm variant. Snyk tracked a self-propagating attack across 57 packages that hid its trigger somewhere almost no security tool checks — a build configuration file rather than the usual install script — specifically to dodge detection.

Researchers now describe several of these as part of an evolving worm family that automatically steals developer credentials and uses them to infect further packages on its own, without further human input from the attacker. It spreads the way a biological worm does: quietly, automatically, and faster than anyone is watching.

Why This Matters to You, Specifically — Not Just "Developers"

Here's the part that rarely gets said plainly: if your website was built in the last few years using any modern framework, it almost certainly depends, directly or indirectly, on packages that have been targeted in an attack like this. You don't need to have done anything wrong. Your developer doesn't need to have made a mistake. A dependency you've never heard of, three or four layers deep in a list neither of you ever reads, can be the door.

The consequences aren't abstract. Depending on the attack, a compromised dependency can silently steal customer data, harvest login credentials for your hosting or cloud accounts, or use your website as a launchpad to attack your customers directly. And because the malicious code often looks identical to normal code — sometimes even carrying valid, legitimate-looking security certificates, as in the Red Hat incident — it can sit undetected for a long time.

What We Actually Do About This, Building Client Sites

We build web and SaaS products for a living at Taylance Tech, which means every project we ship carries this exact exposure. A few things we've learned matter more in practice than in theory:

Version pinning beats blind trust. Many of 2026's incidents specifically exploited projects that auto-update to "whatever the latest version is." A project with dependencies locked to specific, reviewed versions doesn't silently pull in a malicious update the moment it's published — it gives you a deliberate window to update on your own schedule, not the attacker's.

Disabling automatic install scripts closes a real door. A large share of 2026's attacks — including the node-gyp worm — execute automatically the moment a package is installed, before anyone has looked at what it does. Turning that automatic execution off, and only allowing it deliberately, is one of the single highest-value security defaults a project can have, and it's often simply not turned on by default.

"It has millions of downloads" is not a safety signal anymore. Axios has 100 million weekly downloads and was still compromised. Popularity means a package is convenient and well-documented. It does not mean anyone is actively re-verifying every release. Assuming otherwise is exactly the assumption 2026's attackers have been exploiting.

Five Questions Worth Asking Your Developer or Agency

You don't need to become a security expert to protect your business. You need to know these five questions are being answered "yes":

1. Are our project's dependencies pinned to specific versions, rather than set to auto-update to "latest"?
2. Are automatic install scripts disabled for third-party packages by default?
3. Do we run any automated scanning that flags newly known-malicious packages before they reach production?
4. Are the credentials our project depends on — cloud accounts, deploy keys, API tokens — rotated regularly, and do we know exactly what would be exposed if one leaked?
5. If a dependency we use were compromised tomorrow, how would we find out, and how fast?

If any of these gets a shrug instead of a clear answer, that's worth addressing before it's a problem instead of after.

The Bottom Line

Nobody needs to panic about this — the vast majority of the internet's software runs on this same borrowed-code model, every day, without incident. But 2026 has made one thing clear: supply chain attacks are no longer a rare edge case discussed only in security conference talks. They're a routine, recurring, increasingly sophisticated part of the threat landscape, and the businesses least prepared for them are the ones who've never had the conversation at all.

If you're not sure how your website or app would answer the five questions above, that's a conversation worth having before an incident forces it. Reach out and we'll walk through your specific setup — no obligation, and if everything checks out, we'll tell you that too.

Frequently Asked Questions

What is a supply chain attack in software?

A supply chain attack compromises a shared, trusted component — such as a code package, build tool, or software update — rather than attacking a target directly. Because thousands of businesses rely on the same shared components, one successful attack can silently spread to every company using that component, without the attacker ever targeting them individually.

Was my website affected by the 2026 npm attacks?

It's possible, especially if your site was built with modern JavaScript frameworks and hasn't had a dependency security review recently. The safest step is asking your developer or agency directly whether your project used any of the affected packages during the windows they were compromised, and whether dependency scanning is in place going forward.

What is npm and why does it matter for security?

npm is the primary public library that JavaScript developers use to share and reuse pre-written code, and it powers the majority of modern websites and web apps. Its scale — millions of packages, billions of downloads — is exactly what makes it valuable to attackers: compromising one popular package can reach hundreds of thousands of projects at once.

How can a small business protect itself from supply chain attacks?

The most effective steps don't require an in-house security team: pinning software dependencies to specific, reviewed versions instead of always using "the latest," disabling automatic script execution during package installation, using automated tools that flag newly-discovered malicious packages, and rotating cloud and API credentials regularly. Asking a developer or agency directly whether these practices are in place is a reasonable and increasingly necessary question.

Are these attacks getting worse?

Yes, by volume and sophistication. Security researchers tracked over 454,600 new malicious open-source packages in 2025, a 75% increase year over year, and 2026 has already included attacks attributed to state-sponsored groups as well as self-propagating "worm" campaigns that spread automatically without further attacker involvement.