Notifications
Clear all
Topic starter
20/08/2026 5:45 pm
TL;DR: A new Magecart-style campaign hides skimmer payloads in blockchain smart contracts, uses blob URLs and MIME-type tricks to bypass Content Security Policy, and has already compromised more than 110 websites, according to Jscrambler. CSP and SRI alone are not enough when delivery and execution are both being actively obfuscated.
NHIMG editorial — based on content published by Jscrambler: analysis of a Magecart-style skimmer campaign that uses blockchain smart contracts and CSP evasion
By the numbers:
- Jscrambler says over 110 websites have been compromised by this campaign to date.
Questions worth separating out
Q: What breaks when CSP is not strict enough on payment pages?
A: Loose CSP settings let attackers use allowed browser behaviors, external script paths, or dynamic object URLs to hide malicious code in checkout flows.
Q: Why do checkout skimmers remain effective even when websites use security headers?
A: Security headers help only when they match the real runtime behavior of the page.
Q: How do security teams know if browser integrity controls are working?
A: They should look for three signals: complete coverage of payment pages, low-noise integrity alerts, and a fast approval or revoke path when unexpected script changes appear.
Practitioner guidance
- Tighten script-source controls for checkout pages Explicitly block blob: and data: sources in script-src, and remove wildcard allowances wherever payment flows do not require them.
- Restrict WebSocket destinations on commerce paths Limit connect-src to known payment, analytics, and support domains so unexpected WebSocket sessions from checkout code are visible and reviewable.
- Monitor runtime script behavior, not just static page content Use client-side integrity monitoring to detect blob creation, object URL use, and script mutations after page load, especially on pages handling card data.
What's in the full report
Jscrambler's full analysis covers the operational detail this post intentionally leaves for the source:
- Specific indicators of compromise, including the smart contract and domain patterns tied to the campaign.
- Detailed examples of the loader variants and the browser behaviors used to hide malicious execution.
- Campaign-level remediation guidance for CSP, connect-src, and runtime monitoring in checkout environments.
- The researchers' timeline of discovery and the chain of infrastructure changes across the campaign.
👉 Read Jscrambler's analysis of the blockchain-backed Magecart skimmer campaign →
Magecart smart-contract skimmers: are your web controls keeping up?
Explore further
20/08/2026 6:28 pm
Browser-executed payment code is now part of the trust boundary. The campaign shows that checkout security can no longer be assessed only at the server or gateway layer. If a payment page can fetch, assemble, and execute code after load, then policy controls must extend into runtime script integrity and destination control. Practitioners should treat the browser as an enforcement point, not just a presentation layer.
A question worth separating out:
Q: What should teams do when payment-page tampering is detected?
A: Teams should isolate the affected page, preserve evidence, identify the modified script or header, and determine whether customer data could have been exposed during the malicious execution window. Then they should rotate any related secrets, review third-party dependencies, and validate that the monitoring gap is closed before restoring normal checkout traffic.
👉 Read our full editorial: Magecart skimmers using smart contracts raise the bar for web defence
