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.
Editorial analysis by NHI Mgmt Group, based on content published by Jscrambler: “Payment Iframes Now Proven Susceptible to Silent Skimming”.
By the numbers:
- Jscrambler’s researchers discovered over 110 websites compromised to date.
Key questions
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 smart contracts make skimmers harder to disrupt?
A: A smart contract can store or point to payload data on-chain, so defenders cannot simply take down a server to remove the code.
Q: How should security teams reduce the risk of client-side data skimming on checkout pages?
A: Security teams should treat browser-executed JavaScript as part of the trust boundary, not as a harmless front-end detail.
Practitioner guidance
- Harden script source policy Set Content Security Policy to explicitly block blob: and data: in script-src wherever business logic allows it, and avoid wildcard allowances that mask new execution paths.
- Constrain WebSocket destinations Limit connect-src to required payment and application domains only, then alert on any unexpected WebSocket endpoint during checkout.
- Monitor runtime script behaviour Use client-side integrity monitoring that flags script loading from blobs, object URLs and unusual DOM mutations instead of relying only on static file checks.
Bottom line: The attack succeeds by combining hidden payload delivery, in-browser execution tricks and resilient on-chain storage, which makes standard web controls easier to evade.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
20/08/2026 6:28 pm
Client-side skimming has moved beyond static obfuscation into control-plane evasion. The campaign matters because the attacker is no longer relying only on hidden code, but on browser behaviours, plugin rewrite logic and blockchain retrieval to stay ahead of review. That changes the defender's job from script inspection to continuous runtime governance. Practitioners need controls that can observe behaviour after the page loads, not just policies written before deployment.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What should merchants do immediately when a payment page is suspected of skimming?
A: Isolate the page, preserve client-side evidence, invalidate exposed session and payment-related tokens where possible, and review every script, redirect and checkout dependency that can alter the customer transaction path. The priority is containment of live collection paths before further cardholder data is captured.
👉 Read our full editorial: Magecart skimmers using smart contracts raise the bar for web defence