Supply chain
Convertr's own analytics script skimmed checkout cards
A Magecart group planted a card skimmer in the Plausible tracker Convertr serves to every checkout. How it worked, and the script controls that would have caught it.
From October 24 to October 27, 2026, every checkout run by Convertr, a Brazilian e-commerce platform behind the online stores of dozens of fashion brands, loaded a payment card skimmer. The attackers did not touch the merchants' sites or Convertr's checkout code. They changed one file: the web analytics tracker that Convertr hosts on its own self-managed Plausible server and loads on every checkout page. Convertr says merchants have sold more than R$2 billion through the platform.
Sansec, the e-commerce security firm that found it, ties the attack to a Brazil-focused Magecart group it has tracked since July 2024. Until now that group compromised Magento, OpenCart and WooCommerce stores one at a time; this is its first observed supply-chain attack. The skimmer took card number, expiry date, CVV, cardholder name and the shopper's CPF, the Brazilian taxpayer ID. If you run a checkout that loads any third-party or self-hosted script, the controls that would have caught this are the ones PCI DSS now requires on payment pages.
How it works
Plausible is an open-source alternative to Google Analytics. Site owners either use the hosted service or run Plausible Community Edition (CE) themselves, and pages load a small tracker script from that server. Convertr's checkouts loaded https://analytics.convertr.app.br/js/script.pageview-props.tagged-events.js, so whoever controlled that server controlled code running inside every payment page.
The infected file was the stock Plausible tracker with a block of character codes appended. At runtime the codes are turned back into JavaScript and passed to eval. The code checks the page address for checkout.convertr and stays idle anywhere else, which keeps it quiet on the marketing pages most scanners visit. On a checkout it reads the payment form and the payment API requests, joins the values into a pipe-delimited record tagged ctr, base64-encodes it and sends it to https://1x0.is/ws. The first version, on October 24, matched generic card field names. A second version on October 26 targeted the exact field names in Convertr's payment API.
Nothing in the browser looks wrong. The script comes from Convertr's own domain over HTTPS, the analytics still work, and the order goes through. Server-side logs on the checkout show nothing either, because the theft happens in the shopper's browser.
How the attackers likely got in
Convertr ran Plausible CE 3.0, installed in 2025 and never updated. CVE-2026-8467 is a flaw in phoenix_storybook, a component library for Elixir apps that Plausible CE bundles. The library's playground takes attribute values over a WebSocket and drops them unescaped into a HEEx template (Phoenix's HTML template format), which is then compiled and run. Anyone who can reach the /storybook path can run commands as the user running Plausible, with no login.
Plausible CE 3.0.0 through 3.2.0 are affected, release candidates included. Version 3.2.1, released on May 15, 2026, removes the endpoint and changes nothing else. Sansec calls this the suspected entry point and is clear that it is unconfirmed: it has not seen Convertr's server logs. Command execution on the analytics server is enough to rewrite the tracker file, and a public write-up of the flaw notes that the same access exposes the database and application secrets such as SECRET_KEY_BASE, which can be used to forge sessions.
What happened and when
Sansec's last clean copy of the tracker is from 05:03 UTC on October 24. It detected the skimmer at 23:22 UTC that day. On October 26 it published its analysis, and at 15:34 UTC Convertr was still serving the skimmer and had not responded. Convertr reported the skimmer removed and Plausible upgraded at 12:54 UTC on October 27, and Sansec confirmed the tracker clean at 13:08. Convertr says it is notifying affected merchants, payment providers and the authorities.
Browsers can keep a cached copy of the infected script for up to 24 hours, so exposure did not end exactly at cleanup.
What to do
If you sell through Convertr. Ask Convertr in writing to confirm the tracker is clean and when it was fixed, and tell your payment provider and acquirer. Fetch the tracker yourself and search it for indexOf('checkout.convertr') and (0,eval); the October 26 build had SHA-256 ee4618d24737eff785e5a267b55903d5ef6ff7ecbeb099347a67fee77734d7f7. Customers who paid by card since October 24 on a page whose address contained checkout.convertr should ask their bank to block and replace the card and watch for misuse of their CPF.
If you run Plausible CE yourself. Upgrade to 3.2.1 or later. If you cannot do that today, block /storybook at the reverse proxy, which is the workaround Plausible gives. Then search your access logs for any request to that path, for example grep -E '"[A-Z]+ /storybook' /var/log/nginx/access.log*. If you find one, treat the server as compromised: rebuild it, rotate SECRET_KEY_BASE and every other secret in its environment, and compare the files under priv/tracker/js/ with the official release.
Everyone else. Block and alert on 1x0.is and on the group's earlier exfiltration domains in DNS and proxy logs, including 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 and antiddos-protection.net. A hit from a staff machine that placed a test order is a strong sign one of your checkouts is infected.
Why script controls on the payment page matter
PCI DSS v4, the card industry's security standard, added two requirements for exactly this case, mandatory since March 31, 2025. Requirement 6.4.3 says every script that loads on a payment page must be inventoried, authorised, justified in writing and protected by an integrity check. Requirement 11.6.1 asks for an automated way to detect unauthorised changes to the page and its HTTP headers as the browser receives them, run at least weekly or at a frequency set by your own risk analysis.
Each of those would have caught or blunted this attack. An analytics tracker is a hard script to justify on the page that takes a card number; removing it from checkout ends the risk. If it stays, a Subresource Integrity (SRI) hash in the script tag makes the browser refuse any file whose contents no longer match, and a self-hosted tracker only changes when you upgrade it, so the hash is easy to maintain. A Content Security Policy (CSP) whose connect-src and img-src list only your own and your payment provider's domains would have stopped the browser sending data to 1x0.is. A weekly change check that compares the scripts each checkout loads against the inventory would have flagged the new code within days.
The analytics server also needs to be patched like a production system, because it effectively is one. A patch that sat available for five months on a box that nobody counted as part of checkout was, by Sansec's best guess, the way in.
Our web penetration testing covers what loads on your checkout and where it can send data, and compliance and audit readiness can build the script inventory and change detection that 6.4.3 and 11.6.1 ask for. Open the chat and Yaali, our AI agent, will pass your question to an engineer.
Sources: Sansec, BleepingComputer, Plausible CE v3.2.1 release notes, CVE-2026-8467 at Kodem, CVE-2026-8467 advisory note, Report URI on PCI DSS 11.6.1, Clover on PCI DSS 6.4.3 and 11.6.1.