Is My Online Store Hacked? A Five-Minute Check for Magento Skimmer-Style Injections

If you run an online store, you’ve probably wondered whether anyone would know if it got hacked. With this campaign, the honest answer is that you might be the last to find out.

Security firm Sansec says an unknown group has infected 953 online stores, most of them on Magento. The campaign has been running since July 2025. The Hacker News reported on it on October 26, 2026. The detail that matters most to a store owner is that the code checks who is visiting. Real shoppers get the malicious script. Security scanners get nothing.

What happened, in plain English

The attackers add a small piece of code to a store’s pages. When a shopper opens the page, that code makes their browser contact the attacker’s server and ask what to do next. Sansec put it this way: the server first checks whether you are “a real shopper or a security scanner.” Scanners are shown a clean page.

On Magento, the code is tucked into CMS blocks. These are small pieces of content, like a header, a footer or a promo banner, that get dropped into your pages. They live in a database table called cms_block. The source doesn’t say whether the attackers change an existing block or add a new one. Either way, the code runs when the block is displayed.

Two versions of the loader have been seen:

One saves its payload in the visitor’s browser (in something called localStorage). The code can then run again on later visits, even if the attacker’s domain goes offline.
The other adds browser fingerprinting checks to filter out bots and scanners, so only real shoppers see the bad code.

The source says the final payload isn’t known. So I can’t tell you what it does to your customers. A loader like this is a foothold, though. It lets the attacker run whatever they choose on your pages, and that is the same setup used to steal payment details at checkout.

How they got in

Sansec estimates 471 Magento stores were injected through a vulnerability called PolyShell (CVE-2026-48356). Another 102 had files uploaded through PolyShell or another flaw, SessionReaper (CVE-2025-54236).

In one example, a store had web shells, which are files that give an attacker remote control. They were disguised as PNG images in a folder at pub/media/custom_options/quote/. That store was still missing Adobe’s fix, APSB26-73, for PolyShell on supported release lines.

Patching isn’t a guarantee, either. In another case, a store on Magento 2.4.7-p10 with no missing core patches was compromised. The attacker added a rogue administrator account and used it to inject the code.

The injected code has pointed at five domains over time. Each is written here with brackets so nobody clicks it by accident:

manulfie[.]click (first seen July 2025)
neswnsssn[.]click (December 2025)
lanhd6549tdhse[.]top (March 2026)
additionalver[.]com (June 2026)
deepveindrilling[.]com (October 2026)

Sansec found the newest one in the CMS blocks of 83 stores since it was registered on October 6, 2026. Expect more domains to follow, so don’t treat this list as complete.

Does this affect you?

If you run Magento, assume it could. That’s especially true if you haven’t applied Adobe’s PolyShell fix, or if you’ve ever had an admin account you can’t fully account for.

If you’re on Shopify, the article doesn’t say Shopify is affected. The campaign it describes depends on Magento’s CMS blocks and Magento vulnerabilities. The general lesson still applies to any store: a script on your pages that you didn’t put there is a problem. If you aren’t sure what’s on your store, ask the platform’s support or your developer.

One more thing. A scanner telling you your site is clean isn’t proof. This campaign is built to fool scanners, so a clean report only tells you what the scanner was shown.

The five-minute check

You can do most of this without technical skill. For the parts that need database access, you’ll be asking someone else to do it.

Look at your admin users. Open the list of administrator accounts in your store’s admin. Anyone you don’t recognize, or an account created recently that nobody can explain, is a red flag. The 2.4.7-p10 case shows why: the attacker simply made their own admin.
Look at your CMS blocks and pages. Open each block and page in the admin. You’re looking for a script tag or a web address you didn’t add. Sansec’s advice is to check the cms_block and cms_page tables for unexpected entries, so a block you don’t remember creating also counts.
Search for the five domains. If you or your developer can search the database, search those two tables for each domain above. Any hit means you’ve been hit.
Check your patch level. Find out which Magento version you’re on and whether APSB26-73 has been applied. If you can’t find out, that is your answer for now.
Ask about that media folder. Image folders should hold images. Files in pub/media/custom_options/quote/ that are really code in disguise are hard to spot by eye. This one is for your host or developer.

What to do today

Patch. If APSB26-73 isn’t applied, get it applied. Adobe is the official source for that fix.
Remove what you find. Delete rogue admin accounts and unfamiliar blocks, but save a copy of them first. Your host or an investigator will want to see exactly what was there.
Change credentials. Reset admin passwords and use strong, unique ones. The source specifically recommends strong passwords.
Don’t stop at the block. Removing a bad CMS block doesn’t remove a hidden web shell. If one is on the server, the attacker can put the block right back. The cleanup has to cover files and accounts as well as content.

What to tell your host

Hosts respond faster to specifics. Here is what I’d send them:

“I’m concerned about a Magento campaign reported by Sansec that injects JavaScript loaders into the cms_block table.”
Ask them to search cms_block and cms_page for the five domains listed above.
Ask them to check for web shells, including files disguised as images, in pub/media/custom_options/quote/.
Ask which Magento version you’re on, and whether the PolyShell fix (APSB26-73) and the SessionReaper fix have been applied.
Ask them to review admin accounts and recent logins for anything you didn’t create.
Ask for the logs from the period you’re worried about, and ask them to keep those logs.

The same article mentions two critical PHP flaws, called PHP2Shell (CVE-2026-109618 and CVE-2026-109619), that are seeing widespread exploitation attempts. It’s a separate issue, but it’s worth asking your host whether your PHP version is covered.

Signs something already went wrong

This is the hard part, because the campaign is designed to stay quiet. Some general things to watch for:

Customers report odd behaviour at checkout, or unexpected redirects.
Your payment processor or card companies contact you about fraud tied to your store.
An admin account or CMS block appears that nobody on your team made.
A visitor sees something strange, but when you check, everything looks normal. Remember that the code treats you differently if it thinks you’re a scanner. One of the loaders also saves its code in the visitor’s browser, which is another reason it can behave differently from one visit to the next.

When to get help

If you find any of the domains, an unknown admin, or a block you didn’t make, treat it as a real incident. Your host is the first call. If customer payment details may have been exposed, tell your payment processor too. If you can’t tell whether you’re clean, an incident-response or e-commerce security firm can look at the files and logs. Please don’t rely on one clean scanner result.

Sources

The Hacker News: Hackers Infect 953 Online Stores With Scanner-Evading JavaScript, Mostly on Magento (October 26, 2026), which reports findings from Sansec

Featured image: Image by makieni777 from Pixabay.