The 7 Biggest Supply Chain Attacks of 2026

Sometime after December 2025, a payment processor became a hiding spot for the exact theft it exists to prevent.

A skimmer discovered on Magento and Adobe Commerce checkout pages doesn’t reach out to a suspicious domain the way malware is supposed to. It hides the payload inside a customer record stored in the attacker’s own Stripe account, pulls it out through a Google Tag Manager container, the same mechanism marketing teams use to add tracking scripts without touching site code, and sends stolen card data right back out through that identical channel. Stripe sells the infrastructure the entire internet trusts to move money safely. It became the dead drop instead.

That’s not a coincidence. It’s the cleanest illustration available of the argument this entire list is making: in 2026, the attack almost never comes through the front door. It comes through the door you didn’t know you’d propped open, a package, an SDK, a CDN-hosted script, a payment processor’s own API, something you or your vendor already decided to trust. Software Supply Chain Failures now sits at number 3 on OWASP’s proposed 2025 Top 10, the first time the category has cracked the top tier, and it earned that ranking by showing up in exactly the kind of incident nobody budgets for.

7. The PayPal Working Capital Data Exposure

Date: Active July 1 – December 13, 2025; disclosed February 2026
Vector: Undetected coding flaw, not a third-party compromise
Impact: Customer PII and SSNs exposed for nearly six months

This one is the odd entry on the list, and it belongs here anyway.

A coding flaw introduced during an update to PayPal’s Working Capital loan app went undetected for close to six months. Exposed data included names, emails, phone numbers, business addresses, dates of birth, and in some cases Social Security numbers. A limited number of accounts saw unauthorized transactions, which PayPal reimbursed, and affected users got password resets and two years of credit monitoring.

There was no compromised vendor here, no poisoned package. That’s exactly why it’s instructive. PayPal’s prevention controls didn’t fail loudly. They failed quietly, and nothing was watching runtime behavior closely enough to catch the gap for half a year.

Why it matters: A supply chain attack and a silent runtime exposure produce the same blind spot: unauthorized access to data, no malware signature, no noisy exploitation, just anomalous behavior blending into normal traffic until someone finally looks.

What it exposed: Prevention and detection are not the same investment, and most organizations have only really built the first one.

Read our full breakdown: PayPal Data Breach 2026: What Happened & What It Means for Web Security

6. The AppsFlyer SDK Crypto Wallet Swap

Date: March 9–11, 2026
Vector: CDN-hosted SDK modified at the source
Impact: Present in 100,000+ web and mobile applications; 48-hour compromise window

For 48 hours, one of the most widely embedded analytics libraries on the internet was quietly rewritten on AppsFlyer’s own CDN to steal cryptocurrency.

The AppsFlyer Web SDK, not the mobile SDK, was modified to intercept crypto wallet addresses entered by end users and silently swap them for attacker-controlled ones, while exfiltrating page URLs, timestamps, and user agents in the background. The script kept performing its legitimate analytics job the entire time, which is what made it almost invisible. Nothing about it looked broken, because nothing was.

No perimeter defense could have caught this. The SDK was already allowlisted everywhere it ran. Signature-based detection had nothing to match, because the payload was novel. Subresource Integrity checks were irrelevant, because the file was modified at its authoritative source, not intercepted in transit. The “clean” version and the “malicious” version were the same URL.

Why it matters: Any organization letting users enter payment or wallet data through a page loading third-party SDKs inherited this exposure the moment the CDN was compromised, whether or not they’d ever heard of the incident.

What it exposed: Trust in a source, not a signature, was the entire control most sites relied on. Once that source turned, every control built around “is this domain allowed?” had nothing left to check.

Read our full breakdown: AppsFlyer SDK Exploited in New Supply Chain Crypto Attack

5. The Trivy CanisterWorm Attack

Date: 2026
Vector: Self-propagating npm worm using blockchain-based C2
Impact: 47 npm packages compromised, thousands of downloads affected

There’s a particular irony here too: the compromised tool was Trivy, one of the most widely used open-source vulnerability scanners in the industry. A campaign researchers dubbed CanisterWorm didn’t just poison a single dependency. It used stolen credentials and automated publishing to infect multiple packages, establishing persistence and expanding automatically across the npm ecosystem, no human attacker required after the initial foothold.

The technical novelty is worth sitting with. CanisterWorm used an ICP canister, a tamperproof smart contract running on the Internet Computer blockchain, as its command-and-control server. Because the attacker can swap the C2 URL directly inside the canister, the infrastructure is effectively resistant to conventional takedown. It’s the first publicly documented malware to operate this way.

Why it matters: Self-propagating attacks change the economics of defense. When malware spreads automatically across packages and maintainers without ongoing human input, detection windows shrink and blast radius grows faster than any manual response can keep pace with, and now the takedown itself is harder too.

What it exposed: A package can pass every scan at ingestion and still be updated or triggered remotely after deployment. SBOMs and dependency scanning stop at the point of entry. They don’t answer what’s actually executing in a browser or a build process right now.

Read our full breakdown: The Trivy Supply Chain Attack and the Visibility Gap

4. Shai-Hulud 2.0

Date: November 21–25, 2025 (technically late 2025, included here because everything after it in 2026 traces back to it)
Vector: Self-propagating npm worm, preinstall execution, fake Bun runtime disguise
Impact: 25,000+ GitHub repositories, hundreds of maintainers, 100M+ combined monthly downloads across infected packages

Worth being upfront about this one: it launched two months before 2026 started. It’s on this list anyway, because the stolen credentials from this exact campaign are what made the Trust Wallet hack further down this list possible, and its techniques, preinstall execution, fake runtime disguise, self-healing propagation, were echoed and escalated across nearly every major campaign that followed it into the new year.

The first Shai-Hulud wave, in September 2025, was already one of the most advanced npm supply chain attacks on record. The second wave, launched November 21, was an escalation on every axis that mattered. Infection moved from postinstall to preinstall, executing before dependencies even finished resolving. The worm disguised its activity behind a fake Bun runtime so its process names looked benign in logs. Stolen secrets were triple-Base64-encoded to slip past pattern-matching scanners. Compromised machines were silently registered as self-hosted GitHub Actions runners to establish persistence, and if exfiltration or propagation failed, the fallback was to wipe the victim’s home directory outright.

The targeting wasn’t random. Attackers went after maintainers with broad publishing rights, Zapier, ENS Domains, PostHog, Postman, and hundreds of others, because compromising one such account could poison dozens of high-trust packages in a single move. New infections appeared every 30 to 40 minutes at the campaign’s peak.

Why it matters: This wasn’t stealthy credential theft anymore. It was a worm willing to sabotage a machine outright the moment its primary objective was blocked, spreading through the exact trust relationships that make open-source software work at all.

What it exposed: Traditional software composition analysis is built to catch known vulnerabilities at the point of ingestion. It was never built to catch a package that behaves perfectly at scan time and only turns malicious after it’s already running in production.

Read our full breakdown: Shai-Hulud 2.0: The Worm Returns

3. The Stripe-Hosted Skimmer

Date: Active since at least December 2025; publicly documented mid-2026
Vector: Malicious code hidden inside Stripe API metadata, delivered via Google Tag Manager
Impact: Checkout pages on Magento and Adobe Commerce stores, running for months undetected

This is Magecart evolved past the point where allowlists can help you.

Instead of reaching out to a suspicious domain, this skimmer hides inside two services almost every e-commerce store treats as unconditionally safe: Stripe and Google Tag Manager. A GTM container pulls a hidden payload out of a customer record stored in the attacker’s own Stripe account and runs it in the shopper’s browser at checkout. It captures card number, expiration, CVV, name, billing address, email, and phone number, scrambles the data, and parks it in local storage. A separate routine checks for stolen data every 60 seconds and smuggles it out by creating fake customer records inside that same Stripe account. A second version does the identical trick through Google Firestore.

The design choice is the whole attack. Both api.stripe.com and Google Tag Manager are domains every serious e-commerce site has to allow. CSPs and allowlists work by blocking traffic you haven’t approved, and there’s nothing here to flag, because the traffic is going exactly where it’s supposed to go.

Why it matters: This is precisely the blind spot PCI DSS 4.0.1’s requirements 6.4.3 and 11.6.1 were written for: an inventory of every script on a payment page, and a way to detect unauthorized change, for scripts you wrote and scripts you didn’t.

What it exposed: The question was never “where is this traffic going.” A trusted domain always passes that test. The question that actually catches this is “what is this script doing right now, regardless of where it’s hosted.”

Read our full breakdown: The Stripe-Hosted Skimmer Explained

2. The Trust Wallet Chrome Extension Hack

Date: December 24–26, 2025
Vector: Trojanized Chrome extension update, published using credentials stolen via Shai-Hulud
Impact: $8.5 million stolen from roughly 2,500 wallets

This is where Shai-Hulud stopped being an npm story and became a headline about real money disappearing from real accounts.

During the Shai-Hulud campaign above, attackers swept up GitHub secrets and Chrome Web Store API keys belonging to the Trust Wallet project. That access was enough. On December 24, 2025, a new version of the Trust Wallet Chrome extension, v2.68, appeared in the Chrome Web Store, published with valid, stolen, legitimate-looking credentials. No phishing link. No suspicious prompt. It looked exactly like an authorized update, because as far as the Chrome Web Store could tell, it was one.

The trojanized version silently captured wallet seed phrases the moment a user unlocked their wallet. There’s no password reset for a crypto wallet. The seed phrase is the wallet. Within hours, attackers had recreated thousands of users’ wallets elsewhere and drained them. By the time Trust Wallet’s team confirmed the malicious release and pushed a clean patch, $8.5 million was already gone.

Why it matters: Most businesses will never ship a crypto wallet through a Chrome extension, but nearly all of them run analytics tools, support widgets, and partner-built extensions with the same elevated browser privileges. The mechanics are identical whether what’s harvested is a seed phrase, an auth token, or a session cookie.

What it exposed: A compromised extension pushed through an official store bypasses every instinct users are trained to rely on. The only thing that can catch it is watching what the code actually does once it’s running.

Read our full breakdown: $8.5 Million Shai Hulud Trust Wallet Crypto Hack

1. The ATMZOW Skimmer

Date: Active since 2015; current variant documented 2026
Vector: Malicious script hidden inside a Google Tag Manager container
Impact: Checkout pages compromised for over a decade; 40 rotating exfiltration domains in the current campaign

We’re closing on this one, not opening on it, because it deserves the last word.

Magecart has run the same play since 2015: hide the skimmer inside a Google Tag Manager container, because googletagmanager.com is a domain almost every checkout page on earth is configured to trust. The current variant, tracked as GTM-TVKQ79ZS, ties its decoder to the exact character length of the script, so reformatting it during automated analysis breaks it outright. Exfiltration rotates across 40 newly registered domains, two at a time, cached per victim in localStorage, hidden behind Cloudflare. When Google takes a malicious container down, a replacement is live within hours. Judged purely by how new the technique is, this is the oldest incident on this list.

Judged by how long it’s survived, it’s the most damning.

Every other entry here is a new technique that worked because it was new. ATMZOW isn’t new. It’s eleven years old, and the reason it still works is that nobody had to fix the actual problem, they just kept trusting the same domain. The timing here cuts the opposite way from the usual story: this isn’t a narrow window that got caught in minutes. It’s a campaign that has had over a decade to get caught, evolving in step with the industry’s defenses the whole way, and it is still winning because the underlying assumption, that traffic to a trusted domain is safe, was never actually tested by any of the tools built since 2015. Underground tools like WormGPT and FraudGPT are now used to generate polymorphic versions of scripts like this one, functionally identical but syntactically unique on every deployment, which means even the newest defenses are inheriting the same blind spot the oldest ones had.

This is the difference between defending a domain and defending a behavior, made concrete. Any control built around “is this domain on the allowlist,” a CSP, a WAF rule, a blocklist, inherits the same blind spot: it can only ever be as good as the list of domains someone remembered to write down, and an attacker only has to find one domain nobody thought to question. A control built around watching what a script actually does, which fields it touches, where it sends data, cannot be evaded this way, because it was never asking whether the domain was right. It was asking whether the behavior was right, and eleven years of a script doing the wrong thing has never stopped looking wrong.

Why it matters: No amount of tooling built since 2015 has closed this gap, and that’s not a failure of any one vendor’s product, it’s a failure of the whole category’s premise. If an eleven-year-old technique still works today, and is now getting help from AI to work even better tomorrow, trusting a domain was never the same thing as trusting the code running on it.

What it exposed: The safest architecture isn’t the one with the most complete list of trusted domains. Every list is incomplete the moment a trusted domain gets used the wrong way. The safest architecture is the one that never asked whether the domain was trusted in the first place, only whether the script was doing something it shouldn’t.

Read our full breakdown: How ATMZOW Skimmer Is Still Hiding Inside Google Tag Manager.

Why These Attacks Changed the Conversation

None of these seven incidents needed a zero-day. None of them needed to break anything.

They needed a maintainer’s stolen npm token. A CDN modified at the source instead of intercepted in transit. A payment processor’s own API used as a dead drop. A Chrome extension published with real, stolen, valid credentials. A security vendor’s own build pipeline. In every case, the code that did the damage was code the victim, or the victim’s users, had already decided to trust.

That’s the pattern behind OWASP moving Software Supply Chain Failures to number 3 on its proposed 2025 Top 10. It’s not a hypothetical risk category. It’s the mechanism behind the most consequential security stories of the year, and in every single case, the actual theft or exfiltration happened somewhere traditional tools don’t look: inside a live browser session or a build process, after everything upstream already passed clean.

Scanning your dependencies at build time still matters. Vetting your vendors still matters. But a package, an SDK, or a script, including one built by a company that sells security for a living, can pass every check you run today and still turn malicious tomorrow. The only way to catch that moment is to watch what your third-party code is actually doing right now, not just where it came from or what it looked like the last time someone reviewed it.

The age of chasing hackers is over. The real risk lives in your exposure.