Magecart: what it is and how to protect your store, card to Pix

Magecart is the name for attacks that place malicious code on the payment page of a legitimate online store to divert what the customer types or pays. For years the target was the card number. In September 2026, a campaign in Brazil showed the same kind of code swapping the QR code for Pix (the instant payment system run by Banco Central do Brasil, Brazil's central bank). The store stays online, with the right brand and the right price, and the customer sees nothing wrong.

Where the name comes from

The name combines Mage, from Magento, and cart, as in shopping cart. Researchers started using it in the middle of the last decade for the groups that attacked shopping carts on that platform. Over time, the term came to mean the technique itself, on any e-commerce platform, whether on a store's own site or on a third-party service.

What defines a Magecart attack is not the tool used but the place: the page where the customer says how they will pay.

How a Magecart attack works

1. Entry. The code gets in through an unpatched flaw in the platform, a vulnerable plugin or theme, a leaked admin password or a compromised third-party script. In June 2024, a single script service used by more than 100,000 sites started delivering malicious code after it changed owners.
2. Disguise. The snippet is usually a few obfuscated lines and sits inside a legitimate file, an image or a service the store already trusts. In April 2026, researchers found the code hidden in an invisible image on about 100 stores. In June, another family kept the code and the stolen data inside a well-known payment service, so the traffic looked normal.
3. Action only at checkout. The code stays quiet on other pages. When the customer reaches payment, it reads the credit card or debit card fields, or swaps the QR code, the Pix Copia e Cola code (the text version of the payment code that the customer copies and pastes into their banking app) or the linha digitável (the payment number) of the boleto (the Brazilian bank payment slip).
4. Exit. With cards, the data goes to an attacker's server and is used later. With Pix, the customer sends the money to the wrong account, instantly.

The cases that defined the problem

• British Airways, 2018. An altered script on the website and the app copied payment data for about two weeks. The UK data protection authority counted 429,612 people affected and issued a fine of 20 million pounds in October 2020.
• Europol, 2023. An operation coordinated by Europol notified hundreds of online stores in several countries that had card-stealing code active on their payment page, most of them unaware.
• 2026. This year's research shows the code moving to places common defenses don't look: inside images and legitimate payment services, where stores rarely check.
• Brazil, September 2026. The independent researcher known as eremit4 identified, and Kaspersky confirmed, 90 small and mid-sized stores with code that swapped the QR code and the Pix Copia e Cola code at checkout. When the customer chose card, the same code copied the details. The researcher called the case "the new Brazilian magecart". We cover this case in Magecart on Pix.

Why stores take so long to notice

With cards, the sale is approved and the money comes in. The damage shows up weeks later, on the customer's statement, and only when the issuing bank cross-checks several cases does it conclude that they all bought from the same store.

With Pix, the sale simply never comes in. The dashboard shows a pending or abandoned order, and the complaint arrives days later, when the product was not shipped. Merchants hit in 2026 first reported a rise in drop-offs, before they understood what was going on.

In every case, the server may look clean. If the code comes from outside or is assembled in the browser, the copy of the store's files does not change. What changes is what the customer sees.

What PCI DSS requires

Since March 31, 2025, PCI DSS requirements 6.4.3 and 11.6.1 are mandatory for anyone who accepts cards online. Requirement 6.4.3 calls for an inventory of the scripts on the payment page, with a justification and an integrity guarantee for each one. Requirement 11.6.1 calls for a mechanism that detects unauthorized changes to the page and to the security headers, checked at least weekly.

Both were written because of Magecart on cards. They do not mention Pix or boleto, even though the code that swaps a QR code runs on the same page and through the same path. We explain both requirements in PCI DSS 6.4.3 and 11.6.1.

How to protect your online store against Magecart

1. Close the entry points. Update the platform, theme and plugins, and remove what you don't use. Most campaigns exploit known flaws that have already been fixed.
2. Protect the admin panel. Two-factor authentication for every administrator, a review of the accounts with access and new passwords for integrations.
3. Reduce what runs at checkout. Every script on the payment page needs an owner and a reason. Chat, heatmaps and ad pixels rarely need to be there.
4. Prefer card fields hosted by the provider. They reduce the risk of direct copying, but the surrounding page can still show a fake form. See what hosted fields solve and what they don't.
5. Limit where the page can send data. A well-configured content security policy gets in the way of sending data to unknown servers. It does not help when the attacker uses a service the store has already allowed.
6. Monitor the page as the customer sees it. The file on the server can be right while the screen is wrong. See how to monitor checkout changes.
7. Check the payment code on display. For Pix, boleto and stablecoin wallets, compare what the screen shows with what the store issued, before the customer pays.
8. Have a plan for incident day. Who turns off the affected payment method, who talks to the provider, how to notify customers and how to preserve the evidence.

Signs your store may have been hit

• A rise in pending Pix payments, with no matching drop in checkout visits.
• Customers saying they paid and the order was not approved, with a receipt in another company's name.
• A notice from the payment provider or acquirer about cards used in fraud after purchases at the store.
• Files changed when nobody published anything, or an administrator nobody recognizes.
• The payment page sending data to domains the team doesn't know.

If two of these signs show up together, treat it as an incident until proven otherwise.

Where Proteside fits in

Proteside is a cybersecurity layer that checks, on the payer's screen, whether the payment details are the ones the seller issued, and blocks the swap before confirmation. It builds the script inventory that PCI DSS requires and goes further: it compares the QR code, the Copia e Cola code, the boleto number and the card form with what the store generated, on every order, and logs each attempt as evidence. See how it works for credit card and for PCI DSS compliance.