An unpatched analytics server put a card skimmer on every Convertr checkout

Between 24 and 27 October 2026, every Convertr checkout loaded code built to copy shoppers' card details. Convertr is a Brazilian platform that runs the online shops and payment pages of dozens of fashion brands. According to research published by Sansec, the e-commerce security firm that spotted it, the code had been appended to the Plausible analytics script that Convertr hosted on a server of its own. It was not in the payment gateway or in any shop's template.

Sansec's best guess at the way in is a critical flaw patched in May, although it cannot confirm it. The tool, installed to count page views, ran on the payment page with the same access as the card form and had gone without an update since 2025.

How did a card skimmer reach the checkout through an analytics tool?

The skimmer arrived hidden in the Plausible tracking file that Convertr served from analytics.convertr.app.br to every merchant checkout on the platform. A web skimmer is a piece of JavaScript that runs in the shopper's browser and copies whatever they type into the payment form, and the industry files these attacks under the Magecart label. Sansec says Convertr installed Plausible Community Edition (CE) 3.0, an open-source alternative to Google Analytics, in 2025 and never upgraded it.

Which route did the attackers probably take?

Sansec points to CVE-2026-8467, a flaw in a developer tool that Plausible CE left reachable in production, while stressing that it has not seen Convertr's server logs. The bug sits in phoenix_storybook, a library used to showcase and test interface components during development. The GitHub security advisory explains that its Playground accepted values sent over WebSocket without authentication, dropped them unescaped into a template, then compiled and evaluated that template with no sandbox. The result is unauthenticated code execution on the server, scored 9.5 under CVSS v4.

Plausible CE bundled the library and exposed it at /storybook in versions 3.0.0 to 3.2.0. Version 3.2.1, released on 15 May 2026, removes the endpoint altogether, and its security note tells anyone unable to upgrade straight away to block /storybook at the reverse proxy. The researcher who found the flaw reported it privately on 11 May. A fix shipped four days later, more than five months before the attack.

What did the injected code do?

The injected code copied the shopper's card details and CPF and sent them to a domain run by the attackers. It left the genuine Plausible script intact and appended an obfuscated block that only woke up when the page address contained Convertr's checkout domain. It then harvested the card number, expiry date, CVV, cardholder name and CPF (Brazil's taxpayer number), reading both the form fields and the calls made to the payment API. Each record was base64-encoded and posted to 1x0.is.

The first build hunted for payment fields using generic patterns. Around 26 October a revised build appeared that used the exact field names of Convertr's payment API. In our reading, that adjustment points to an operator checking the haul, though Sansec does not say so.

How much is known about the attack?

The technical timeline is well documented, but nobody knows how many cards were stolen, and Convertr's account clashes with Sansec's.

How long was the skimmer active?

The skimmer ran for about three days, and browser caching may have extended its reach by up to 24 hours. The last clean copy of the script in Sansec's records dates from 05:03 UTC on 24 October; the firm detected the skimmer at 23:22 the same day. Sansec contacted Convertr before going public and received no reply, and at 15:34 UTC on the 26th, the day Sansec published, the platform was still serving the code. On the 27th Convertr said it had removed the code and upgraded Plausible. At 13:08 UTC that day Sansec confirmed the file was clean again.

Is the number of stolen cards known?

The number of cards captured has not been disclosed. Convertr says, in a figure cited by Sansec, that merchants have sold more than R$2 billion (around €320 million) through the platform. Convertr told Canaltech that no sensitive merchant or customer data had been accessed, a position at odds with Sansec's technical analysis, which BleepingComputer also reported. No public forensic report has yet reconciled the two accounts. Convertr told Sansec it is notifying affected merchants, payment providers and the relevant authorities.

Were other Plausible installs attacked?

At least one other vulnerable Plausible CE install, running 3.2.0, was compromised that same week, although no link to Convertr has been shown. On 23 October an administrator opened an issue in the Plausible CE repository. In their container, a script launched by beam.smp, the Erlang virtual machine Plausible runs on, had started a cryptocurrency miner disguised as a system process and eating about three CPU cores around the clock. The reporter could not pin down the entry point, another user linked Plausible's security advisory, and the issue was closed that day. It was a case of cryptojacking.

Who is behind the attack?

Sansec attributes the attack to a Brazilian Magecart group it has tracked since July 2024, which until now compromised merchants one at a time. It links the group to skimmers on dozens of Magento, OpenCart and WooCommerce stores, almost all in Brazil, some of which carried the code for close to two years. Convertr is the first supply-chain attack the firm attributes to it, and the same collection endpoint, 1x0.is/ws, had turned up a day earlier in a skimmer on another Brazilian store.

The group's fingerprints include short .is domains rotated every few months, Discord webhooks for collecting data and a variant that swaps the QR code of PIX, Brazil's instant payment system, for the attacker's own.

Why did the usual controls miss it?

The usual controls missed it because the script came from a trusted source and the theft happened inside the shopper's browser. From a merchant's point of view, the script came from a domain belonging to its platform, sat among the approved sources of whatever content security policy (CSP) it had and had loaded without trouble for a long time. Analytics servers tend to be filed under marketing, with patching left to whoever set them up. A web application firewall inspects requests reaching the server, whereas here the data left the browser for a third-party domain, well outside its reach.

The vulnerable code was also a development dependency. A component playground has no business on a production server, yet it shipped inside the official image and answered anyone who could reach the host. In organisations with years of accumulated integrations, such pieces often stay on whatever version they had on installation day. A software bill of materials (SBOM) would have made the dependency visible, and an external review of the attack surface could have spotted that /storybook was answering.

Can a skimmer hidden in a self-hosted script be detected?

A skimmer like this can be detected by watching the server that hosts the script, the content the shopper receives and the connections the browser opens.

What should be monitored on the server hosting the script?

On the server, the access logs, the process list and the integrity of served files all need checking. If requests to /storybook turn up, Sansec advises rebuilding the server, rotating secrets and diffing the files in priv/tracker/js/ against the official release.

A shell, wget or curl spawned by beam.smp is hard to justify in Plausible. In the 23 October issue, the miner traced back to an unexpected child of beam.smp, and a well-configured EDR agent or auditd can record it. For served files, a reference hash of the tracking script with an alert when it changes outside a planned upgrade does the job.

Can the script the shopper receives be checked from outside?

What the shopper receives can be checked from the outside, by fetching each payment-page script at regular intervals, hashing it and comparing the result with the approved value. It covers the script side of PCI DSS requirement 11.6.1, which also asks for monitoring of security-impacting HTTP headers. Sansec has also published the SHA-256 of the infected copy from 26 October, which helps with retrospective searches through proxy logs or caches.

Can the browser block the theft?

The browser can block the upload of data through a CSP and the execution of an altered file through Subresource Integrity. A CSP whose connect-src directive lists only the gateway and the merchant's domains would have blocked the upload to 1x0.is. That directive governs fetch, XHR and WebSocket connections, including no-cors requests like the one the skimmer used.

Deployed as Content-Security-Policy-Report-Only, the policy does not block requests but flags the first attempt to reach an unapproved domain. Report URI, a service that collects those reports, argues that report-only mode is enough for the authorisation 6.4.3 asks for and to feed the change detection in 11.6.1, though enforcement gives stronger protection.

Subresource Integrity (SRI), an integrity attribute carrying the script's hash on the tag that loads it, would have stopped the browser from running the altered file. The price is operational, because every legitimate update means a new hash. That makes SRI a better match for self-hosted, versioned scripts, which is what an in-house Plausible is.

What does PCI DSS require for payment-page scripts?

PCI DSS v4 has required two controls aimed at this type of attack since 31 March 2025, as the PCI Security Standards Council has explained. Requirement 6.4.3 says every script on a payment page must be authorised, have its integrity assured and appear in an inventory with a written justification. Requirement 11.6.1 calls for a mechanism that detects unauthorised changes to those scripts and to the security-impacting HTTP headers, as received by the shopper's browser, and raises an alert when they happen.

Are merchants that validate with SAQ A exempt?

Merchants that validate with SAQ A are not exempt, even though both requirements have left their questionnaire. The Council dropped them from SAQ A, the questionnaire for merchants that fully outsource card capture, in a revision published in January 2025 and in force since 31 March. It replaced them with an eligibility condition under which the merchant must confirm that its site is not susceptible to attacks from scripts that could affect its e-commerce systems.

FAQ 1588, from February 2025, lets merchants show this either with techniques like those in 6.4.3 and 11.6.1 or with confirmation from a PCI DSS-compliant service provider. As Report URI points out, a payment provider generally cannot see the merchant page hosting its form, and few will vouch for it. Most merchants therefore end up needing equivalent controls.

Where does responsibility lie when a platform hosts the checkout?

When a platform hosts the checkout for many merchants, as Convertr does, technical control over the script rests with the platform, and the evidence each merchant can produce depends on what the platform monitors. A merchant should therefore ask its platform which scripts load on the payment pages it serves, who approves them and how merchants will hear about a change. That question belongs in third-party risk management.

Where the GDPR applies, for example to a merchant established in the EU, the theft of card details and cardholder names is also a personal data breach. Under Article 33, the platform, if it acts as processor, must tell the merchant without undue delay. The merchant, as controller, must notify the supervisory authority (the AEPD in Spain) within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to the people affected.

Which measures reduce the risk from self-hosted auxiliary tools?

Four measures reduce the risk from components installed once and left in place, such as analytics, heatmaps, support chat, tag managers or A/B testing.

• Whenever its script loads on the checkout, the tool needs an owner and a patch management cycle on a par with the payment system. It then belongs in the 6.4.3 inventory and, depending on the architecture, within PCI DSS scope.
• An analytics server only has to deliver its script and receive events, so the admin panel and development routes can sit behind an address allowlist or authenticated access.
• Gateway-hosted card fields inside an iframe limit what a script on the parent page can read, although they do not prevent other abuse such as replacing the form or the payment QR code.
• Security advisories for each self-hosted open-source project need to reach someone able to act on them. A vulnerability management programme that covers these components, together with an up-to-date view of the external attack surface, closes much of that gap.

For anyone taking card payments, the incident is a chance to test whether the evidence a PCI DSS compliance programme expects is in place. That starts with listing every script on the payment page with its justification and recording which server delivers each one and what version it runs. A web application security audit that includes the client side reaches what server-side testing misses.

Which indicators of compromise has Sansec published?

Sansec has published the exfiltration endpoint, the infected file with its hash and the domains the group used before. They can be checked against proxy, DNS and firewall logs as indicators of compromise.

• Exfiltration endpoint: 1x0.is, path /ws.
• Infected file: analytics.convertr.app.br/js/script.pageview-props.tagged-events.js, SHA-256 ee4618d24737eff785e5a267b55903d5ef6ff7ecbeb099347a67fee77734d7f7 (copy from 26 October).
• Earlier exfiltration domains used by 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 and antiddos-protection.net.

Because the group rotates its domains every few months, these indicators are mainly useful for looking back. For ongoing monitoring, a behavioural rule does more by flagging any outbound request from a payment page to a domain that is not on the approved list.

Where does the payment-script inventory fall short?

The inventory required by PCI DSS tends to fall short on one column, covering the server that delivers each script, its version and who answers for it. As long as the analytics server sits in the marketing column, its version, its exposed routes and its security advisories seldom pass through the same checks as the payment gateway, even though its code runs alongside the card number.

The same pattern surfaced in our five supply-chain lessons for CISOs and in the case of up-to-date WordPress sites that still received a hidden implant.

Sources and attribution: this analysis draws on public disclosures available on 30 October 2026, chiefly Sansec's research, Convertr's statement to Canaltech, the Plausible and GitHub security advisories and PCI SSC documentation. Entry via CVE-2026-8467 is Sansec's unconfirmed hypothesis. Mentioning Plausible does not imply that its current releases are affected by CVE-2026-8467, which was fixed in 3.2.1. Attribution to a Brazilian Magecart group comes from Sansec and may change.

The configurations described (CSP, SRI, integrity monitoring and detection rules) are indicative and should be tested in a pre-production environment first, as an overly strict policy can break the checkout. References to PCI DSS and the GDPR do not replace a Qualified Security Assessor's judgement or legal advice for any specific environment.