A wave of Magento compromises that began March 19, 2025, has hit over 56.7% of vulnerable stores worldwide — and the payload is unlike anything most blue teams have seen before. Researchers at Sansec identified a new skimmer that ditches HTTP entirely for WebRTC data channels, allowing it to load malicious JavaScript and exfiltrate card data over encrypted UDP without triggering the Content Security Policy rules that defenders have spent years tuning. This isn't a theoretical bypass; it's an active campaign targeting real checkout pages right now.
This post breaks down how the attack chain works from initial exploitation through card exfiltration, why standard CSP is insufficient against this vector, how to detect it in your environment, and what mitigations actually move the needle. If you run Magento Open Source or Adobe Commerce and haven't patched PolyShell, stop reading and patch first.
The PolyShell Exploit: From REST API to Remote Code Execution
The attack begins before any skimmer code is in play. Threat actors are exploiting PolyShell, a vulnerability in Magento Open Source and Adobe Commerce that allows unauthenticated attackers to upload a web shell via the Magento REST API. Once the shell lands on disk, the attacker has persistent code execution on the web server — game over for any downstream control.
Why PolyShell Spread So Fast
Mass exploitation of PolyShell started on March 19, 2025. The exploitation rate is not surprising to anyone who watches Magento attack timelines: the platform's REST API is a recurring target (see previous exploits like CVE-2022-24086), threat actors scan for unpatched instances within hours of PoC availability, and many smaller merchants run Magento Open Source without a dedicated patch management process.
The attack technique maps directly to MITRE ATT&CK T1190 (Exploit Public-Facing Application) for initial access, followed by T1505.003 (Web Shell) for persistence. Once a web shell is established, the attacker's next move is scripted — they know the Magento file structure and inject skimmer code exactly where checkout JavaScript is loaded.
Important: Patching PolyShell stops initial access. But if your store was already compromised before patching, the web shell and skimmer payload may still be present. Patching alone is not remediation — you need a full file integrity audit.
Attack Entry Timeline
| Stage | Technique (ATT&CK) | Description |
|---|---|---|
| Initial Access | T1190 | PolyShell exploitation via Magento REST API |
| Persistence | T1505.003 | Web shell upload to server file system |
| Execution | T1059.007 | JavaScript injection into checkout page templates |
| C2 Channel | T1095 | Non-HTTP C2 via WebRTC/UDP data channel |
| Exfiltration | T1048.002 | Card data sent over DTLS/UDP to attacker IP |
How the WebRTC Skimmer Actually Works
This is where the attack gets technically interesting. Traditional Magecart-style skimmers load a secondary script via a <script src="..."> tag or an XHR/fetch call to an attacker-controlled domain. Defenders learned to block these with CSP directives like script-src and connect-src. The WebRTC skimmer sidesteps that entire model.
The Peer Connection Sequence
After the injected skimmer script runs on the checkout page, it executes the following sequence:
- Creates a
RTCPeerConnectionobject pointing to hard-coded STUN/TURN server IP202.181.177[.]177on UDP port 3479 - Establishes a WebRTC data channel — the same browser API used by video conferencing and real-time gaming apps
- Retrieves additional JavaScript payload over this channel rather than via HTTP(S)
- Injects the retrieved JavaScript into the page to hook form fields and capture card input
- Exfiltrates harvested payment data back over the same DTLS-encrypted UDP connection
The critical implication: connect-src and script-src CSP directives have no authority over WebRTC peer connections. Browsers treat RTCPeerConnection as a separate networking primitive. Unless your CSP includes specific directives like connect-src coverage for WebRTC — which most implementations don't — the outbound data channel is completely invisible to policy enforcement.
Why This Works Against Most Deployed CSPs
Most CSP implementations in e-commerce are written to block <script> tag injection and XHR/fetch calls to unauthorized origins. Very few include WebRTC-aware directives because, until recently, no real-world skimmer used this channel. The attack also uses DTLS encryption over UDP, so network-layer inspection tools that look for plaintext card patterns in HTTP traffic won't see anything useful.
Pro Tip: To block WebRTC peer connections at the CSP level, add the directive default-src without 'unsafe-eval' and specifically restrict peer connections. Firefox and Chrome honor CSP-restricted WebRTC when you omit 'unsafe-inline' and configure strict default-src. Test your current CSP header against the CSP Evaluator and look specifically for missing WebRTC coverage.
Detection: What to Look for in Your Environment
Catching this attack after the fact requires looking in places most SOC runbooks don't cover. HTTP-based IOC feeds won't surface the C2 IP in your proxy logs because the traffic never hits your proxy.
Host-Based Indicators
On the Magento server itself, look for:
- Unexpected PHP files in
/pub/,/media/, or/var/directories with recent modification timestamps - Files containing
eval(base64_decode(...))or obfuscated hex strings - REST API logs showing unusual POST requests to
/rest/V1/endpoints from non-admin IPs around or after March 19 - File integrity monitoring (FIM) alerts — this is exactly the scenario CIS Control 3.14 (File Integrity Monitoring) is designed to catch
Network-Based Indicators
Traditional network detection is harder here, but not impossible:
- DNS/STUN traffic: Monitor for outbound UDP traffic to port 3478–3479 from your web server. Web servers should almost never initiate WebRTC connections.
- Block IP 202.181.177[.]177 at your perimeter immediately if you haven't already.
- Browser-side anomalies: If you run a Content Security Policy Report-Only header, check your report endpoint for unexpected
connect-srcviolations — though note the WebRTC bypass means standard connect-src may not report at all.
| Detection Surface | Tool/Method | Signal |
|---|---|---|
| Web server file system | FIM (OSSEC, Wazuh, Tripwire) | New/modified PHP files in public dirs |
| Magento REST API logs | Log aggregation (Splunk, ELK) | Anomalous POST to /rest/V1/ |
| Network perimeter | Firewall/IDS | Outbound UDP 3478-3479 from web tier |
| Browser telemetry | CSP reports + RUM | Unexpected RTCPeerConnection calls |
| Threat intel | IOC feeds | IP 202.181.177[.]177 |
Incident Scenario
Imagine your SOC receives a FIM alert at 2:14 AM: a new file pub/media/catalog/.thumb.php was created. The alert fires with low priority because the path looks like a thumbnail cache. An analyst triages it as routine and closes it. Three days later, a fraud team member flags a spike in card-not-present fraud tied to your checkout. A threat hunter pulls the file — it's a web shell. The WebRTC skimmer has been running undetected because no HTTP requests to an external C2 ever fired.
This scenario plays out in real incident responses more often than it should. Low-priority FIM alerts on media directories are a well-known blind spot.
Mitigation: What Actually Reduces Risk Here
There is no single control that eliminates this threat. The correct response is defense-in-depth across three layers.
Immediate Actions (Do These Now)
- Patch PolyShell — apply the relevant Magento security patch immediately. Check the Adobe Security Bulletin for the specific patch ID.
- Audit your file system for web shells, focusing on
/pub/,/media/,/vendor/, and/app/code/— anywhere a REST API upload might land. - Block
202.181.177[.]177at your firewall and WAF. - Rotate all admin credentials and invalidate active API tokens. Web shell access may have been used to harvest credentials.
Structural Controls
| Control | Framework Reference | Risk Reduction |
|---|---|---|
| Patch management (SLA <72h for critical) | CIS Control 7, NIST CSF RS.MI | Eliminates initial access vector |
| File Integrity Monitoring on web root | CIS Control 3.14 | Detects web shell within hours |
| WAF rule for REST API abuse | OWASP ASVS L2 | Blocks exploitation attempt |
| Subresource Integrity (SRI) on checkout JS | PCI DSS v4.0 Req 6.4.3 | Detects injected script changes |
| CSP with strict default-src | ISO 27001 A.14.2 | Limits script injection surface |
| Network egress filtering on web tier | NIST SP 800-41 | Blocks unexpected outbound UDP |
Important: PCI DSS v4.0 Requirement 6.4.3 explicitly requires merchants to manage all JavaScript loaded on payment pages, including integrity verification. If you're not meeting this control, this attack is exactly the scenario the requirement was written for. Non-compliance in a breach context means significantly increased liability under PCI DSS and potential GDPR Article 32 obligations if EU cardholder data was involved.
What This Attack Tells Us About the Evolving Skimmer Threat
Magecart-style attacks have been running since at least 2015, and the core technique — inject JavaScript into a checkout page — hasn't changed. What changes is the evasion. Early skimmers sent card data in plain HTTP. Defenders added CSP. Attackers moved to HTTPS. Defenders added connect-src. Now attackers have moved to WebRTC.
This is a predictable arms race: every defensive control creates an incentive to find the transport layer it doesn't cover. WebRTC was always a candidate because browsers treat it as a peer communication primitive with separate trust assumptions from HTTP. The question now is whether browser vendors will expose better CSP hooks for WebRTC, and whether merchants will implement them before the next evasion technique surfaces.
The broader lesson for defenders: treat your CSP as a living document, not a deployment artifact. Review it quarterly against emerging attack vectors, and test it against your actual checkout page behavior — not just against a policy validator.
Key Takeaways
- Patch PolyShell immediately — over half of vulnerable Magento instances have already been hit since March 19
- Run a web shell audit now, not after your next scheduled scan cycle — check media and cache directories specifically
- Add outbound UDP egress filtering on your web server tier; legitimate web servers don't initiate WebRTC connections
- Implement PCI DSS v4.0 Req 6.4.3 Subresource Integrity checks on all checkout JavaScript — this detects injected skimmer code even when the C2 channel is invisible
- Treat low-priority FIM alerts on web directories as high-priority during active exploitation campaigns
- Review your CSP for WebRTC coverage — standard connect-src does not restrict RTCPeerConnection by default
Conclusion
The WebRTC skimmer identified by Sansec is a meaningful step forward in Magecart evasion technique, but the entry point is the same vulnerability defenders have been chasing for years: unpatched public-facing applications and insufficient file integrity monitoring. The PolyShell exploitation wave is still active. If you operate a Magento environment and haven't confirmed your patch status and run a file integrity audit in the past week, do that before anything else.
Beyond the immediate incident response, this attack should prompt a genuine reassessment of your CSP strategy and network egress controls for web tier assets. The controls exist — FIM, SRI, egress filtering, PCI DSS v4.0 requirements — but they require intentional implementation. Start with a payment page JavaScript audit and a web server egress review this week.
FAQ
Q: Does patching PolyShell remove the WebRTC skimmer if my store was already compromised?
No. Patching closes the initial access vector but doesn't remove artifacts already placed on your server. You need to manually audit the file system for web shells and injected code, and restore checkout templates from a known-clean backup or version control baseline.
Q: Can a WAF block the WebRTC exfiltration channel?
No. WAFs operate at the HTTP layer. WebRTC data channels communicate over DTLS/UDP, which sits entirely outside the WAF's inspection path. Network-layer firewall rules blocking outbound UDP 3478-3479 from your web server are more effective for this specific threat.
Q: Is this skimmer targeting only self-hosted Magento, or does it affect Adobe Commerce Cloud too?
The PolyShell vulnerability affects both Magento Open Source and Adobe Commerce. Adobe Commerce Cloud environments may have additional platform-level controls, but the vulnerability and exploitation technique apply to the application regardless of hosting model. Check with Adobe for environment-specific guidance.
Q: How do I test whether my current CSP blocks WebRTC connections?
Open your checkout page in a browser with DevTools open. In the Console, run new RTCPeerConnection({iceServers:[{urls:'stun:stun.l.google.com:19302'}]}). If it succeeds without a CSP violation, your CSP does not restrict WebRTC. To restrict it, you need to ensure your CSP does not include permissive fallbacks and consult the current W3C working draft on CSP Level 3 WebRTC restrictions, as browser support varies.
Q: What logging should I enable to detect future skimmer injections earlier?
Enable and centralize Magento REST API access logs, configure your FIM tool to alert on new file creation (not just modification) in web-accessible directories, and deploy a real-user monitoring (RUM) script that can detect unexpected JavaScript execution on checkout pages. Combining FIM with a SIEM correlation rule for "new file in /pub/ + REST API POST within same 1-hour window" creates a high-fidelity detection for this specific attack pattern.
Enjoyed this article?
Subscribe for more cybersecurity insights.