What a software supply chain attack means for your Statamic website

These packages have always been a target for supply chain attacks, but an increasing amount of software supply chain attacks are targeting open-source ecosystems, like NPM and Composer.

A software supply chain attack does not target your website directly.

Instead it poisons one of the building blocks your relies on, a package or library written by someone else, and rides that trusted code straight into your site.

When whoever maintains your site installs a routine update, if a package has been compromised, the malicious code comes along for free.

That is what makes these attacks effective. Nobody has been careless. Keeping a site's software up to date is the normal, sensible thing to do. The attack hides inside the exact habit that is supposed to keep a site safe.

What a software supply chain attack actually is

Almost no modern website is built entirely from scratch. Yours is assembled from hundreds of open-source packages: the framework, the build tools, the bits that handle dates, HTTP requests, image processing, and so on.

An attacker who compromises just one of those packages has the potential to reach many websites that depend on a package. They do not need to break into your server. They wait for the poisoned package to be pulled in during a routine update.

By default, Statamic is a flat-file CMS, content lives in files rather than a database. That removes a whole class of database-driven risk, which is genuinely good.

But the code that runs Statamic does not escape this. It sits on Laravel, pulls in Composer packages on the back end, and npm packages for the front-end build. Every one of those is a link in your supply chain.

Your Statamic site might be flat-file, but the code that runs it is still assembled from hundreds of packages you did not write.

Two recent attacks worth knowing about

In March 2026, an npm attack hit Axios, one of the most popular packages on the internet. Axios is downloaded around 100 million times a week. A compromise at that scale does not stay contained; it ripples out to a huge slice of the web almost instantly. I wrote up exactly what happened and what it meant in a separate post.

Then there is Shai-Hulud, a self-spreading worm that has been working through the npm ecosystem since late 2025. It does not just sit in one package. Once it lands on a developer machine it harvests credentials and tokens, then uses them to publish itself into more packages automatically. It has hit more than 700 packages, including ones from CrowdStrike, Zapier, PostHog, and Postman, and fresh variants keep appearing into 2026.

Neither attack required anyone to do anything wrong. They spread through trust and routine updates, which is the whole point.

AI is now finding the bugs, on both sides

The latest wrinkle is artificial intelligence. AI is very good at reading large amounts of code and spotting flaws that humans miss.

Anthropic recently ran their tool called Mythos across open-source software and it surfaced thousands of previously unknown vulnerabilities, including a 27-year-old bug in OpenBSD, a system famous for being hardened. Flaws that survived decades of human review fell over in weeks.

That cuts both ways. In the wrong hands, the same capability lets attackers dig old, dormant bugs out of the packages your site may depend on and build working exploits faster than ever. The barrier to pulling off a sophisticated attack just dropped.

The reassuring half is that defenders get the exact same tools. Anthropic released Mythos to a limited set of partners specifically to give the industry time to find and patch these bugs first.

The same AI that can expose a weakness can scan your dependencies, flag the risky ones, and help close the gap before anyone exploits it. It is an arms race, but defence is in the race too.

What this means for your site

There is no opting out of dependencies; nobody builds a commercial website without them. What matters is that whoever looks after your site stays current, watches for compromised packages, and holds off on brand-new releases until they have proven safe, which is exactly when poisoned versions do the most damage.

That is steady, unglamorous work, and it is easy to let slide until something breaks. Keeping dependencies patched, monitored, and defended is a core part of my regular maintenance work, so a story like Axios or Shai-Hulud is something I am already watching for, not something you have to find out about the hard way.

A software supply chain attack is not a reason to panic about open source. It is a reason to make sure the code your website is built from is looked after as carefully as the site you can actually see.