Saturday, 31 October 2026Global tech news & guides — what changed, and what it means for you.

A Hijacked Analytics Script Skimmed Brazilian Shoppers’ Cards

A Hijacked Analytics Script Skimmed Brazilian Shoppers’ Cards

In brief

  • A Magecart group hid a card skimmer in Convertr’s analytics script, stealing card numbers and CPFs from Brazilian checkouts since October 24.
  • Sansec, the security firm that found it, says a notorious Brazilian Magecart group active since 2024 planted the skimmer in Convertr’s analytics script file. From October 24, checkouts on affected stores sent card details and CPF numbers to an attacker-controlled domain.
  • The skimmer stole card numbers, expiration dates, CVV codes, cardholder names, and CPF taxpayer identification numbers — the full set needed to use a card or impersonate its holder.
  • Convertr removed the skimmer and upgraded its Plausible analytics installation to a patched version on October 27, and Sansec confirmed the tracker clean the same day. But browser caching can keep the malicious script active for up to 24 hours after cleanup, so shoppers should clear their cache before ordering again.
  • If you paid by card on a Brazilian store whose checkout page contained “checkout.convertr” since October 24, contact your bank immediately and ask to block the card.

The script every store trusted

Every online store loads third-party scripts: analytics, chat widgets, payment helpers. Shoppers never see them, and stores rarely audit them after installation. That shared trust is exactly what this attack exploited.

Convertr is an ecommerce platform, and its analytics script — the file that records page views and events — loads on every page of every store that uses it, including checkout pages. Sansec found that a Magecart group had planted a card skimmer inside that script: the file at analytics.convertr.app.br/js/script.pageview-props.tagged-events.js. From October 24, any shopper who reached a Convertr checkout while the poisoned script was live had their payment details silently copied to the attackers’ server at 1×0.is, alongside the legitimate checkout submission. The shopper saw nothing wrong. The order went through. The theft rode along invisibly.

The skimmer was not a generic sniffer. Sansec’s analysis shows it was wired to Convertr’s own checkout: it watched for the string “checkout.convertr” in the page address, then collected the payment form’s contents. It also hid its payload with a classic obfuscation trick — building code character by character at runtime — which is why a casual glance at the script would not have revealed it. Sansec published a full indicator list, including the exfiltration domain, the infected file’s SHA-256 hash, and a set of earlier exfiltration domains tied to the same group, so defenders can hunt for the same fingerprints elsewhere.

The group behind it is not new. Sansec describes it as a notorious Brazilian Magecart group active since 2024, with a trail of earlier exfiltration domains. That history matters for how seriously to take the exposure window: this was not an opportunistic defacement, it was a working card-theft operation run by a group with a track record.

The timeline, day by day

Sansec’s published timeline pins the incident down precisely, and the dates are what turn a scary headline into a concrete exposure window.

On May 15, 2026, Plausible — the analytics software Convertr’s tracker is built on — fixed CVE-2026-8467 in version 3.2.1 of its Community Edition. That detail matters because it shows a patched version existed months before the attack; Convertr’s October 27 upgrade to a patched version closed a gap that had been open since at least May.

On October 24 at 05:03 UTC, Sansec observed the last clean copy of the Convertr tracker. By 23:22 UTC the same day, Sansec had detected the skimmer. The window between those two observations is when the poisoned script went live — meaning shoppers who checked out on affected stores from October 24 onward were exposed.

On October 26, the skimmer was updated to target the Convertr payment API specifically, and at 15:34 UTC Convertr was still serving the malicious script. Sansec published its analysis that day. On October 27 at 12:54 UTC, Convertr reported that the skimmer had been removed and Plausible upgraded to a patched version; at 13:08 UTC, Sansec confirmed the tracker was clean.

That gives a clean exposure window with a dirty edge: October 24 through October 27 for the server-side script — plus up to 24 hours of browser-cached copies after cleanup, which is why Sansec’s cache warning is not a footnote but part of the incident itself. A shopper who visited an affected store on October 27, after the server was cleaned, could still have loaded the poisoned script from their own browser’s cache.

Why one script compromises every store

The uncomfortable lesson of this incident is architectural, not moral. Nobody at the affected stores did anything wrong, and no shopper clicked anything suspicious. The compromise happened one level up: at the shared script provider.

When a store embeds a third-party analytics script, it hands that script the same page privileges as its own checkout code. The script can read form fields, including card numbers, because the browser does not distinguish between “the store’s code” and “the analytics company’s code” once both run on the same page. Security teams call this the supply-chain problem: you do not just trust your own code, you trust every script your pages load, and every script those scripts load in turn.

That is why this incident scales the way it does. Compromising one store yields one store’s shoppers. Compromising a shared analytics script yields every store that loads it. The same pattern has hit other shared components — chat widgets, tag managers, payment plugins — and the defense is the same in each case: treat third-party scripts on payment pages as part of your attack surface, pin them to known-good versions, and monitor them for changes.

For shoppers, the parallel lesson is that “I only shop on legitimate stores” is not a complete defense. The store was legitimate. Its analytics script was not, for three days. The defenses that actually work at the shopper level are the ones that limit what a stolen card number is worth: virtual or disposable card numbers that expire after one transaction, transaction alerts that fire the moment a charge posts, and a bank that can kill a card in minutes rather than days.

What shoppers should do now

If you paid by card on a Brazilian store whose checkout page address contained “checkout.convertr” at any point since October 24, take these steps in order.

First, contact your bank immediately and ask to block the card. BleepingComputer’s reporting carries the same advice from Sansec’s findings, and it is the only step that fully neutralizes a stolen card number. Do not wait for a fraudulent charge to appear — the skimmer captured everything needed to use the card, including the CVV, and the CPF number alongside it raises the identity-theft stakes beyond a simple card replacement.

Second, clear your browser cache before placing any new order on an affected store. Sansec warns that caching can keep the malicious script active for up to 24 hours after Convertr’s cleanup. A cleared cache forces your browser to fetch the current, clean script. This step is easy to skip and exactly the one that matters most in the day after a cleanup announcement.

Third, review your recent statements for charges you do not recognize, and turn on transaction alerts if your bank offers them. Watch for small test charges as well as large ones: card thieves often validate a stolen number with a small transaction before using it in earnest.

Fourth, for future online shopping, consider disposable virtual cards where your bank offers them. A virtual number that expires after one transaction is worthless to a skimmer even if it is captured, which converts this entire class of attack from a card-theft incident into a non-event.

Store owners on Convertr should note the other half of the lesson: confirm you are serving the patched tracker, and audit which third-party scripts run on your checkout pages. The question to ask of every script on a payment page is simple — does it need to be there, and would you notice if it changed? If the answer to the second question is no, that script is an unmonitored dependency on your most sensitive page.

What is still unknown

Three things remain open, and honest coverage should say so rather than fill the gaps.

First, how the attackers first compromised the script is not detailed in Sansec’s published account. Whether they exploited the unpatched Plausible version, another vulnerability, or a credential is not something the public record currently establishes, and this article does not guess.

Second, Convertr had not responded to BleepingComputer’s request for comment at the time of its October 27 report. The company told Sansec it was notifying affected merchants and payment providers, but a full public statement with a merchant-facing timeline has not yet appeared. If one lands, it may revise the exposure window or the affected-store count.

Third, the number of affected shoppers is not public. Sansec’s indicators and the October 24 start date define who is at risk, but no total has been published. Shoppers should act on the date-and-URL test — checkout.convertr in the address since October 24 — rather than waiting for a count that may never come.

The pattern to watch is whether other platforms running the same analytics software check their own scripts. A shared-component compromise is rarely a one-off: the same group, the same technique, and the same unpatched dependency tend to surface again at the next platform that has not yet looked.

Sources

Last verified: October 28, 2026.

Shoaib Hassan

Shoaib Hassan is the founder and editor of AuTechWire, an independent technology publication covering broadband, mobile networks, privacy, startups, and consumer tech.

Leave a Comment