WebRTC Skimmer Bypasses CSP to Steal Payment Data from E-Commerce Sites

Cybersecurity researchers have disclosed a technically novel payment card skimmer that uses WebRTC data channels to both receive its payload and exfiltrate stolen financial data — a technique that bypasses the Content Security Policy (CSP) mechanisms that many e-commerce operators deploy as a core defence against JavaScript-based skimming attacks.

The Technical Innovation: Weaponising WebRTC

Content Security Policy is a browser-enforced security control that restricts which origins a page's JavaScript is permitted to load resources from or send data to. When properly configured, a strict CSP should prevent an injected skimmer from phoning home to an attacker-controlled server. This is why modern Magecart-style groups have been relentlessly researching CSP bypass techniques.

This newly discovered skimmer's innovation lies in its choice of transport: WebRTC (Web Real-Time Communication), the browser API designed for peer-to-peer audio, video, and data applications.

Unlike HTTP requests — which are subject to CSP connect-src directives — WebRTC uses the Interactive Connectivity Establishment (ICE) protocol and can establish DTLS-encrypted UDP data channels to remote peers. These connections are not governed by CSP's standard directives in all browser implementations, creating a blind spot that this skimmer exploits for both payload delivery and data exfiltration.

Attack Flow

The skimmer's operational chain has three stages:

Stage 1: Payload Delivery via WebRTC

Rather than loading its core malicious code via an HTTP <script> tag or fetch() call — which would be blocked by a restrictive script-src or connect-src CSP directive — the skimmer uses a WebRTC signalling handshake to establish a peer data channel. The malicious payload is delivered over this channel before the browser's CSP policy can be applied to the content.

This technique allows the attacker to inject only a tiny bootstrap stub into the compromised page. The stub itself may appear benign enough to evade automated malware detection, with the actual keylogging and exfiltration code arriving dynamically over the WebRTC channel.

Stage 2: Credential Harvesting

Once initialised, the skimmer hooks into the checkout page's DOM to intercept payment form field values as they are typed or autofilled. The harvested data includes:

• Full payment card number
• Cardholder name
• Card expiry date
• CVV / security code
• Billing address details

Stage 3: Exfiltration via Encrypted UDP

Harvested card data is serialised, encrypted, and transmitted to the attacker's C2 server over a DTLS-encrypted WebRTC DataChannel. Because this traffic travels over UDP rather than HTTP(S), it is invisible to:

• Browser CSP enforcement (in affected implementations)
• HTTP-layer network inspection tools
• Many WAF and DLP solutions that do not perform UDP deep packet inspection

The use of DTLS encryption further makes the traffic appear as legitimate WebRTC traffic to network-level monitors.

Deployment Context

Researchers note that this skimmer has been observed in conjunction with PolyShell compromise of Magento 2 storefronts — a recently disclosed polyglot file upload vulnerability that enables attackers to deploy arbitrary code on vulnerable installations. The WebRTC skimmer represents the monetisation layer of these intrusions, deployed after initial access is established.

The combination is particularly dangerous: PolyShell provides broad initial access across thousands of vulnerable Magento stores, and the WebRTC skimmer provides a covert, CSP-bypassing mechanism to harvest the payment data processed by those stores.

Detection Challenges

The skimmer is difficult to detect using conventional approaches:

• Static analysis of injected JavaScript may only reveal the small bootstrap stub, which may be heavily obfuscated
• Network monitoring may not flag the WebRTC connections if monitoring focuses exclusively on HTTP/HTTPS traffic
• CSP violation reports will not trigger, as the technique is designed to avoid firing report-uri endpoints
• Browser developer tools will show WebRTC peer connections in the chrome://webrtc-internals panel, but this requires active investigation

Mitigation Strategies

For CSP configuration:

The WebRTC CSP bypass highlights a limitation in CSP's current specification coverage. Some mitigations include:

• Adding webrtc 'block' to the CSP header — a non-standard but supported directive in Chromium-based browsers that disables WebRTC entirely for the page
• Implementing strict default-src 'none' policies and reviewing whether any WebRTC functionality is legitimately required on checkout pages

For e-commerce operators:

1. Deploy integrity monitoring on all JavaScript loaded by checkout pages; flag any changes to checkout page content between deployments
2. Patch underlying access vulnerabilities — this skimmer is a secondary payload; the primary concern is securing the Magento installation against initial compromise
3. Implement PCI DSS-required network segmentation to limit what a compromised webserver can reach
4. Consider a dedicated payment page hosted by a PCI-compliant payment processor (redirect-based checkout), which eliminates the risk of client-side skimming entirely

The research represents a meaningful evolution in skimming tradecraft and signals that CSP alone is insufficient as a defence against determined Magecart-style operators.