Enterprise Cybersecurity IntelligenceWednesday

An enterprise cybersecurity intelligence company.For security and technology leaders.

Security.io
Security.io Intelligence

What changed, why it matters,
and how it evolved.

Supply Chain · Executive briefing

Convertr skimmer turns analytics governance into payment-incident response

A compromised Plausible analytics file loaded malicious payment-skimming code into Convertr checkout paths, demonstrating how one shared script can propagate fraud across otherwise separate merchants.

By Security.io Intelligence Desk · Published Wednesday, 28 October 2026

Supply ChainData ProtectionApplication Security
Why it is in today’s brief

The older Plausible flaw alone would not qualify. What changed was evidence of an active shared-script compromise, a payment-API-specific skimmer update and 27 October cleanup confirmation accompanied by exact indicators. It warrants inclusion because merchants now have a concrete hunt and notification decision, while the propagation path demonstrates material software-supply-chain risk beyond a single vulnerable server.

Read first

Sansec identified payment-skimming code in a Plausible analytics file served from Convertr infrastructure and published exact indicators. Convertr subsequently reported the skimmer removed and Plausible patched, but merchant exposure, transaction counts and cached execution remain unresolved.

Act now

Search web and proxy logs for the published script URL and exfiltration endpoints.

Accountable owner

Digital-commerce CISO with application security, fraud, payment, privacy and merchant-platform owners

Decision horizon

Hunt immediately; determine merchant, transaction and notification scope within 24 hours.

AssessmentMedium confidence
Emerging riskWatch for merchant notifications, payment-provider findings, quantified transaction exposure and additional compromised shared scripts.

What happened

Sansec recorded the last clean Convertr tracker at 05:03 UTC on 24 October 2026 and detected the skimmer at 23:22 UTC the same day. On 26 October 2026, Sansec observed the skimmer updated to target Convertr’s payment API. At 12:54 UTC on 27 October 2026, Convertr reported the skimmer removed and Plausible patched; Sansec said the tracker was clean at 13:08 UTC. Sansec suspected exploitation of CVE-2026-8467 in an outdated self-hosted Plausible Community Edition deployment, but that initial-access mechanism was not confirmed.

The infected file was https://analytics.convertr.app.br/js/script.pageview-props.tagged-events.js with SHA-256 ee4618d24737eff785e5a267b55903d5ef6ff7ecbeb099347a67fee77734d7f7 on 26 October. Sansec published https://1x0.is/ws and https://1x0.is/ws/ as exfiltration endpoints, with indexOf(‘checkout.convertr’) and _s+=String.fromCharCode(_a[_i]);(0,eval)(_s) as skimmer strings. Sansec advises self-hosted Plausible Community Edition operators to upgrade to 3.2.1 or later, search access logs for /storybook and compare priv/tracker/js/ with the official release.

BleepingComputer reported that the injected code targeted card number, expiry date, CVV, cardholder name and Brazilian CPF taxpayer identification number. BleepingComputer warned that browser caching could preserve the malicious script for up to 24 hours after server-side cleanup. Attribution posture: Sansec attributed the activity to a Brazilian Magecart group, but Convertr had not independently confirmed the actor or the suspected initial exploit in the cited sources.

Why this matters now

The compromise crossed organisational boundaries through a trusted client-side script. Merchants did not need to install malware directly: checkout pages loaded a shared analytics resource from Convertr infrastructure, creating a supply-chain path into payment collection and customer browsers.

Server-side removal is not sufficient evidence of closure. BleepingComputer reported that cached copies could continue executing after the hosted file was cleaned. Merchants therefore need browser, content-delivery and transaction evidence, not only confirmation that the current script is benign.

The incident also exposes a recurring control gap around marketing and analytics code. These dependencies often bypass the change-management, integrity validation and monitoring applied to payment application releases, even though they execute inside the same browser context and can read sensitive checkout fields.

The decision for security leaders

Require digital-commerce teams to identify every page and merchant property that loaded the Convertr script, then correlate execution with checkout sessions. A current clean file proves remediation at the source but does not establish which customers previously executed malicious content.

Treat third-party browser scripts as production code. Introduce an approved inventory, content-security policy, integrity monitoring and change alerting for analytics, tag-management and marketing dependencies that execute within checkout or authenticated sessions.

Coordinate fraud, privacy and incident-response decisions from one evidence set. Payment processors may need card-focused indicators, while legal teams need affected jurisdictions and data fields; neither should wait for an unsupported estimate of total victims.

Evidence of closure

  • Log searches record the disposition of every hit on the published indicators.
  • Merchant inventories identify every checkout page that loaded the affected script.
  • Payment and privacy owners document an approved notification and monitoring disposition.
  • Integrity controls alert on subsequent changes to authorised checkout scripts.

The Security.io assessment

Sansec published unusually actionable indicators and a precise timeline, making this a hunt-ready supply-chain incident. Confidence is moderated because the initial exploit remains suspected, the actor attribution is research-led and the cited record lacks a direct Convertr incident statement.

The cleanup confirmation is necessary but incomplete. Browser caching, merchant content-delivery layers and historical transaction sessions can extend exposure beyond the time when the origin file became clean. Merchant-specific evidence is therefore more important than the provider’s current script state.

The broader lesson is control ownership. Analytics code can change independently of a merchant’s application release while retaining access to payment-page data. Organisations that classify such scripts as marketing infrastructure rather than application dependencies will struggle to detect or bound similar incidents.

Questions for the morning meeting

  • Which merchant pages loaded the compromised Convertr analytics script during the exposure window?
  • Can web, browser and payment telemetry identify customers whose checkout sessions executed the skimmer?
  • Do content-security controls prevent shared analytics scripts from changing without review?
  • Which payment providers and regulators require notification based on confirmed execution?
  • Has browser caching been considered in the recovery and exposure window?

Related intelligence

Shared decision context