Card brands will notice this before your weekly scan does. An unknown operator has planted checkout skimmers in 953 online stores, most of them Magento, by stuffing a tiny loader into CMS blocks that render on every product and payment page. Sansec, the Dutch e-commerce security firm that tracks this mess, says the campaign has been live since July 2025. Your cybersecurity stack can give Magento a clean bill of health while customers type PAN, CVV, and billing ZIP into a page the attacker already owns.

The cost is live payment pages, for months, handing card data to a loader your file integrity monitor never saw because the payload never lived on disk.

Cybersecurity That Only Scans Files Misses Checkout

Magento stores HTML snippets in the database. CMS blocks and CMS pages get concatenated into the response like any other template. If you only hash app/code and vendor, you’re hashing the wrong layer. The malicious edit sits in cms_block or cms_page, often a few dozen characters that fetch a remote loader. Visitors get the full skimmer. Your scanner gets a clean plugin tree.

The Hacker News report on Sansec’s write-up calls the JavaScript scanner-evading. Read that as packed, delayed, or gated so automated crawlers see a boring storefront. Threat detection that samples static files or runs a generic website scanner on a schedule will keep blessing the site. The customer browser is the only runtime that matters, and it’s the one you don’t instrument.

An unknown threat actor has infected 953 online stores, most of them running Magento, as part of a long-running campaign active since July 2025.

Your firewall sees a normal HTTPS GET from a shopper. There’s no exploit packet to drop. Brute-force noise against /admin may have been the original door, or a stolen session, or a neglected extension. Once the operator can edit a block, threat-protection at the edge is watching the wrong conversation. The page source is the malware.

You already know Magecart as a genre. This campaign is the same genre with better hiding. Defense in depth that stops at WAF signatures and malware file scans leaves the CMS as an unmonitored script host. That’s a cyber security gap you can name in one sentence: content is code, and Magento treats merchant content as trusted.

Lock the CMS Before Card Brands Call

Stop waiting for a processor letter. Treat checkout HTML as an incident surface tonight, then keep a watch on it the way you watch privileged accounts.

Do this on the live shop before the next business day.

• Dump cms_block and cms_page from production and grep for script, eval, atob, fromCharCode, iframe, and unexpected HTTPS URLs. Diff against last week’s backup, not against Magento core.
• Save a logged-out checkout HTML snapshot from a real browser profile and compare it to a known-good capture. Headless scanners lie. Use a stock Chrome profile with no extensions.
• Inventory Magento admin users. Disable unknowns. Rotate every admin password and every integration token. Turn on 2FA if it’s off, and kill unused API keys.
• Read admin action logs for CMS saves, design config changes, and new users since July 2025. That’s the campaign window Sansec published.
• Put a Content-Security-Policy report-only header on checkout that allows only your CDN and payment processor. The first violation report is often the loader host.
• If you find a skimmer, freeze checkout, rotate payment gateway credentials, and start incident response with your processor. Assume PANs left. Don’t debate it in Slack for three days.

Keep it going. Rebuild security hardening around Magento as a content engine, not a PHP app you patch on Tuesdays. Back up CMS tables daily and alert on row changes to blocks that render on checkout. Require two people to publish a CMS block that appears on the payment flow. Restrict admin to a jump host. Don’t hang /admin on the same hostname shoppers use. Review third-party Magento extensions quarterly the way you review IdP apps. If an extension can edit blocks, it is an admin.

A Stolen Admin Session Keeps Skimming for Months

July 2025 to late October 2026 is a long dwell time for a payment-page implant. Someone had write access and nobody watched the HTML. A CMS row will never trip the EDR rule you wrote for a dropped PHP webshell.

That dwell time is the real bill. PCI forensic invoices. Card-brand operating-expense assessments. Customers who won’t come back. Your threat-protection program looking busy while the storefront did the attacker’s work. If incident response starts at reinstalling Magento, you’ll miss the database. Restore files, leave the block, and you reopen tomorrow.

Hunt persistence the way you hunt a second admin. New CMS widgets. Theme files stored in the database. Cron jobs that rewrite a cleaned block overnight. Magento’s block-save event should page the same on-call rotation that gets a domain-admin add. Until that is true, you’re running a card collector with a storefront skin.

Payment processors will ask who could edit the checkout and whether you have logs. If the answer is every marketing intern with a Magento account, you already know how the next campaign lands. Shrink that group. Log every publish. Keep a canary checkout capture once a week and diff it. That test is ugly. It also tells you whether threat detection ever sees the skimmer your shoppers already run.

Patch Magento. Yes. Then watch what merchants are allowed to publish. The 953 stores missed a simpler failure than a missing patch. Checkout HTML is production code, edited through a GUI, with no pull request and no CSP. Fix that, and the next loader has to fight you on a channel you actually instrument.

Sources

• Hackers Infect 953 Online Stores With Scanner-Evading JavaScript, Mostly on Magento