Loading story…
Researchers uncovered Magecart-style web skimming campaigns that concealed malicious JavaScript inside image files to evade detection on compromised e-commerce sites. In one case affecting Magento 2.x stores, injected code retrieved a seemingly legitimate PNG file at /pub/media/wysiwyg/m2themes/googletagmanager.png, extracted data appended after the PNG IEND marker, and executed the hidden payload in the browser to steal payment information entered at checkout.
A related campaign hid skimmer code in EXIF metadata and used image files for data theft, showing attackers were abusing trusted media formats both to stage malware and to exfiltrate stolen credit-card details. Investigators also found the Magento skimmer relied on a booby-trapped GitHub repository, mag202/magento, where malicious mage.png files were repeatedly uploaded and removed to update payloads and derive exfiltration gates tied to lookalike domains such as fontsgoogle-apis[.]com and googletag-manager[.]com, underscoring a broader shift toward image-based concealment and legitimate-platform abuse in web skimming operations.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
7 events from the most recent confirmed update back to the earliest known activity.
The domain fontsgoogle-apis[.]com, later recovered as the skimmer's exfiltration gate in a newer variant, was registered.
A historical April 10 version of app/design/frontend/Magento/luma/media/mage.png in the mag202/magento repository contained JavaScript appended after the PNG IEND marker, hiding skimmer logic and exfiltration details.
A GitHub user named mag202 created the mag202/magento repository, presented as a beta version of Magento 2.4 and later used to host malicious mage.png files.
The domain googletag-manager[.]com, used by an earlier version of the skimmer's exfiltration logic, was registered.
The domain gstatlcs[.]com, later noted as being hosted on the same server as other campaign infrastructure, was registered.
Sucuri reported a Magecart-style campaign on compromised Magento 2.x sites where malicious JavaScript was appended after the IEND marker of legitimate PNG files and executed on checkout pages.
Malwarebytes published analysis of a web skimmer that hid within EXIF metadata and exfiltrated credit card data via image files, documenting a related image-based skimming technique.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
2 references tracked. Mallory keeps watching after this page renders.
Map indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
A large Magecart campaign compromised nearly 100 Magento and Adobe Commerce stores by hiding a full credit-card skimmer inside a **1x1-pixel SVG** embedded directly in checkout page HTML. Researchers said the malware stores its payload in the SVG `onload` handler, decodes it with `atob()`, and runs it via `setTimeout`, allowing it to evade scanners that typically look for externally loaded scripts. When shoppers click checkout, the skimmer displays a convincing fake **"Secure Checkout"** overlay that captures billing and payment details before validating card numbers with the **Luhn algorithm**. The stolen data is exfiltrated as XOR-encrypted, base64-obfuscated JSON to attacker-controlled infrastructure, in some cases disguised as Facebook analytics traffic. Sansec linked the infections to exploitation of the **PolyShell** vulnerability, which affects Magento Open Source and Adobe Commerce stable version 2 deployments and can enable unauthenticated code execution and account takeover. Defenders were urged to hunt for hidden SVG tags and suspicious `onload` code, check for the `_mgx_cv` localStorage key, and block outbound traffic to the identified attacker infrastructure, including domains resolving to **`23.137.249.67`** hosted by IncogNet in the Netherlands.
Jun 29, 2026
Researchers found a compromised **X-Cart** e-commerce site running two separate payment skimmers: a basic server-side stealer and a more advanced client-side JavaScript skimmer. The server-side malware captured base64-encoded payment `POST` data and saved it to a fake `.jpg` file, while the browser-based skimmer validated that a credit card number was present before exfiltrating checkout data to attacker infrastructure. Analysts traced the X-Cart exfiltration path to `metahtmlhead[.]com/folder/ip/zxc.php`, with the destination assembled through DOM-based domain construction to hinder detection. The JavaScript skimmer used layered obfuscation and an anti-debugging technique tied to wrapper-function length, forcing researchers to brute-force parts of the code to recover its behavior. A similar skimmer was later identified on a **Magento 1.x** site, using the same obfuscation style and a matching URL path structure but sending stolen payment data to `winsiott[.]com/folder/ip/stt.php`. The overlap in code design, evasion methods, and infrastructure indicates a broader web-skimming campaign targeting multiple e-commerce platforms.
Aug 15, 2026
Researchers at Sansec uncovered a Magecart campaign that uses trusted **Google Tag Manager** and **Stripe** infrastructure to steal payment data from e-commerce checkout pages. The skimmer is delivered through a malicious but legitimate-looking GTM container and activates on **Magento** and **Adobe Commerce** checkout flows, where it harvests card numbers, expiration dates, CVV codes, names, billing addresses, email addresses, and phone numbers. The malware retrieves additional JavaScript from Stripe customer metadata and executes it dynamically, helping the attack blend into normal traffic to trusted services. The stolen data is obfuscated with **XOR**, stored locally, and later exfiltrated by creating fake customer records in an attacker-controlled Stripe account, causing the theft to appear as ordinary traffic to `api.stripe.com` and potentially bypass content security policies and network filtering. Sansec also identified a variant that uses **Google Firestore** instead of Stripe, pulling payloads from a document named `tracking/captcha` in a project called `braintree-payment-app`. Researchers said the Stripe customer record used to host the skimmer was created on Dec. 24, 2025, indicating the campaign may have been active since at least then.
Jun 29, 2026