Magecart 1×1 SVG skimmer on Magento: DLP and GDPR compliance

On April 8, 2026, Sansec disclosed a Magecart campaign against ~100 Magento stores: a credit card skimmer hidden in a 1×1 SVG, exfiltrating to 23.137.249.67 (IncogNET, NL). Here is how well‑tuned DLP addresses GDPR Articles 32 and 44‑49.

The facts

On April 7–8, 2026, the forensics team at Sansec documented a web‑skimming attack targeting nearly a hundred Magento e‑commerce sites. The mechanism: the attacker injects an <svg width="1px" height="1px" onload="..."> element that embeds all malicious code in base64 (via atob()) and runs it via setTimeout. When the user clicks “Pay/Checkout,” a fake “Secure Checkout” overlay captures card numbers in real time (Luhn validation), billing address and other fields, then exfiltrates JSON data encrypted with XOR + base64 to attacker‑controlled domains.

Sansec assesses the initial intrusion likely exploited the PolyShell vulnerability affecting Magento/Adobe Commerce (unauthenticated code execution and takeover). BleepingComputer confirms the key details, noting that as of April 8, Adobe had not released a production patch (only a pre‑release was available). The exfiltration infrastructure is hosted by IncogNET (AS40663) in the Netherlands; the host later stated the malicious account was disabled.

Public IOCs (Sansec extract):

• Exfiltration IP: 23.137.249.67 (IncogNET, NL)
• Path: /fb_metrics.php
• Local browser marker key: _mgx_cv
• Exfiltration domains: statistics-for-you[.]com, statistics-renew[.]com, morningflexpleasure[.]com, reusable-flex[.]com, goingfatter[.]com, wellfacing[.]com

Defensive highlights: 100% inline payload (no external script call), “no‑cors” POST via fetch() with iframe fallback, near‑invisible 1×1 SVG tag, credible UX lures, and redirection to the legitimate payment page after data theft — all of which evade superficial controls.

Sources: Sansec (research and IOCs), BleepingComputer (context and summary).

The applicable legal framework

• GDPR — Article 32 (security of processing): duty to implement appropriate technical and organizational measures proportionate to risks, including preventing unauthorized disclosure and controlling outbound data transfers (EUR‑Lex).
• GDPR — Chapter V, Articles 44‑49 (international transfers): any transfer to a third country or international organization is subject to conditions (adequacy, SCCs + supplementary measures, strict derogations). Controllers must “know their transfers” and verify actual access/flows, not just nominal hosting (EDPB Recs 01/2020; CNPD – transfers).

Practical takeaway: automatic exfiltration of payment data (PAN, CVV, address) by a skimmer script breaches Article 32 and, if data leave the EEA or are accessed from a third country, constitutes a transfer under Articles 44‑49 — even if the “main” app is hosted in Europe. The GDPR framework focuses on real flows and access, not server location alone.

The technical solution to deploy

DLP (Data Loss Prevention) properly configured — in addition to patching/WAF and front‑end controls (CSP) — detects and blocks exfiltration of sensitive personal data from browsers, web servers, and business endpoints.

• Outbound (egress) network DLP: inspect Internet‑bound HTTP(S) with content‑aware signatures for card schemas (PAN with Luhn, BIN, IBAN formats), identity data (name+address+ZIP), and custom rules for obfuscation patterns (XOR “script” + base64, no‑cors POST). Block/quarantine IOCs domains/IPs and suspicious paths (/fb_metrics.php), short domain age, unexpected ASN.
• Endpoint/browser DLP: pre‑send content control on web fields, form‑grabbing detection, and policies preventing “card numbers” from being sent to unauthorized origins. Integrations via EDR/XDR agents and managed extensions.
• Mail & API DLP: if teams exchange customer proofs, the DLP engine should prevent sending attachments with PAN/CVV outside the domain/EEA and trigger a DPO review on unusual flows.
• Flow governance: map authorized destinations (allow‑lists for PSPs, monitoring stacks, anti‑fraud, archiving), log blocked attempts, and maintain a cross‑border personal data flows register usable by the DPO.

References: ISO/IEC 27001:2022 Annex A.8.12 (data leakage prevention), A.8.16 (monitoring), A.8.23 (application data security); NIST CSF 2.0 PR.DS (Data Security), DE.AE (event detection); CIS Controls v8 #3 (Data Protection) and #13 (Network Monitoring & Defense).

How Luxgap delivers this

• Our 24/7 managed SOC: we ingest Sansec IOCs (domains, IP 23.137.249.67, paths, _mgx_cv artifact) into SIEM/XDR, correlate with web/CDN/WAF logs and egress firewalls, and deploy pattern detections (XOR “script”, base64, no‑cors POST) specific to skimmers. Explore our 24/7 managed SOC.
• Our ISO 27001 governance: transfer‑mapping workshop with the DPO to align DLP with GDPR Chapter V: allow‑lists of authorized destinations, proportionality evidence (Art. 32), and exportable logs for the CNPD.
• Our dark web monitoring: monitor channels selling card sets/credentials, alert correlated with your DLP events to speed incident triage and, if needed, GDPR Art. 33 notification. Learn more about our dark web monitoring.

Real‑world case in Luxembourg or the EU

A B2C marketplace subject to GDPR and operating multilingual across the EU observed sporadic unexplained cart abandonment. In six weeks we: (1) deployed egress DLP with PAN/Luhn dictionaries and “C2 skimmer” rules (no‑cors POST, young/non‑PSP domains, /metrics//analytics paths), (2) added Sansec/BleepingComputer IOC feeds, (3) aligned the allow‑list of payment‑only destinations (PSPs, anti‑fraud), and (4) enabled browser telemetry on support endpoints. Result: multiple exfil attempts automatically blocked, evidence of no unauthorized transfers for the DPO, and a server remediation plan (PolyShell patch + restrictive “form‑action/script‑src” CSP).

Immediate next steps

1. Block the IOCs today: 23.137.249.67, the 6 Sansec domains, path /fb_metrics.php. Add “POST to unapproved domain” rules on PAN/CVV data.
2. Hunt for artifacts: search for <svg ... onload= with atob() in templates/JS, and the local key _mgx_cv on the front end. Ensure no unknown JS “checkout” overlay intercepts clicks.
3. Map your transfers (EDPB Step 1): list authorized egress destinations for personal data (PSP, KYC, anti‑fraud), distinguish EEA vs third countries, record in your GDPR register and configure DLP accordingly.
4. Patch and segment: apply the Magento/Adobe Commerce fix when available, isolate payment hosting, and harden CSP (form-action, connect-src, script-src).
5. Test your detection: simulate an outbound POST with a test PAN to a “decoy” domain; verify DLP/SIEM alerting, SOC escalation, and DPO’s ability to address Art. 32 and Chapter V (see the GDPR framework).

Go further

Need combined operational and compliance support? Reach out via our contact page.

Official sources

• News and IOCs: Sansec — SVG Onload Tag Hides Magecart Skimmer (07/04/2026); BleepingComputer — Hackers use pixel‑large SVG trick to hide credit card stealer (08/04/2026).
• Regulatory: GDPR Art. 32 & Chapter V (EUR‑Lex); EDPB Recommendations 01/2020 — supplementary measures for transfers; CNPD (LU) — “International Transfers” dossier.