NEW MAGECART ATTACK USES WEBRTC TO BYPASS CSP, THEN TRIPS ON MANGENTO 2
A newly observed Magecart-style skimmer shows how attackers can bypass Content Security Policy (CSP) entirely by moving stolen checkout data through WebRTC, a browser feature designed for real-time communications. CSP is commonly used to control where browser-based scripts can load resources or send data, but this attack avoids the usual web request paths and attempts to exfiltrate payment data through WebRTC relay connections instead.
The technique is clever, risky, and active on non-Magento ecommerce platforms. But when the same skimmer landed on Magento 2, its own complexity worked against it: the checkout page rebuilt itself during normal shopper interactions, causing the malware to execute a second time and crash on a basic JavaScript scoping error. That failure does not make the technique harmless. On platforms where the script runs as intended, the same WebRTC approach can bypass CSP and move stolen checkout data outside normal web traffic
Attack details
Source Defense researchers found this skimmer active on non-Magento ecommerce platforms, where its WebRTC-based exfiltration technique could operate as designed, and also observed it on Magento 2, where it failed because of the way Magento checkout pages are rebuilt in the browser.
The attack was delivered as heavily obfuscated first-party JavaScript, using multiple layers of decoding, decryption, decompression, and custom encoding before revealing the inner payload. Once unpacked, the script attempted to inject additional logic into the page and reuse an existing script nonce, helping it blend into sites that enforce CSP. Its main innovation was the use of WebRTC TURN relays for exfiltration. Instead of sending stolen card data through normal HTTP requests, the malware attempted to route relay-based WebRTC traffic through an attacker-controlled TURN server on port 443, then hide chunks of encoded checkout data inside TURN username fields. The payload monitored payment and identity fields, including card numbers, CVVs, names, addresses, and passwords, using DOM monitoring, Shadow DOM traversal, input, paste, and submit listeners, plus autofill detection through CSS animation behavior.
On Magento 2, however, the checkout page is dynamically rebuilt as shoppers interact with it. That caused the skimmer to run again after it had already loaded once. Because the attacker did not include a simple “already loaded” check, and because parts of the script used variable declarations that cannot be declared twice in the same scope, the second execution caused a JavaScript error: the browser refused to continue running the payload. In practical terms, the skimmer could not maintain a stable listener on the checkout page, so the Magento 2 deployment failed before it could reliably collect and send data.
How Source Defense protects you
This is exactly the gap Source Defense is built to close. CSP can restrict many traditional exfiltration paths, and server-side protections can inspect what reaches the application or network edge, but they may not see a skimmer that reads checkout fields inside the browser and moves data through WebRTC instead of normal web requests.
Source Defense monitors script behavior where the attack happens, making suspicious first-party activity visible and actionable before stolen data disappears through a channel CSP was not built to control. Source Defense extends security to the client side by monitoring what scripts do in the browser, not just where they came from, helping security teams detect eSkimming behavior at the point of input before data reaches the web server. For this attack pattern, Source Defense would surface signals tied to sensitive checkout behavior, including accessing PCI data, accessing PII data, executing risky actions such as eval, and sending data to a blacklisted domain.
These alerts appear in the bell notification center and dashboard summaries, with relevant behavior visible in the “Script behaviors” widget and blacklist findings surfaced in the “Found in blacklists” widget when applicable.
Depending on configuration, alerts can also be sent by email and/or webhook, helping teams respond quickly without relying on CSP reports, manual console inspection, or server-side logs alone.
Key takeaways
The irony is hard to miss: the attacker built a sophisticated WebRTC exfiltration path to sidestep CSP, then forgot to make the script safe to run twice. On Magento 2, that mistake turned stealth into noise. On other platforms, however, the same technique can still create a serious client-side risk.
CSP, SRI, WAFs, and server-side logging remain useful, but they can miss attacks that execute in the customer’s browser, observe form input directly, and attempt to move data through nontraditional channels such as WebRTC. Source Defense helps close that gap with behavior-based client-side visibility, supporting payment-page security, eSkimming defense, and PCI DSS 4.0.1 requirements around script monitoring and change detection.
PCI DSS 4.0 makes client-side security a priority.
Source Defense delivers a solution for 6.4.3 and 11.6.1 without adding a burden to your security teams.