Hackers Target 953 Online Stores With Scanner-Evading JavaScript

An aggressive, long-running digital skimming campaign has successfully compromised nearly a thousand e-commerce websites worldwide. Operating largely below the radar since July 2025, threat actors have quietly embedded stealthy, scanner-evading Magento JavaScript loader campaign payloads into vulnerable online storefronts. The operation highlights the persistent vulnerabilities plaguing legacy content management systems, particularly Adobe Commerce and open-source Magento installations, as attackers refine their methods to bypass automated security monitoring tools.

Quick Verdict / Key Takeaways:

• Core Development: An unknown threat actor has infected 953 online stores—predominantly running Magento—with malicious JavaScript since July 2025.
• Technical Specs / Root Cause: The campaign injects obfuscated code into legitimate CMS blocks, serving second-stage payloads only when unsuspecting human visitors load the page.
• The Bottom Line: E-commerce administrators must audit custom CMS database blocks, restrict admin panel access, and deploy robust Content Security Policies (CSPs).

Anatomy of a CMS Database Block Infection

The campaign, uncovered by Dutch e-commerce security firm Sansec, relies on a calculated infiltration method designed to evade traditional file-integrity monitoring systems. Instead of modifying core PHP files or static JavaScript assets on the server's filesystem—changes that standard security scanners flag almost instantly—the attackers target the database itself.

By gaining unauthorized access to the administration panels of targeted online stores, the threat actors inject malicious code directly into the CMS blocks table within the backend database. Because these blocks are rendered dynamically during page generation, the malicious script becomes an organic part of the Document Object Model (DOM) when viewed in a browser.

The payload itself is engineered for discretion. Rather than executing aggressively for every inbound HTTP request, the injected JavaScript features environmental checks designed to filter out web crawlers, security scanners, and automated analysis sandboxes. When a search engine crawler or automated security bot queries the e-commerce platform, the script remains dormant or benign. However, when an unsuspecting human customer navigates to the storefront, the loader springs into action, fetching and executing secondary obfuscated payloads designed to harvest sensitive payment card data, credentials, and personally identifiable information (PII) at checkout.

The Concentrated Risk Facing Legacy Magento Deployments

While digital skimming operations—historically grouped under the umbrella term "Magecart"—are far from new, the concentration of this specific 953-store wave on Magento underscores the platform's unique risk profile. Open-source Magento and its enterprise counterpart, Adobe Commerce, manage massive volumes of high-value transactional traffic, making them prime targets for financially motivated cybercriminals.

The success of this campaign does not necessarily point to a novel zero-day vulnerability in the Magento core architecture. Instead, security researchers indicate that the breaches typically stem from a familiar cocktail of security hygiene lapses: weak or reused administrative credentials, unpatched third-party modules, API misconfigurations, and left-open database ports. Because many merchants rely on outsourced agencies or decentralized teams to maintain their infrastructure, orphaned admin accounts often remain active long after projects conclude, providing threat actors with a frictionless entry point.

Furthermore, digital skimming scripts have evolved significantly over the past several cycles. Modern e-commerce malware frequently employs advanced string obfuscation, DOM-based event listeners, and domain-fronted infrastructure to blend in with legitimate telemetry or analytics tracking scripts. This makes static signature-based detection virtually useless, forcing security teams to pivot toward behavioral analysis and strict outbound network monitoring.

Defending E-Commerce Platforms Against Silent Injections

Mitigating campaigns that abuse legitimate database structures requires a defense-in-depth strategy that goes far beyond traditional file integrity monitoring. Because database-level modifications bypass standard code audits, store operators must implement rigorous access controls and continuous monitoring specifically targeting backend mutations.

First and foremost, administrative access to Magento backends must be strictly restricted behind multi-factor authentication (MFA), IP whitelisting, and non-standard login URLs. Securing administrative interfaces drastically cuts off the initial vector leveraged by these threat actors. Additionally, merchants should perform regular database audits, specifically monitoring the cms_block and cms_page tables for unauthorized script tags, base64-encoded strings, or external resource calls.

On the client side, deploying a strict Content Security Policy (CSP) acts as an invaluable circuit breaker. By explicitly defining which external domains are permitted to execute scripts or receive outbound telemetry, a well-configured CSP can effectively neutralize unauthorized data exfiltration attempts, even if an attacker successfully manages to inject malicious code into the database.

---

Frequently Asked Questions

What is a Magento JavaScript loader campaign?

It is a targeted cyberattack where threat actors compromise e-commerce administration panels to inject malicious, obfuscated JavaScript into dynamic database blocks. This script loads secondary payloads onto user browsers to skim sensitive checkout data.

Why are Magento stores targeted more frequently than other platforms?

Magento processes high volumes of direct credit card transactions and financial data, making it a lucrative target for cybercriminals. Additionally, complex multi-vendor ecosystems and legacy third-party extensions often provide unpatched entry points for attackers.

How can merchants detect if their store has been infected by this campaign?

Because this campaign modifies database records rather than physical server files, traditional file integrity monitors may fail to spot it. Store owners must audit their CMS blocks and CMS pages directly in the database or use specialized e-commerce security scanners that check for DOM-level anomalies.