Convertr’s Checkout Skimmer: The Dependency Your Lockfile Misses

On October 26, Sansec reported a skimmer in Convertr’s shared analytics script. Its October 27 update confirmed removal. The initial entry point remains unconfirmed. Read the investigation.

The application-security question is broader than which package was vulnerable. Which executable bytes reach your checkout without passing through your application’s dependency review? A clean repository cannot answer that question by itself.

Extend the inventory to the browser

Start with one critical page and a synthetic user journey. Record scripts loaded by the initial document, the tag manager and subsequent navigation. Repeat after the relevant consent choices. Avoid collecting customer data while making that record.

For each script, retain its full source URL, initiating component, business purpose, owner, update mechanism and approved content digest where applicable. Distinguish a file bundled into your application from a URL that serves independently changing content. Document unknowns rather than treating every familiar hostname as an approved dependency.

Original control model, not a reconstruction of Convertr’s deployment. The labels identify review responsibilities rather than measured attack volume.

This adds a browser view to the artifact questions in our embedded-runtime patch workflow. The two inventories should share owners and evidence, but neither should silently substitute for the other.

An allowed host is not an approved file

A policy that permits a script host answers where a browser may load code. It does not establish that the current file is the reviewed one. Content Security Policy and Subresource Integrity address different controls. The MDN script-src reference and integrity guidance explain their enforcement models.

Use a controlled exercise to test the distinction. Serve an inert fixture from your own test origin, approve its expected content and then change that fixture. Confirm what the browser actually blocks. Never replace a production analytics file to prove this point.

For a stable external resource, consider an integrity attribute with a reviewed digest and the necessary cross-origin configuration. Define how an intentional update gets a new approved digest. A randomly changing resource or a loader that fetches more scripts requires a different operational design. Do not paste an integrity example into production and assume its downstream behavior is covered.

For CSP, begin with an inventory-backed policy and review violation reports using synthetic traffic. A report-only deployment measures proposed restrictions; it does not enforce them. Test the enforced policy with the real checkout flow before relying on it. Retain the effective response headers and the browser observation, not just a configuration file.

Turn ownership into a testable decision

A script exception should have an owner who can explain why it belongs on the payment page. Ask what changes if it is removed, whether it can run on a less sensitive page and which destinations its workflow needs. These are design questions for your application, not claims about another merchant’s implementation.

The table is a proposed review contract. It is not a report of controls used by Convertr or a claim that one control prevents every skimmer.

Keep incident response separate from a clean reload

If your own evidence indicates an incident, preserve the relevant timestamps, script bytes and deployment records before changing them. Use your response process to decide retention, containment and required notifications. Keep payment details out of ordinary diagnostic logs.

After an approved change, verify the page that users receive. Check redirects, cached resources, script initiation and the resulting policy. Exercise the legitimate payment journey with approved test facilities. A successful asset request is useful delivery evidence; it is not a complete incident investigation.

This follows the distinction in our privilege-boundary validation guide: a successful operation does not prove that every forbidden operation fails. Our coding-agent supply-chain analysis applies a related lesson to another way executable inputs enter development work.

Use Plexicus for an evidence-led assessment

Plexicus describes AI Swarm Pentest as scoped application and API assessment with reviewable evidence. Its remediation workflow presents reviewed fixes and verification retests. For a checkout engagement, bring the script inventory, synthetic user journey and the exact policy questions you need answered.

Agree whether browser behavior, third-party endpoints and script-change controls fall inside the authorized scope. Do not infer a continuous client-side skimmer-monitoring service, automatic coverage of every tag manager or a reproduction of this incident from those product descriptions.

A useful deliverable names the tested deployment, observed behavior, control owner and retest outcome. Keep unresolved supplier questions visible. The goal is a checkout dependency decision your team can explain, change and verify.

Sources

• Sansec investigation and October 27 update.
• MDN: Subresource Integrity.
• MDN: CSP script-src.

Want to review one critical checkout flow? Contact Plexicus with its authorized scope, script inventory and a synthetic test journey.