A long-running Magecart-style campaign has compromised at least 953 e-commerce stores, the vast majority running Magento, injecting scanner-evading JavaScript loaders directly into CMS blocks. Active since July 2025 and identified by Dutch e-commerce security firm Sansec, this operation represents a sophisticated evolution in client-side card skimming — one that prioritizes stealth, persistence, and evasion of both automated scanners and manual code review.
For SOC teams, CISOs, and e-commerce platform owners, this is not a theoretical vulnerability disclosure. This is confirmed active exploitation of the web application layer, targeting the trust boundary between your storefront and your customers' browsers. The threat actor isn't dropping ransomware or exfiltrating databases. They're skimming payment card data, PII, and session tokens in real time as transactions occur. And they're doing it through a legitimate Magento feature — CMS blocks — that most security teams never audit.
If your organization operates or manages Magento stores, or if you provide MDR services to retail clients, immediate hunting and hardening are required.
Technical Analysis
Attack Vector: CMS Block Injection
Magento's CMS blocks (also called static blocks) are reusable content fragments typically used for banners, promotional messaging, footer links, and trust seals. They're stored in the cms_block database table and rendered on category pages, product pages, and checkout flows via layout XML or widget references.
In this campaign, the threat actor gains administrative access to the Magento backend — exact initial access vectors remain unconfirmed in the Sansec disclosure, but historical Magecart TTPs include credential stuffing against /admin panels, exploitation of outdated Magento versions, compromised third-party extensions, and supply-chain compromise of theme or extension vendors.
Once inside, the attacker modifies existing CMS blocks or creates new ones, embedding malicious JavaScript that serves a loader script when pages render. Critically, this loader is designed to evade automated scanning:
- Conditional execution: The script checks for indicators of analysis — headless browsers, missing mouse movement, disabled JavaScript features, specific user-agent strings — and remains dormant if detected.
- Dynamic payload retrieval: The CMS block contains only a lightweight loader. The actual skimming payload is fetched from attacker-controlled infrastructure at runtime, often via obfuscated domains, DGA-generated hostnames, or compromised third-party CDNs.
- DOM injection timing: The payload doesn't execute immediately on page load. It waits for specific events — checkout form focus, payment field interaction, or completion of address fields — ensuring it only activates when high-value data is present.
- Exfiltration obfuscation: Stolen data is encoded, encrypted, or split across multiple requests to blend with legitimate traffic. Common patterns include base64-encoded POST bodies, beaconing to domains that mimic analytics platforms, or abuse of legitimate services as dead drops.
Why CMS Blocks Are Effective for Attackers
CMS blocks are a persistence mechanism hiding in plain sight:
- Legitimate functionality: Magento admins routinely edit CMS blocks. Security tools rarely flag these changes as anomalous.
- Database persistence: Unlike file-based web shells, CMS block modifications survive server reboots and don't trigger file integrity monitoring unless you're specifically hashing database content.
- Cached rendering: Magento's full-page cache (FPC) means the malicious block may be cached and served to thousands of users before a refresh occurs, amplifying impact while reducing the window for detection.
- Limited logging: Default Magento logging captures admin logins and some configuration changes, but CMS block edits are often logged only at the application level (if at all) and rarely forwarded to SIEM platforms.
Exploitation Status
This campaign is confirmed active and in-the-wild. Sansec's telemetry indicates continuous operation since July 2025, with 953 confirmed infections as of the disclosure date. No CVE has been publicly assigned — this is a technique, not a single vulnerability. The attack chain likely exploits:
- Weak or reused admin credentials
- Outdated Magento installations (particularly versions prior to 2.4.7, which lack recent security patches)
- Vulnerable third-party extensions with remote code execution or privilege escalation flaws
- Misconfigured file permissions or exposed admin panels
CISA KEV inclusion is not applicable as this is not a CVE-specific vulnerability. However, the TTPs align with MITRE ATT&CK techniques T1505.003 (Web Shell), T1189 (Drive-by Compromise), and T1056.004 (Input Capture: Credential API Hooking).
Affected Platforms
- Magento Open Source: All versions, though older installations (pre-2.4.6) are at higher risk due to unpatched vulnerabilities.
- Adobe Commerce: Both on-premise and cloud-hosted instances are susceptible if admin access is compromised.
- Custom themes and extensions: Any third-party code with backend vulnerabilities can serve as an initial access vector.
The campaign disproportionately affects Magento due to its market share in mid-to-large e-commerce operations, but the technique is platform-agnostic. WooCommerce, Shopify (via admin API abuse), and custom PHP storefronts are equally vulnerable to CMS-level content injection.
Detection & Response
SIGMA Rules
The following Sigma rules target observable behaviors associated with CMS block injection, suspicious admin activity, and client-side payload delivery. Tune thresholds based on your environment's baseline admin activity.
---
title: Magento Admin Panel Access from Suspicious Geolocation
id: 9a4f3e21-7b8c-4d5e-9f2a-1c3b5d7e9a1f
status: experimental
description: Detects Magento admin panel logins from IP addresses associated with VPNs, Tor exit nodes, or geographies inconsistent with baseline admin activity.
references:
- https://attack.mitre.org/techniques/T1078/
author: Security Arsenal
date: 2026/10/22
tags:
- attack.initial_access
- attack.t1078
logsource:
category: webserver
product: apache
detection:
selection:
cs-uri-stem|contains:
- '/admin'
- '/admin_'
sc-status: 200
filter_known_admins:
c-ip|contains:
- '10.0.0.'
- '192.168.'
condition: selection and not filter_known_admins
falsepositives:
- Legitimate admin access from home networks or travel
- Third-party developers or agencies
level: medium
---
title: Suspicious JavaScript Loaded from Non-Standard Domain
id: 7c2e8f4a-3b1d-4e6c-9a5f-2d8b4c7e1a3f
status: experimental
description: Detects HTTP requests for JavaScript files from domains not associated with the primary storefront or known CDNs, indicating potential skimmer payload retrieval.
references:
- https://attack.mitre.org/techniques/T1189/
author: Security Arsenal
date: 2026/10/22
tags:
- attack.collection
- attack.t1189
logsource:
category: proxy
detection:
selection:
cs-uri-stem|endswith: '.js'
c-ip|startswith:
- '10.'
- '192.168.'
- '172.16.'
filter_known_domains:
cs-host|contains:
- 'yourstore.com'
- 'cdn.yourstore.com'
- 'google-analytics.com'
- 'googletagmanager.com'
- 'cloudflare.com'
condition: selection and not filter_known_domains
falsepositives:
- Legitimate third-party integrations (payment gateways, marketing tools)
- Development or staging environments
level: high
---
title: Unexpected Database Query to CMS Block Table
id: 4d6a9c2e-8f1b-4a3c-9e7d-2b5f8a1c4e6d
status: experimental
description: Detects direct SQL queries against the cms_block table from application servers, which may indicate CMS block enumeration or modification by an attacker.
references:
- https://attack.mitre.org/techniques/T1505/
author: Security Arsenal
date: 2026/10/22
tags:
- attack.persistence
- attack.t1505
logsource:
category: database
product: mysql
detection:
selection:
query|contains:
- 'cms_block'
- 'UPDATE cms_block'
- 'INSERT INTO cms_block'
filter_known_app:
user|contains:
- 'magento_app'
- 'magento_user'
condition: selection and not filter_known_app
falsepositives:
- Magento application itself performing legitimate CMS operations
- Admin-initiated content updates via backend
level: medium
KQL for Microsoft Sentinel / Defender
This query hunts for suspicious admin panel access patterns and anomalous outbound JavaScript requests from Magento servers. It assumes Apache or Nginx logs are ingested via Syslog or CommonSecurityLog.
// Hunt for Magento admin panel logins from unusual IP addresses
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where RequestURL contains "/admin" or RequestURL contains "/admin_"
| where SourceIP !startswith "10." and SourceIP !startswith "192.168." and SourceIP !startswith "172.16."
| summarize LoginAttempts = count(), DistinctUserAgents = dcount(RequestClientApplication) by SourceIP, DestinationHostName, bin(TimeGenerated, 1h)
| where LoginAttempts > 5 or DistinctUserAgents > 3
| sort by LoginAttempts desc;
// Hunt for outbound requests to suspicious JavaScript domains from web servers
Syslog
| where TimeGenerated > ago(7d)
| where Computer contains "web" or Computer contains "magento"
| where SyslogMessage contains "GET" and SyslogMessage contains ".js"
| extend JSUrl = extract(@"GET (https?://[^\s]+\.js)", 1, SyslogMessage)
| where isnotempty(JSUrl)
| extend Domain = tostring(parse_url(JSUrl).Host)
| where Domain !contains "yourstore.com"
and Domain !contains "cloudflare"
and Domain !contains "google"
and Domain !contains "jquery"
| summarize Requests = count() by Domain, Computer, bin(TimeGenerated, 1d)
| sort by Requests desc;
// Correlate admin logins with subsequent outbound connections
let AdminLogins = CommonSecurityLog
| where TimeGenerated > ago(7d)
| where RequestURL contains "/admin"
| where SourceIP !startswith "10." and SourceIP !startswith "192.168."
| summarize by SourceIP, DestinationHostName, TimeGenerated;
AdminLogins
| join kind=inner (
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where RemoteUrl endswith ".js"
) on $left.DestinationHostName == $right.DeviceName
| project AdminLoginTime = TimeGenerated, SourceIP, DeviceName, RemoteUrl, RemoteIP
| sort by AdminLoginTime desc;
Velociraptor VQL
Use this artifact to hunt for modified Magento CMS blocks by querying database content directly or examining cached rendered HTML for injected scripts.
-- Hunt for suspicious JavaScript patterns in Magento CMS blocks (requires database access)
SELECT
block_id,
title,
identifier,
content,
creation_time,
update_time
FROM
mysql_query(
query="SELECT block_id, title, identifier, content, creation_time, update_time FROM cms_block WHERE content LIKE '%<script%' OR content LIKE '%eval(%' OR content LIKE '%atob(%' OR content LIKE '%fromCharCode%' ORDER BY update_time DESC",
env_system_mysql_username="readonly_user",
env_system_mysql_password="secure_password"
)
WHERE
content =~ "script|eval|atob|fromCharCode|onerror="
-- Hunt for recently modified template files that may contain injected code
SELECT
FullPath,
Size,
Mtime,
Ctime,
hash(path=FullPath) AS FileHash
FROM
glob(globs="/var/www/html/app/design/frontend/**/*.phtml")
WHERE
Mtime > ago("7d")
AND (FullPath =~ "checkout" OR FullPath =~ "cart" OR FullPath =~ "payment")
ORDER BY
Mtime DESC
-- Enumerate active network connections from PHP-FPM or Apache processes
SELECT
Pid,
Name,
CommandLine,
RemoteAddress,
RemotePort,
Status
FROM
netstat()
WHERE
(Name =~ "php-fpm" OR Name =~ "apache" OR Name =~ "nginx")
AND RemotePort != 3306
AND RemotePort != 6379
AND RemotePort != 443
AND Status =~ "ESTABLISHED"
Remediation Script
This Bash script audits Magento installations for common indicators of compromise, verifies file integrity, and checks for unauthorized CMS block modifications.
#!/bin/bash
# Magento CMS Block Injection Detection and Remediation Script
# Run as a user with read access to Magento files and database
MAGENTO_ROOT="/var/www/html"
DB_USER="magento_user"
DB_PASS="secure_password"
DB_NAME="magento_db"
BACKUP_DIR="/var/backups/magento_audit_$(date +%Y%m%d_%H%M%S)"
echo "[+] Starting Magento security audit..."
mkdir -p "$BACKUP_DIR"
# 1. Check for recently modified template files
echo "[+] Checking for modified .phtml template files in the last 30 days..."
find "$MAGENTO_ROOT/app/design/frontend" -name "*.phtml" -type f -mtime -30 > "$BACKUP_DIR/modified_templates.txt"
if [ -s "$BACKUP_DIR/modified_templates.txt" ]; then
echo "[!] WARNING: Modified templates found. Review $BACKUP_DIR/modified_templates.txt"
else
echo "[+] No recently modified templates detected."
fi
# 2. Audit CMS blocks for suspicious JavaScript
echo "[+] Querying cms_block table for suspicious content..."
mysql -u"$DB_USER" -p"$DB_PASS" "$DB_NAME" -e \
"SELECT block_id, title, identifier, update_time FROM cms_block WHERE \
content LIKE '%<script%' OR \
content LIKE '%eval(%' OR \
content LIKE '%atob(%' OR \
content LIKE '%fromCharCode%' OR \
content LIKE '%document.write%' OR \
content LIKE '%innerHTML%' \
ORDER BY update_time DESC;" > "$BACKUP_DIR/suspicious_cms_blocks.txt"
if [ -s "$BACKUP_DIR/suspicious_cms_blocks.txt" ]; then
echo "[!] WARNING: Suspicious CMS blocks detected. Review $BACKUP_DIR/suspicious_cms_blocks.txt"
echo "[!] Backup these blocks before modification: mysqldump -u$DB_USER -p$DB_PASS $DB_NAME cms_block > $BACKUP_DIR/cms_block_backup.sql"
else
echo "[+] No obvious malicious CMS blocks found."
fi
# 3. Check admin users for unauthorized accounts
echo "[+] Auditing Magento admin users..."
mysql -u"$DB_USER" -p"$DB_PASS" "$DB_NAME" -e \
"SELECT user_id, username, email, created, logdate FROM admin_user ORDER BY created DESC;" > "$BACKUP_DIR/admin_users.txt"
echo "[+] Admin user list saved to $BACKUP_DIR/admin_users.txt"
echo "[!] Manually review for unauthorized accounts."
# 4. Check for web shells in common upload directories
echo "[+] Scanning for web shells in media and var directories..."
find "$MAGENTO_ROOT/media" "$MAGENTO_ROOT/var" "$MAGENTO_ROOT/pub/media" -type f \( -name "*.php" -o -name "*.phtml" \) -mtime -60 > "$BACKUP_DIR/suspicious_php_files.txt"
if [ -s "$BACKUP_DIR/suspicious_php_files.txt" ]; then
echo "[!] WARNING: PHP files found in upload directories. Review $BACKUP_DIR/suspicious_php_files.txt"
else
echo "[+] No PHP files detected in upload directories."
fi
# 5. Verify Magento version
echo "[+] Checking Magento version..."
if [ -f "$MAGENTO_ROOT/bin/magento" ]; then
php "$MAGENTO_ROOT/bin/magento" --version > "$BACKUP_DIR/magento_version.txt"
cat "$BACKUP_DIR/magento_version.txt"
echo "[!] Verify this version is fully patched at https://magento.com/security/patches"
else
echo "[!] Could not determine Magento version. Check manually."
fi
# 6. Check file permissions on critical directories
echo "[+] Auditing file permissions..."
find "$MAGENTO_ROOT/app/etc" -type f -perm -o+w > "$BACKUP_DIR/world_writable_config.txt"
if [ -s "$BACKUP_DIR/world_writable_config.txt" ]; then
echo "[!] WARNING: World-writable configuration files detected. Fix immediately."
else
echo "[+] Configuration file permissions appear secure."
fi
# 7. Check for suspicious cron jobs
echo "[+] Auditing cron jobs for Magento user..."
crontab -u www-data -l 2>/dev/null > "$BACKUP_DIR/www-data_crontab.txt" || echo "No crontab for www-data"
crontab -u magento -l 2>/dev/null > "$BACKUP_DIR/magento_crontab.txt" || echo "No crontab for magento user"
echo "[+] Audit complete. Review all files in $BACKUP_DIR"
echo "[+] Next steps: Review flagged files, update Magento to latest version, rotate admin credentials, enable 2FA."
Remediation
Immediate Actions
-
Audit CMS Blocks: Export and review all CMS blocks for injected JavaScript. Look for
<script>tags,eval(),atob(),fromCharCode(), or base64-encoded content. Compare against known-good backups. -
Review Admin Users: Query the
admin_usertable for accounts created or modified in the last 90 days. Disable any unrecognized accounts immediately. Force password resets for all admin users and enable two-factor authentication (2FA) via the Magento Admin Panel under Stores > Configuration > Security > 2FA. -
Update Magento: Ensure you are running the latest security-patched version. As of October 2026, Magento Open Source 2.4.7-p3 or later and Adobe Commerce 2.4.7-p3 or later include all current security fixes. Review Adobe's security bulletin archive at https://helpx.adobe.com/security/products/magento.html for applicable patches.
-
Rotate Credentials: Change all admin passwords, API keys (under System > Integrations), database credentials in
app/etc/env.php, and SSH keys for server access. -
Enable File Integrity Monitoring: Deploy FIM on
app/code,app/design,vendor, andpub/staticdirectories. Tools like Tripwire, AIDE, or OSSEC can alert on unauthorized file modifications.
Long-Term Hardening
-
Restrict Admin Panel Access: Implement IP whitelisting for
/adminand/admin_*paths via.htaccess, Nginx configuration, or a WAF rule. If dynamic IPs are unavoidable, enforce VPN-only access to the admin panel. -
Deploy Content Security Policy (CSP): Configure CSP headers to restrict JavaScript execution to trusted domains. Example for Apache:
APACHE
Header set Content-Security-Policy "script-src 'self' https://cdn.yourstore.com https://www.google-analytics.com; object-src 'none'; base-uri 'self';"
Test in report-only mode first to avoid breaking legitimate functionality.
8. **Enable Magento Security Scan**: Adobe provides a free Security Scan Tool at https://account.magento.com/scanner. Schedule weekly scans and review findings.
9. **Database Activity Monitoring**: Forward MySQL/MariaDB query logs to your SIEM. Alert on `UPDATE` or `INSERT` statements against `cms_block`, `cms_page`, or `core_config_data` tables originating from non-application hosts or during non-business hours.
10. **Web Application Firewall (WAF)**: Deploy a WAF with Magento-specific rulesets. ModSecurity with OWASP CRS includes protections against common Magento attack patterns. Cloudflare, Sucuri, and Fastly offer managed WAF services tuned for e-commerce.
11. **Implement Subresource Integrity (SRI)**: For any third-party JavaScript loaded on checkout pages, use SRI hashes to ensure payload integrity. Example:
```html
<script src="https://cdn.example.com/script.js" integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC" crossorigin="anonymous"></script>
- Monitor Checkout Behavior: Implement client-side JavaScript integrity monitoring using tools like Sansec, Sucuri, or Source Defense. These services detect unexpected DOM modifications, form field hijacking, and anomalous outbound requests from the browser.
Vendor and Community Resources
- Adobe Security Bulletins: https://helpx.adobe.com/security/products/magento.html
- Magento Security Best Practices: https://experienceleague.adobe.com/docs/commerce-operations/implementation-playbook/best-practices/launch/security-best-practices.html
- Sansec Magecart Research: https://sansec.io/research
- OWASP Web Skimming Prevention: https://owasp.org/www-community/attacks/Web_Skimming
CISA Deadlines
No CISA KEV entry applies to this campaign as it is technique-based rather than CVE-specific. However, CISA Binding Operational Directive 23-02 mandates that federal agencies remediate internet-facing vulnerabilities within prescribed timelines. If your Magento stack has unpatched CVEs from 2025 or 2026, treat them as critical priority.
Related Resources
Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.