Your website didn't get hacked. Its supplier did.

Picture a bakery that buys its flour from a trusted supplier, the same one it's used for years. One week, without anyone noticing, that supplier's flour mill gets contaminated. The bakery didn't change a thing. They followed every food safety rule they always have. And the bread still came out wrong, because the problem never started in their kitchen.

That's roughly what happened on the internet this month, except the flour was code, and the bakeries were thousands of websites and apps that had no idea anything was wrong.

What actually happened

Most modern websites and apps aren't built entirely from scratch. Developers pull in small, pre-written pieces of code — called packages — to handle things like formatting dates, processing payments, or rendering a button. It's normal, efficient, and almost universal. A single website can quietly depend on hundreds of these packages, most of them written by people the site owner has never met and will never think about.

This month, attackers found a way into the pipeline that builds and publishes some of these packages — not by stealing a password, but by compromising the automated system that ships the code in the first place. That's an important distinction. It means the malicious code went out through the normal, trusted channel, with nothing about it looking unusual to the people downloading it. Thirty-two packages, across roughly ninety-six versions, were affected before it was caught.

No developer using those packages did anything wrong. They updated their dependencies the way they're supposed to. The compromise happened upstream, in a place none of them could see, let alone review.

It's the digital version of a contaminated ingredient slipping into a product through the supply chain — not through anyone's carelessness in the kitchen.

Why this matters even if you've never written a line of code.

You don't need to understand package managers or build pipelines for this to be relevant to you. If your business has a website, an app, or even an online store built on a modern platform, there's a very good chance some part of it depends, somewhere down the chain, on exactly this kind of shared code. You're not exposed because you did something risky. You're exposed because almost everyone builds this way now, and the convenience that makes modern websites fast to build is the same convenience that makes this kind of attack so effective.

This is also why "I'll just be more careful" doesn't fully solve the problem. Being careful protects you from clicking a bad link or reusing a weak password. It doesn't protect you from a supplier three layers removed from you having a bad week.

What you can actually do about a risk you can't see

The honest answer is that you, personally, checking every dependency your website relies on isn't realistic — and it isn't supposed to be your job. But there are a few things that genuinely reduce your exposure:

If you're on a managed platform like Wix, a meaningful part of this risk sits with the platform rather than with you — they're the ones responsible for vetting what runs underneath their apps and features. That's one real advantage of not self-hosting custom infrastructure you'd have to monitor yourself.

If you have custom code, a developer, or a contractor maintaining something bespoke for you, ask a simple question: how quickly would you find out if one of the third-party tools we depend on was compromised? "We'd see it in the news eventually" is a different answer than "we have alerts set up for exactly this."

And the backup conversation comes up again here, because it always does: if something upstream does go wrong and affects your site or your data, having a clean, recent copy to restore from turns a crisis into an inconvenience.

The uncomfortable trend underneath this

This isn't a one-off story. Attacks aimed at the supply chain behind software — rather than the software's end users directly — have been increasing because they're efficient. Compromise one widely-used piece of shared code, and you potentially reach thousands of downstream targets at once, without ever attacking any of them directly. It's a higher-leverage move than going after one website at a time, and attackers have noticed.

You don't need to lose sleep over packages you'll never see the names of. You do need to know that "we didn't do anything wrong" and "we weren't affected" aren't the same statement anymore — and that having a quick way to check, and a backup plan if the answer is uncomfortable, matters more than it used to.