Magecart is Back in 2025: Learn About Its Latest Hiding Place

Veteran web skimmer now disguised in <img> tags

Cybersecurity experts recently identified a new twist on the Magecart attack targeting e-commerce platforms. It involves embedding malicious code within seemingly harmless HTML image tags, and using techniques such as Base64 encoding (a standard method) to conceal its malicious intent. In this post we explore the latest in a long line of tactics that have kept Magecart alive, but first…

What is Magecart?

If you haven’t heard of Magecart before, it’s a cyberattack where hackers inject malicious code, typically JavaScript, into a website to steal sensitive information like credit card details, personal data, or login credentials. The term “Magecart” is a portmanteau of “Magento” (the open source e-commerce platform) and “shopping cart”, and it originally referred to a loose collective of hacking groups known for pioneering this style of attack against many shopping platforms, but it’s now commonly used to describe the attack method itself or web-skimming attacks in general.

Here’s how it usually works:

The attackers first exploit vulnerabilities in a website’s code, third-party plugins and services, or scripts from external vendors to insert a “skimmer.” This piece of software quietly captures data entered by shoppers—the digital equivalent of someone looking over their shoulder as they type info into a checkout page. The stolen data is then sent to a server controlled by the attackers.

Defending against Magecart involves continuously scanning the website for vulnerabilities, detecting and investigating any potentially malicious code changes that could indicate web-skimmer injection, and monitoring any data being sent to suspicious domains (all of which Reflectiz provides).

What makes Magecart attacks tricky to uncover is the stealth aspect; users often don’t notice that anything is wrong, and the website might look and behave perfectly normally. There are various methods attackers use to maintain this low profile so let’s break them down:

Obfuscation: Hackers scramble the malicious code—using techniques like minification, string encoding (like Base64 as we mentioned), or custom encryption—to make it unreadable to humans and harder for security tools to flag. The functionality of the thieving code remains intact, but it looks like gibberish or benign at first glance. (Reflectiz has a built-in deobfuscator to reveal what it’s really up to though.)

Dynamic Injection: Attackers often avoid hardcoding the skimmer into the website’s source. Instead, they use external scripts hosted on attacker-controlled domains (sometimes mimicking legitimate ones) that load the malicious payload at runtime. This reduces the footprint on the compromised site and complicates static analysis by security scanners.

Using Legitimate Libraries: Embedding malicious code within popular JavaScript libraries (e.g., jQuery) or disguising it as a legitimate update to a third-party script is a common tactic. This makes the skimmer blend into the site’s normal operations, and security teams might overlook it amidst trusted code.

Timing and Delays: Some Magecart variants use conditional logic, such as activating only after a set time, on specific pages (e.g., checkout), or after certain user actions (e.g., clicking “submit”). This evades detection by tools that perform quick or surface-level scans, as the malicious behavior isn’t immediately apparent.

Cookie and Session Management: By leveraging cookies or hijacking user sessions, attackers can mask their activity. For example, they might store parts of the skimmer logic in cookies or use session data to trigger the code, avoiding direct exposure in the site’s codebase.

Exploiting Third-Party Services: Magecart attackers frequently target supply chain vulnerabilities, compromising third-party scripts (e.g., analytics tools, chat widgets, or payment processors) that websites rely on. This allows them to inject skimmers without touching the primary site, making attribution and detection harder.

Using HTTPS: Serving malicious code over HTTPS is standard practice to avoid raising red flags with browsers or security tools that block or warn users about insecure HTTP traffic.

History of Magecart Attacks

Some sources say that Magecart attacks emerged as far back as 2010, but 2015 is generally accepted as the time when large-scale attacks became widespread. British Airways Is a notable victim that exposed the data of half a million customers in 2018, and a Magecart attack at Ticketmaster that same year also ran into the hundreds of thousands. Ticket vendors make particularly attractive targets, which explains why See Tickets was breached in 2022 and then again in 2023.

Attackers aren’t choosy, though, and smaller companies are as much at risk as larger ones. New York-based car accessory business iOttie was breached in 2023, compromising just 241 sets of customer payment details. Small pickings for the criminals, perhaps, but equally damaging for the company when you consider that PCI DSS noncompliance penalties begin at $5000 per month and GDPR fines for less serious offenses start at €5 million or 2% of the company’s annual global revenue, whichever is higher. Then there is the loss of revenue that comes with the loss of customer trust and the potential for class action lawsuits by data breach victims.

Magecart Disguised in an <img> Tag

One of the reasons why Magecart has persisted for so long is hackers’ willingness to adapt. They are always coming up with new ways to hide their malicious code, and the <img> tag approach is among the latest.

In this case, attackers chose to hide the malware inside an <img> tag, probably because these tags often contain long strings so at first glance they don’t arouse suspicion. The Base64-encoded content points to JavaScript code that’s activated when a ‘onerror’ event is detected. The onerror function is triggered when an image fails to load, and it tells the browser to show a broken image icon, but in this case, the onerror event has been modified to run the malicious JavaScript as well as just respond to the error.

Browsers automatically trust the onerror function and the <img> HTML element is generally considered harmless, but in this case, it’s anything, but. Once activated, the malware waits until the user is on the checkout page and then dynamically inserts a fake form to capture their card number, expiration date, and CVV, before exfiltrating it to an external domain.

Prevention Tactics

On average, it takes 171 days to expose a Magecart attack, largely because standard security controls like Web Application Firewalls (WAF) are not designed to detect these client-side threats. Effective defense requires specialized approaches focused on monitoring JavaScript behavior.

Organizations can protect themselves through several key strategies:

Continuous monitoring of all scripts and third-party components running on websites to detect suspicious activities like unauthorized code changes or communication with unusual domains.
Behavior analysis of web elements in real-time to identify potential threats, particularly those using sophisticated obfuscation techniques.
Comprehensive visibility across the entire user journey—from landing page to checkout—to protect all sensitive areas, not just payment forms.
Intelligent alert systems that prioritize notifications based on risk severity, enabling quick response before significant damage occurs.

Several security solutions, including tools like Reflectiz, offer these capabilities through continuous monitoring and third-party risk detection systems. The most effective solutions combine lightweight implementation with robust detection capabilities to defend against the ever-evolving tactics of Magecart attackers, who tend to increase activity during high-traffic periods like the holiday season but remain threats throughout the year.

Implementing specialized security measures is essential for any organization handling sensitive customer data online, particularly those operating e-commerce platforms.