New WebRTC skimmer uses DTLS-encrypted UDP data channels to bypass CSP and exfiltrate payment data. PolyShell Magento RCE under mass exploitation. Patch step...
How a WebRTC skimmer slips past CSP
Content Security Policy is built around what the browser will fetch and execute over ordinary web channels: scripts, images, XHR, fetch, form posts. A skimmer that never opens those doors is harder to stop with the policies most stores already ship. WebRTC data channels ride on DTLS-encrypted UDP. They are not the same class of request as a script tag or an API call to a third-party host, so many CSP allowlists never see them as something to block. The page still looks “locked down” while payment fields are read in the browser and pushed out over a channel that security headers were never designed to police.
The attack surface is the checkout page itself. Malicious JavaScript already running in the page context can open a peer connection, establish a data channel, and stream cardholder data without a classic beacon or form post. Encrypted UDP traffic blends into normal browser networking and is awkward to inspect with tools that only log HTTP. Defenders who only audit CSP violations and blocked script sources will miss the exfiltration path entirely.
Why Magento stores are in the blast radius
PolyShell is a remote code execution chain against Magento that is under mass exploitation. Once an attacker can run code on the store server, planting or updating a skimmer is routine: inject a script into checkout templates, layout XML, or a compromised extension, and every subsequent payment page becomes an exfiltration point. The WebRTC technique is the delivery and egress layer; the Magento RCE is how the skimmer gets onto high-value checkouts at scale.
That pairing matters for triage. A store that “only” has a CSP gap is still exposed if the site is not patched. A store that patches Magento but never reviews checkout scripts, admin integrity, or third-party modules can still host a skimmer delivered by some other foothold. Treat the RCE and the browser-side channel as one incident class: server compromise plus client-side payment theft.
What to patch and check first
- Apply Magento security updates for the PolyShell RCE path immediately; do not wait for a scheduled release window if the store is internet-facing.
- Audit checkout HTML and injected scripts for unexpected WebRTC usage (RTCPeerConnection, data channel setup) and for any code that reads card or wallet fields.
- Review admin users, API keys, and recently modified themes, modules, and CMS blocks; mass exploitation often leaves persistence in layout and extension files.
- Tighten CSP where you can, but do not treat it as a complete control for WebRTC or other non-HTTP egress; pair it with integrity checks and script allowlisting that actually covers the checkout origin.
- Monitor for anomalous outbound traffic from browsers on payment pages and for server-side file changes under media, theme, and module paths.
Practical defense beyond the headline controls
Payment pages should load as little third-party script as possible. Prefer server-side or hosted fields that keep PAN data out of your own DOM when your processor supports it. Subresource integrity and strict script hashes help against silent injection of known bundles, but custom skimmer code will not match a known hash—so change detection on checkout templates and a short, reviewed allowlist of scripts matter more than policy length.
If you suspect compromise, rotate payment credentials and admin secrets, rebuild checkout assets from known-good sources, and re-scan for residual WebRTC or other side-channel beacons after patching. CSP remains useful against drive-by script loads; it is not a substitute for patching Magento and keeping hostile JavaScript off the payment page in the first place.