The 1x1 pixel that steals cards: the new Magecart attack in Magento

A data theft operation has endangered about a hundred online stores that work with the Magento platform: the malicious code that removes card numbers is hidden in a pixel and disguised as a Scalable Vector Graphics (SVG) element. The investigation that brought this campaign to light was published by the security firm eCommerce Sansec, whose technicians detail how attackers manage to inject and run the skimmer without leaving external references that many detection tools do mark.

The technique is apparently simple and at the same time ingenious: the skimmer lives entirely in line within a 1 × 1 pixel SVG that includes an attribute onload. That handler contains the payload encoded in base64, decoded withatob ()and then run by a timer; thus the labels are avoided< script >and most automated scanners don't easily detect it. Sansec describes this tactic as a way to keep all malware "encapsulated" in a single attribute, without references to files outside the site.

In practice, when a legitimate buyer presses the payment button in a compromised store, a malicious JavaScript intercepts that action and shows an emerging window that simulates a secure payment process. The overlap includes the usual fields for card data and billing and makes real-time checks - for example verification with Luhn's algorithm - to validate that the numbers presented seem correct. The captured data are packed in JSON, they are obfuscan with base64 and in addition simple operations such as XOR are applied before they are sent to the attacker.

Sansec tracked the exfiltration to six domains receiving the information and found that all were housed in IncogNet LLC (AS40663) in the Netherlands, with each domain receiving data from between ten and fifteen confirmed victims. In related campaigns the attackers had even used WebRTC as an output channel to avoid detections based on classic HTTP requests.

The researchers believe that the gateway to this wave was holdings of the vulnerability known as PolyShell, published in mid-March; this failure affects the facilities of Magento Open Source and Adobe Commerce in stable versions 2.x and allows the execution of unauthenticated code and the taking of accounts. For now, Adobe has only included the correction in a pre-release version (2.4.9-alpha3 +), so many production shops remain potentially vulnerable. For a context on the gravity and background of these "Magecart" type attacks, see the general entry on the phenomenon. in Wikipedia.

Sansec indicates a number of specific signals and actions for store managers that can help detect and mitigate this attack. Among the most direct tracks is the presence of SVG tags with an attributeonloadwho invokesatob (); that chain is a good starting point for looking for injections. Another commitment mark to review in the browser is the existence of the key_ mgx _ cvin localStorage, since your presence may indicate that the payment data have been stored by the malicious load. It is also recommended to monitor and block requests on unusual routes such as/ fb _ metrics.phpor domains that pass through analytical services and, if necessary, filter traffic to IP 23.137.249.67 and related domains.

In addition to these specific detections, operational measures should be implemented without delay. If the site is vulnerable to PolyShell, it is essential to apply all available mitigation immediately and, where feasible, update to the version that includes correction or move to a safe branch. Managers should review file integrity on the server by comparing with clean known copies, audit accounts and administrative credentials, force password and API key change, and apply rules in the WAF to block inline injection patterns. It is also good practice to notify payment providers and prepare a customer response plan if data theft is confirmed; PCI and data protection laws require some coordinated responses.

For regular buyers there are simple precautions that reduce risk: use external payment methods where possible (e.g. services that touch the card), prefer virtual or single-use cards for online purchases and monitor the movements in the bank extract after buying. If a pop-up window that rerequests the card's data appears to be "strange" in the store's flow appears when paying, it is appropriate to close the operation and contact the trade on another channel before trying to pay again.

At the institutional level, this incident underlines the need for platform providers to act quickly in the face of critical vulnerabilities and for operations teams to maintain detection processes that do not depend solely on signatures in external files. Tools that inspect inline scripts, server integrity controls and a deployment strategy that limit direct changes in production help reduce the attack surface.

If you want to go into the original technical report, the Sansec publication contains the samples and diagrams of the payload: Sansec - SVG onload Magecart skimmer. To better understand the algorithm that skimmers use to validate card numbers in real time, the explanation of the Luhn algorithm is available in Wikipedia. And to check the version and documentation notes of Adobe Commerce, see the release notes section of the platform at Adobe Commerce release notes.

This episode is a reminder that threats in electronic commerce are not always hidden in obvious files or in calls to external domains; sometimes the threat is in a pixel and depends on how quickly administrators and suppliers apply patches and controls so that pixel is no longer a trap.