Magecart Attacks in 2025: Patterns We Saw and How to Catch Them

Profile
Yves SoeteFollow
6 min read · Mar 20, 2026

MAR 20, 2026 - Written by Yves SoeteBlacksight LLC — scan your site for skimmers atscanner.blacksight.io

Magecart-style web skimmers have been the dominant ecommerce attack vector for close to a decade, and 2025 kept that streak going. We tracked compromised-script incidents across sites running BlackSight's supply-chain scanner and saw patterns worth sharing — both for the scale, which remains large, and for the evolution in tactics that make these attacks harder to catch with last-year's tooling. This post summarizes what we saw and what actually catches the current generation of skimmers.



The big shift: skimmers moved to CSS and SVG



The most important tactical change in 2025 was attackers hiding skimmer code inside CSS files and SVG images rather than JavaScript files. Traditional supply-chain scanners focus on script tags. A compromised CSS file loaded via link rel="stylesheet" was treated as a cosmetic asset and ignored. The skimmer payload was stored in a CSS comment or an embedded SVG that was then referenced by JavaScript from elsewhere, separating the visible-bad-code from the suspicious-looking-loader.

This matters because the detection surface for most security tooling was scripts. If your third-party monitoring only scans script-src, you missed everything in 2025 that used this pattern. Extending monitoring to cover CSS, SVG, font files, and any other resource that can contain executable markup is now mandatory.



Second shift: legitimate CDN infrastructure as delivery



Throughout 2025, we saw a notable increase in skimmer payloads hosted on entirely legitimate CDNs. jsDelivr, GitHub raw content, Cloudflare R2, and even trusted enterprise vendors had short-lived malicious files served from their domains. Attackers abused the trust these domains carry — a script from cdn.jsdelivr.net does not look suspicious in a header allowlist or CSP rule.

The operational pattern was usually: register a new GitHub account, push skimmer code to a public repo, use the jsDelivr auto-serve pattern to deliver it via cdn.jsdelivr.net/gh/newaccount/skimmer-repo/payload.js. The domain allowlist was never tripped. The payload URL looked random enough that reputation-based defenses missed it. The compromise window averaged 6 to 48 hours before the repo was taken down.

Defense: do not treat entire CDN domains as trusted in your CSP. Use specific paths where possible, or layer SRI hashes on top of the CDN allowlist.



Top 10 compromise patterns we flagged



Ranked by how often we saw them across monitored sites: abandoned analytics/tracking pixels whose vendor was acquired and the new owner turned the script malicious; legacy ecommerce plugins (particularly on Magento 1 sites that never migrated); chat-widget scripts from smaller vendors whose infrastructure was compromised; customer-review and trust-badge widgets from discount-priced vendors with weak security; wishlist and save-for-later widgets bolted on years ago and never updated; session-replay and heatmap tools whose code-injection behavior was abused; payment-form enhancement scripts that hooked form submissions; progress-bar and conversion-optimization widgets with full DOM access; gift-card and loyalty-program integrations; and finally compromised WordPress or Shopify plugins that pushed updates through official channels.

The common thread: none of these are "obvious" supply-chain risks. They are scripts operators added years ago and never looked at again. The skimmer riders exploit exactly that inattention.



Three controls that actually caught it



Continuous inventory with diff alerts. We caught the majority of 2025 incidents because the scanner noticed a new payload URL on a site that had a stable script set for weeks. "This is new" is a surprisingly high-signal alert when your baseline is well-established.

SRI on payment-adjacent scripts. Even where the attacker moved fast, sites that had pinned hashes on Stripe, PayPal, or their own checkout-injected code saw the browser refuse to execute the compromised versions. The attacker had to work around the hash, and that typically required an additional step that generated noise elsewhere.

CSP with nonce-based script-src. The static allowlist approach failed in 2025 because attackers abused legitimate domains on the allowlist. Nonce-based CSP — where each page load generates a fresh random nonce and only tagged scripts with that nonce execute — blocks the attack even when the source domain is trusted. It is more work to implement, but it is the most resilient defense we have seen.



What to do this week if you run ecommerce



Inventory everything loading on your checkout page — not just scripts, all resource types. If you have third-party widgets older than 18 months that your team cannot point to a current maintainer for, remove them or accept the risk explicitly with a written decision. Add SRI to every script on the payment path that supports it. Turn on CSP in report-only mode and review violations for two weeks before enforcing. And set up continuous third-party monitoring so new payloads get flagged in hours, not months.



Run a free skimmer scan at scanner.blacksight.io/supply-chain-security to see what your current third-party footprint looks like.

Run a free scan at scanner.blacksight.io

Liked this article? Get notified when new articles drop — visitblacksight.io/blogto subscribe.

Version 1.0.66