cyberx_█
← back to indexCompliance & Regulation14 min read

The QR Code Swapped Inside the Store

A script injected into Brazilian online stores swaps the Pix QR Code and the copy-and-paste string at the moment of payment, for the exact amount of the purchase. There is no flaw in Pix: the payer's only defense is the payee name that Central Bank rules require the app to display — and that is precisely the name e-commerce has made impossible to verify.

Robert F.
The QR Code Swapped Inside the Store
▸In this article

On 1 September 2026, an independent researcher who publishes as eremit4 released an analysis of a Brazilian skimming operation that had always done the same thing — steal card data at checkout — and had now started doing something else. In code collected from a recently compromised store there was a new routine, dedicated to replacing the Pix QR Code the moment the customer chose to pay with it.

Eight days later, Kaspersky confirmed his work and put a number on the finding: ninety small and mid-sized online stores infected in Brazil — eyewear retailers, auto parts, fashion and crowdfunding sites — with the campaign active since June 2025 and six command-and-control domains live. On 12 September, Procon-SP issued a consumer alert.

The press treated the case as the "new QR code scam," and that is where the description falls apart. There is no sticker pasted over a code on a restaurant table, no virus on the payer's phone, and no flaw in Pix. What happened was the compromise of the store's website. The payer is hit as a consequence — and every customer of that store is exposed at the same time, because the malicious code does not live on anyone's device, it lives on the page.

The researcher himself writes the sentence the coverage should have copied: "there is no vulnerability in Pix itself." The attack never touches the payment system. It touches what the screen shows you before you pay.

Three numbers that measure different things

Three figures are circulating about this case, and they are not the same measurement. Adding them up, or using one in place of another, produces a number that does not exist.

  • 107 is the cumulative result count from the hunting rule the researcher maintains to locate new victims, read off the detection chart reproduced in the article, whose window runs from 15 January 2025 to 15 April 2026 in seven-day intervals. It counts detections of the active script, not stores.
  • 41 is the number of anonymized stores that can be counted in the interactive graph published alongside the research, identified there only as "Victim 1," "Victim 2," and so on — the tally is ours, made over what the graph shows. It is the subset he was able to tie to the same campaign with confidence.
  • 90 is the store count produced by Kaspersky, using its own method, when verifying the finding.

Three slices, three methods, three moments. The only honest use is to say where each one comes from.

What the script does, and why no one notices

The design is economical, and the principle is worth understanding — not the step-by-step.

The code stays entirely inert until the page loaded is the order confirmation. Once there, it searches the screen for the thank-you message the store displays to the customer after the purchase; only when it finds that text, and confirms it is visible, does it act. Because many stores render the QR Code after the page has already loaded, the script also installs a watcher that re-runs the check on every change to the page structure.

Then comes the elegant part, and it is what explains why the scam leaves no visual trace: to generate a charge that does not look out of place, the script needs the exact amount of the purchase — and it does not try to read it from the price written on screen. It takes that value from the data layer the store itself feeds to its analytics tools, which is clean, standardized and reliable. With the number in hand, it asks the attacker's server for a QR Code and a copy-and-paste string for the identical amount, and swaps both into the page.

The customer sees a normal-looking code, for the right amount, at the right store, at the right moment. They scan, they pay, and the money goes to an account with nothing to do with the purchase.

The rest of the arsenal belongs to someone who does not want to be studied: the code disables browser console functions to obstruct anyone inspecting it, and the exfiltration of card data, besides going straight to the attacker's servers, also runs through a Discord webhook — a channel that only accepts writes and returns nothing of what has already been sent, which protects the stolen material even when the address is discovered, and neutralizes the kind of response that has worked before against operations built on Telegram bots. The researcher also notes signs of code written with AI assistance: detailed comments in Portuguese, decorative headers and formatting that is a little too uniform.

The classification he gives the whole is the most useful one for anyone who needs to name the problem: swapping the QR is not credential theft, it is manipulation of data in transit. A different attack family, a different kind of defense.

Do not confuse this with the Magento zero-day

In the same week, a second story with the same ingredients hit the news, and the two have already begun to be told as if they were one. They are not.

Pix skimmerStyleSmuggler (CVE-2026-75650)
Who reported iteremit4, on 01/09; Kaspersky confirms on 09/09Sansec, on 05/09
Active sinceJune 2025Probing on 23/08/2026; first confirmed exploitation on 04/09/2026
ReachBrazilian storesMagento 2.4.4 through 2.4.9, global
What it installsCard skimmer and QR-swapping moduleRust backdoor, web shells, remote access tools
Does it cite the other?Kaspersky names no CVE at allSansec mentions neither Brazil nor Pix

The arithmetic settles it on its own: a flaw exploited from 4 September 2026 onward cannot be the entry point for a campaign that has been running since June 2025. Kaspersky attributes the compromise to unmaintained Magento installations, generically, and points to no specific flaw.

For store operators, the distinction is the practical takeaway of the week: anyone who applied Adobe's emergency fix is not protected against the Pix skimmer, and anyone who cleaned out the skimmer is not protected against the zero-day. They are two problems, and each demands its own work.

The defense exists, and it is mandatory

There is one thing the banking app is required to do before you confirm a Pix read from a QR Code, and it is written into the Manual de Requisitos Mínimos para a Experiência do Usuário, one of the documents that make up the Pix Regulation. The version in force is 7.3, from December 2025.

The rule is blunt: before payment confirmation, "the paying user must be shown the DICT data on the receiving user" — name, masked CPF or unmasked CNPJ, and the amount read from the code. Where it is a CNPJ, the name displayed must be the company's trade name and, failing that, its legal name. The payee's branch and account number must not be returned. And there is a lock that matters in this case: the payer "may cancel the payment, but may not edit data read from the QR Code."

The same duty applies to dynamic QR codes, immediate or due-date, with the debtor's data added where provided. In other words: whatever the form of the code, the rule orders the app to query DICT and show who is going to receive the money.

This is why Procon-SP's guidance — check, in the app, whether the name and CNPJ match the store — is not boilerplate advice. It is technically precise. The code can be swapped; the name that appears on screen belongs to whoever will actually receive the money, because it comes from the directory, not from the code that was read.

The defense, then, exists. It is mandatory. And in e-commerce, it does not work.

Why it fails exactly where it is needed most

The problem is that in an online purchase, the name that appears is almost never the store's.

Most merchants do not receive Pix in their own name: they receive it through a payment service provider, a sub-acquirer, a gateway. The name DICT returns is that institution's — a legal name the buyer has never seen, that is not written anywhere on the storefront, and that they have no way to validate. The screen complies with the rule to the letter and still tells the buyer nothing that would let them decide.

Procon-SP's own alert admits as much, in the caveat it is forced to make. The consumer should check whether the data matches the company they bought from —

"or, where the payment is processed by a payment institution, whether it correctly matches the company or institution indicated in the payment process."

The sentence is honest, and it is also a confession of the gap: to follow the guidance, the buyer would have to know in advance which third party is the legitimate one.

On the other side of the counter, Kaspersky arrives at the same place by another route: among its recommendations to merchants is to be transparent and enter the real payee's details. It is the same gap, seen from the seller's side.

And the researcher describes the behavior that closes the circuit: the customer is following a routine they have carried out hundreds of times, and rarely stops to read. The rule forbids showing branch and account, which protects the payee's privacy and, in the same gesture, removes the second reference point that would have been left.

The only defense the rules give the payer is a screen that the payment facilitator model has rendered illegible.

Once the money is gone, a different clock starts

When the wrong Pix has been paid, the instrument is the Mecanismo Especial de Devolução (MED). And here the chain of rules deserves to be assembled in full, because it almost never is.

The MED originates in Resolução BCB nº 103, of 8 June 2021, which inserts into the Pix Regulation the section and Article 41-B defining the mechanism for cases of well-founded suspicion of fraud and of operational failure. It took effect on 1 November 2021, with effects from the 16th.

Four years later, Resolução BCB nº 493, of 28 August 2025, adds the funds recovery functionality, defined as a "procedure for tracing, blocking and returning funds within Pix arising from suspected fraud in the transaction." It has been optional since 23 November 2025 and mandatory since 2 February 2026 for institutions operating as transactional account providers and as special settlement agents.

The detail that usually gets lost: Resolution 493 sets neither a deadline nor a number of layers. Article 41-E expressly delegates to the DICT Operational Manual the maximum blocking and return deadlines and the tracing mechanism itself. The numbers, therefore, live in the manual — the 80-day contestation window, in force since 1 September, and the field that now states which layer of the tracing graph a transaction sits in, mandatory from 26 October.

One correction along the way, since Procon-SP's alert repeats it: saying that "the MED deadline went from 30 to 80 days" misdescribes what changed. The victim's window was always 80 days; what existed was an asymmetry, and what ended was the asymmetry — whoever has funds clawed back now also has 80 days to contest it.

And this is exactly where the rules and the attack meet. The researcher observes that a contestation only takes effect while the funds are still in the account that received them — and that in this scam the victim has no reason to suspect anything, since the purchase went through normally. Time works for whoever received the money. Tracing the subsequent layers is the answer the Central Bank built for this specific problem, and it is still far too recent to judge.

The merchant, and the order that looked abandoned

There is a side effect that explains how this campaign ran for fifteen months without becoming a scandal.

For the store, the order is created normally — and the payment confirmation simply never arrives. The transaction sits pending, or abandoned, among all the carts that really were left behind unpaid. There is no error on screen, no alert, no declined transaction. There is one more cart in a queue every e-commerce operation has.

The discrepancy tends to surface by the worst possible route: when the customer calls asking why the order they paid for was never shipped. On a peak date in Brazilian retail, a short window already means a large loss — and a queue of customers convinced, quite rightly, that they paid.

Hence the recommendation worth printing and pinning to the wall, and it comes from both sides of the reporting: reconcile confirmed Pix payments against order status, with automatic alerts for anything past the expected settlement time. Monitor the integrity of the checkout page too, because the manipulation happens in the customer's browser and watching only the server sees nothing. And treat admin panel credentials as critical assets, with two-step authentication and rotation — including, and especially, those of technology vendors that administer several stores, where a single compromise becomes a supply-chain incident.

What the law calls this

One item the coverage of this subject missed, and which changed this year.

Article 171 of the Penal Code received new wording for § 2º-A through Lei nº 15.397, of 30 April 2026, published in the Official Gazette of 4 May. Electronic fraud, punished with 4 to 8 years' imprisonment, now expressly covers fraud committed through the "duplication of an electronic device or internet application." The penalty in the caput did not change: it remains 1 to 5 years, and what the law did there was rewrite the provision without touching the range. In the same article it created the offense of lending out a straw-man account — assigning a bank account, for free or for money, so that proceeds of criminal activity may move through it — and repealed § 5º, added in 2019, which allowed prosecution only upon the victim's complaint, except where the victim was the Public Administration, a child or adolescent, a person with a mental disability, someone over 70, or otherwise legally incapable.

By the letter of that wording, duplicating a store's payment page to divert the amount fits the offense — and this is a reading of the statutory text, not an assertion of charges, which depends on the specific case and on who analyzes it.

It is also worth knowing where to file the report: since Lei 14.155/2021, Article 70, § 4º, of the Code of Criminal Procedure establishes that, in Article 171 offenses committed through funds transfers, jurisdiction is determined by the victim's domicile. The injured party files where they live, not where the store is.

In one line

There is no flaw in Pix. There is a compromised page, a screen the rules mandate and e-commerce has made illegible, and a clock that runs faster than the contestation.

Sources

The research and the confirmation

The Magento zero-day, which is a different story

The Pix rules

Criminal law

About the author

Robert F.

Robert F. is the founder of CyberX, a digital intelligence operation applied to investigation, based in Brazil with cross-border reach.

He works in OSINT, on-chain tracing and antifraud for legal teams, corporate compliance, banking antifraud and public authorities.

In CyberX publications we write about what can be said in public — fraud and scam typologies, digital threats, on-chain tracing, regulation, and what separates an investigation from a database lookup. Never about a case we work on, clients, matters under judicial secrecy, or operational detail that would compromise an investigation in progress — ours or anyone else's. A third party's case enters through the public official act, and through what it teaches, not through what it exposed.

Related reading

CyberX works in digital intelligence applied to investigation — OSINT, on-chain tracing, and fraud prevention. This content is informational and does not constitute legal advice.

how we write →