953 Stores Hit by Scanner-Evading JavaScript: Magento

The Hacker News reports that hackers have infected 953 online stores with JavaScript it describes as scanner-evading, and that most of the affected stores run on Magento. If you run Adobe Commerce, the useful response is practical: audit what your storefront really serves to shoppers, and don't let one clean scan close the question.

Key takeaways

• The Hacker News reports 953 online stores infected with scanner-evading JavaScript, mostly on Magento.
• Treat the report as a reason to audit every script your storefront loads, not as proof that your store is affected.
• A clean result from one automated scan is weaker evidence when the malware is described as scanner-evading, so combine several kinds of checks.
• Start with a script inventory, an admin account review, a file comparison against a known-good release and a patch check against Adobe's official security bulletins.
• Keep inventory and monitoring in-house. Bring in a partner for forensics, remediation and checkout architecture.

What did The Hacker News report, and what is still unknown?

The headline gives three facts. There are 953 online stores involved. The infection is JavaScript. And the code is described as scanner-evading, with most of the affected stores on Magento. That is the whole of what this post attributes to The Hacker News.

Everything past that is a question to take to the original report. Which versions were involved? How was the code placed on the stores? How long did it sit there? What did it do to shoppers? The headline doesn't answer those, and guessing would be worse than waiting. Read the full article and then compare it against Adobe's own security bulletins and release notes.

One more point on scale. 953 stores is a real number, but it's a small slice of the commerce sites on the internet. Don't read it as a sign that every store is hit. Read it as evidence that this kind of attack is being run against stores like yours, and that enough of them were reached to make the news.

Does this apply to an Adobe Commerce store?

The headline says Magento. If your store runs Adobe Commerce or Magento Open Source, the sensible position is to assume the report is relevant until you have checked, because the cost of checking is a few hours and the cost of being wrong is a compromised checkout.

It also matters who in the business should care. Here is a rough split.

Merchants who run on a hosted, managed setup have help with parts of this, but not all of it. Managed hosting doesn't review the tag manager your marketing team edits on Friday afternoon. Ask your provider exactly what they monitor and what they leave to you.

Why a clean scan should not end the conversation

The word in the headline that matters most is scanner-evading. The details of how the code does that are in The Hacker News piece, and this post won't speculate about them. The plain consequence is this: if code is built to avoid scanners, a scanner reporting nothing is less reassuring than it used to be.

That doesn't make scanners useless. They catch plenty of known problems and they're cheap to run. It means you should never rely on a single kind of evidence. Think of it as four independent angles:

• What the browser loads. Which script URLs and inline blocks appear on product, cart and checkout pages.
• What is on the server. Whether deployed files match the release you meant to ship.
• Who changed what. Admin accounts, permissions, configuration changes and deployment history.
• What leaves the page. Where the browser sends data, as seen by your security headers and network monitoring.

A problem that hides from one angle often shows on another. A file on the server that doesn't match version control is suspicious whether or not any scanner flags it. A script request to a domain nobody can explain is suspicious whether or not the script looks harmful.

What should you do in the first week?

Work through these in order. None of it requires exploiting anything, and all of it is ordinary hygiene.

1. Confirm your patch level. Find the version you run and check it against Adobe's official security bulletins and release notes. Those pages are the authority on fixed versions, so take the numbers from there and not from a blog post, including this one.
2. Build a script inventory. Load your home page, a category page, a product page, the cart and every checkout step in a clean browser session. Record every script source and every inline block. Anything without a named owner goes on a review list.
3. Review the tag manager. Export the container. Look for tags nobody remembers adding, tags that haven't been touched in years, and anything that can inject arbitrary code.
4. Audit admin accounts. List every admin user, last login, role and two-factor status. Remove people who left. Check for accounts created recently that you can't explain.
5. Compare files to a known-good release. Use version control or a clean build as the reference, and diff the deployed code against it. Pay particular attention to theme files, layout templates and anything that outputs JavaScript.
6. Check configuration for injected content. Look at fields in the admin that allow custom HTML or scripts in headers and footers. Compare them with your last known-good state.
7. Rotate secrets if anything looks wrong. That includes admin passwords, API keys and integration credentials, but only after you have preserved evidence.

If step two or five turns up something you can't explain, stop and treat it as an incident. Don't just delete it. Copy the evidence somewhere safe first, then follow your incident plan. Cleaning up too fast can destroy the very information you need to learn how the code arrived, and if you don't find the entry point it will come back.

How do you roll this out without breaking checkout?

Security changes on a checkout page can fail quietly. A policy that blocks one payment script costs you orders for days before anyone notices. So stage the work.

Start in report-only mode. A content security policy can be set to report what it would block without blocking it. Run it for a couple of weeks, read the reports, and build an allow list from real traffic. Then move to enforcement on one low-risk page group before touching checkout.

Test on staging with real payment flows, including the awkward ones: guest checkout, saved cards, wallet buttons, promo codes, and the third-party fraud and address tools you use. Each of those loads its own scripts.

Here is a simple rollout plan with owners.

Roll back quickly if conversion drops. Keep the previous policy in version control so reverting is a one-line change.

How do you measure whether you are safer?

Pick measures that show the process works, not just that a scan ran. A few that are worth tracking:

• The share of scripts on key pages that have a named owner. The goal is all of them.
• The number of unexplained differences between deployed files and the release. The goal is zero, and any nonzero number needs a ticket.
• How long it takes from a new script appearing on checkout to someone being alerted. The direction you want is minutes or hours, not weeks.
• The time since the last admin account review.
• Your patch lag, meaning how long you take to apply a security release after Adobe publishes it.

Watch business metrics too. A sudden change in checkout conversion, payment errors or page load time after a policy change deserves a look. And keep an eye on customer service tickets and payment processor notices, because those sometimes spot trouble before your own tools do.

What should you not do?

• Don't panic-delete. Removing a suspicious file before capturing it destroys evidence and may leave the way in open.
• Don't trust one scan. Given the scanner-evading description, a clean result is a single data point.
• Don't skip the marketing tags. Third-party tags run with the same privileges as your own code in the shopper's browser, and they often change without engineering review.
• Don't copy fixed version numbers from articles. Confirm them against Adobe's official security bulletin.
• Don't enforce a strict policy on checkout without staging. You can lose more in blocked orders than you were protecting.
• Don't assume hosting covers it. Ask your provider in writing what is monitored.
• Don't announce a clean bill of health too early. Say what you checked, and what you haven't.

Where does an implementation partner help, and where can your team manage alone?

Most of the first week is work your own team can do. Patch tracking, a script inventory, an admin account review and a tag manager export are routine and cheap. A partner adds little there, and doing it yourself builds knowledge you'll want when the next report lands.

A partner earns their fee when the situation is harder:

• You suspect a real compromise and need forensics, a timeline and a clear view of how the code got in.
• Remediation touches custom modules, a heavily modified theme or a checkout that was built years ago and nobody fully understands.
• You need to redesign how third-party scripts are loaded, for example to isolate payment fields or reduce what runs on checkout.
• You lack the capacity to run staging tests across every payment method and market.
• You're upgrading anyway and want security work folded into the same project.

When you do look for one, ask for specific evidence: have they handled a storefront compromise before, how do they preserve evidence, and who on their side does the work. The Adobe Commerce partners directory is a reasonable place to start a shortlist, and find-partners lets you filter by what you need. Write down the scope before you talk to anyone. The Adobe Commerce RFP template gives you a structure for that, including sections on security, hosting and handover, so every vendor answers the same questions.

A last position worth taking. Security reports like this one come around regularly, and each time the teams that cope best aren't the ones with the fanciest tooling. They're the ones that know what their storefront loads, who owns it and who gets the alert. Build that once, and the next headline costs you an afternoon instead of a scramble.

Sources

• The Hacker News — Reported that 953 online stores were infected with scanner-evading JavaScript, mostly on Magento.