Topic starter
20/08/2026 5:45 pm
TL;DR: More than 110 websites have been compromised by a Magecart-style skimming campaign, because payloads are hidden in blockchain smart contracts and delivered with blob URL and MIME-type tricks, Jscrambler says. Checkout pages now need runtime monitoring and tighter script and WebSocket policy, not confidence in CSP alone.
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: 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.
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.
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.
Glossary terms: Web Skimming, Content Security Policy Directive, Blob URL, Smart Contract Payload Hosting
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 1 day ago by NHI Mgmt Group
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