The Credit Card Skimmer That Security Tools Can't See

There's a new payment skimmer making the rounds, and it's doing something nobody has seen before: it uses WebRTC DataChannels to steal your credit card details. If that sounds like an odd sentence, stick with me — the technical trick behind this is genuinely clever, and it renders most existing security defenses blind.

Dutch security firm Sansec discovered the skimmer last week on the e-commerce website of a car manufacturer worth over $100 billion. The skimmer was injected through a separate vulnerability called PolyShell that affects every production version of Magento and Adobe Commerce — the platform powering roughly 130,000 live online stores and processing over $155 billion in annual sales. There is no production patch available. Over half the vulnerable stores have already been hit.

If you've bought anything from a Magento-powered store in the past two weeks, you should be paying close attention to your credit card statements.

How Payment Skimmers Usually Work

Traditional payment skimmers — also called Magecart attacks — follow a predictable pattern. Attackers inject malicious JavaScript into a store's checkout page. When you type your credit card number, the script captures it and sends it to an attacker-controlled server via an HTTP request. Maybe it disguises the data as an image load, or stuffs it into a tracking pixel URL, or POSTs it to a domain that looks vaguely legitimate.

Security teams have gotten good at catching this. Content Security Policy (CSP) headers restrict which domains a page can communicate with. Web Application Firewalls (WAFs) inspect outbound HTTP traffic for suspicious patterns. Network monitoring tools flag unexpected connections. These defenses aren't perfect, but they've raised the bar enough that most skimmers get caught within days.

The WebRTC skimmer sidesteps all of that.

WebRTC: The Blind Spot

WebRTC — Web Real-Time Communication — is the browser API that makes video calls, voice chat, and peer-to-peer file sharing work directly in your browser. When you use Google Meet, Discord in your browser, or any number of other communication tools, WebRTC is handling the media streams.

Here's the detail that matters for this attack: WebRTC DataChannels don't use HTTP. They use DTLS-encrypted UDP. That's a completely different communication protocol operating on a completely different network layer.

Content Security Policy? It controls HTTP connections. CSP has no standardized directive for WebRTC traffic. Chrome has shipped experimental support for a webrtc CSP directive, but virtually no site deploys it, and other browsers don't support it yet.

Web Application Firewalls? They inspect HTTP requests and responses. UDP traffic from a WebRTC DataChannel doesn't pass through them at all.

Network monitoring tools that look at HTTP traffic? Same problem. The stolen data leaves over encrypted UDP, and unless you're specifically inspecting DTLS sessions — which almost nobody does for web traffic — you won't see it.

The attackers found a channel that the entire web security stack wasn't designed to monitor.

How the Skimmer Works

The technical execution is tight. The skimmer is a self-executing JavaScript function that does the following:

Step 1: Establish a WebRTC connection. The script creates a WebRTC peer connection directly to the attacker's server at IP address 202.181.177[.]177 on UDP port 3479. Normally, WebRTC requires a signaling server to exchange connection details between peers — that's how your video calls get set up. This skimmer skips signaling entirely by hardcoding the remote Session Description Protocol (SDP) parameters. It generates a random ICE username fragment, hardcodes the ICE password, and constructs a fake SDP "answer" pointing to the attacker's IP with a pre-shared DTLS fingerprint.

No signaling server. No STUN/TURN negotiation. Just a direct UDP connection from the victim's browser to the attacker.

Step 2: Receive the payload. Once the DataChannel opens, the attacker's server sends the actual skimming JavaScript code through it. This is where the CSP bypass gets nasty: the skimmer scans all existing <script> tags on the page looking for a CSP nonce attribute. If it finds one, it copies that nonce onto a new script element and injects the received payload into the page. The payload executes as if it were a legitimate, CSP-approved script.

Step 3: Steal payment data. The injected code hooks into the checkout form and captures card numbers, expiration dates, CVVs, and billing details as you type them.

Step 4: Exfiltrate over WebRTC. The stolen data goes back out through the same DataChannel — encrypted UDP, invisible to HTTP-based security tools.

From the victim's perspective, nothing looks wrong. The checkout page works normally. The payment goes through. You get your order confirmation. Meanwhile, an attacker on the other side of the world has a copy of your card.

PolyShell: The Door They Walked Through

The WebRTC skimmer is the payload. PolyShell is how it got there.

PolyShell (tracked as CVE-2025-20720, CVSS 9.8) is an unauthenticated file upload vulnerability in Magento Open Source and Adobe Commerce. It affects every production version up to 2.4.9-alpha2.

The flaw sits in Magento's REST API. When a product has a "file" type custom option, Magento accepts file uploads as part of the cart item data. You send a POST request to /rest/default/V1/guest-carts/:cartId/items with a file_info object containing base64-encoded file data, a MIME type, and a filename. Magento writes that file to pub/media/custom_options/quote/ on the server.

The problem: there's no file extension restriction. Extensions like .php, .phtml, and .phar are not blocked. The only validation is a call to PHP's getimagesizefromstring() function — which checks if the data looks like a valid image.

That check is trivially bypassed with a polyglot file. A polyglot is a file that's valid in multiple formats simultaneously. The simplest version: prepend GIF89a (the GIF file header) to a PHP payload. The getimagesizefromstring() function sees a valid GIF. The web server sees a .php file and executes it.

That's where the name "PolyShell" comes from — polyglot plus web shell.

No authentication required. No special permissions. Just a single HTTP request to the REST API and you have a web shell on the server. From there, the attacker can inject skimmer code into checkout pages, modify server configurations, access the database, steal customer records — whatever they want.

The Scale of the Damage

Sansec started tracking PolyShell exploitation from the moment probing began on March 16. Automated mass scanning kicked off three days later, with over 50 IP addresses participating. By the time Sansec published their findings, 56.7% of all vulnerable stores had been attacked.

The affected brands are not small fish. Sansec's research mentions infrastructure belonging to Asus, FedEx, Fiat, Lindt, Toyota, and Yamaha among the compromised stores. These are global brands with presumably well-resourced IT teams, and they still got hit — because the vulnerability is in the platform itself, not in any particular store's custom code.

And here's the part that should make store owners lose sleep: there is no production patch. Adobe fixed the vulnerability in version 2.4.9-beta1, released on March 10, but that's a pre-release branch. No isolated security patch exists for current production versions (2.4.7-p4, 2.4.6-p9, and earlier). Store owners are stuck choosing between running unpatched production code or deploying a beta release — neither of which is a great option.

Why This Combination Is Particularly Dangerous

PolyShell and the WebRTC skimmer are two separate issues, but together they form a kill chain that's hard to detect at every stage:

1. Entry is silent. The PolyShell upload looks like a normal REST API request. Unless you're specifically monitoring for file uploads to the custom options endpoint, it blends in with legitimate traffic.

2. The skimmer loads invisibly. The WebRTC DataChannel retrieves the malicious JavaScript outside of HTTP, so CSP and WAFs don't flag it.

3. Data exfiltration is invisible. The stolen card data leaves over encrypted UDP. No HTTP-based monitoring tool catches it.

4. The checkout page works normally. There's no visible sign to the customer that anything is wrong.

Traditional Magecart detection relies on spotting unauthorized JavaScript or unexpected network connections. This skimmer defeats both approaches by using a protocol that security tools weren't built to inspect.

What Store Owners Should Do

If You Run Magento or Adobe Commerce

Check if you've been compromised. Scan the pub/media/custom_options/quote/ directory for any .php, .phtml, or .phar files. These should not exist there. Also look for unexpected files in other media directories — attackers may have moved or renamed their web shells after initial upload.

Monitor your REST API logs. Look for POST requests to /rest/default/V1/guest-carts/*/items that contain file_info objects with suspicious MIME types or filenames ending in executable extensions.

Apply Sansec's virtual patch. Since no official production patch exists, Sansec has published detection rules and a virtual patch through their eComscan product. Other WAF vendors may have published similar rules — check with yours.

Block executable file uploads at the web server level. Configure Nginx or Apache to deny execution of PHP files in the pub/media/ directory tree. This doesn't fix the upload vulnerability, but it prevents uploaded web shells from executing. If you're running Magento, you should already have this rule — but verify it. Many deployments don't.

Add this to your Nginx configuration for the media directory:

location ~* /media/.*\.php$ {
    deny all;
}

Consider upgrading to 2.4.9-beta1 if your risk tolerance allows it. This is genuinely a judgment call. Running a beta in production is normally inadvisable, but running an unpatched production version that's being mass-exploited isn't great either. Test the beta in staging first and assess the risk for your specific setup.

Rotate all credentials. If your store was accessible since March 16, assume your admin credentials, database passwords, API keys, and encryption keys may have been exfiltrated. Change them.

For Security Teams

Start monitoring WebRTC traffic. This skimmer is a proof of concept for an entire class of exfiltration techniques. If attackers can use WebRTC DataChannels to bypass CSP today, they'll be using it for more than just payment skimming tomorrow.

Look at your network monitoring setup. Can it see UDP traffic originating from browser processes? Can it identify WebRTC sessions being established to unexpected IP addresses? If the answer is no, that's a gap.

Audit your CSP directives. Chrome's experimental webrtc CSP directive exists precisely for this scenario. It's not standardized and browser support is limited, but if your users are primarily on Chrome, deploying it adds a layer of defense:

Content-Security-Policy: webrtc 'block'

This tells Chrome to block WebRTC connections that aren't explicitly allowed. It's not a complete fix — other browsers ignore it — but it's better than nothing.

Review your WAF rules for the PolyShell upload pattern. The attack uses the Magento REST API in a way that's technically "valid" from a protocol standpoint. Your WAF needs rules that specifically look for executable file extensions in file_info payloads targeting the guest cart endpoint.

What Shoppers Should Do

If you've purchased anything from an online store in the past two weeks and you're not sure what platform it runs on, there are a few things you can do:

Check your credit card statements. Look for any charges you don't recognize. If you spot something, contact your card issuer immediately.

Use virtual card numbers. Services like Privacy.com, or the virtual card features offered by some banks and credit cards, let you generate single-use or merchant-locked card numbers. If a skimmer grabs one, it's worthless for anything else.

Enable transaction alerts. Most banks can text or push-notify you for every transaction. Real-time alerts let you catch fraudulent charges within minutes instead of waiting for your monthly statement.

Pay with PayPal, Apple Pay, or Google Pay where available. These payment methods don't expose your actual card number to the merchant's checkout form. If the checkout page is compromised, the skimmer can't capture card details it never sees.

The CSP Gap Is a Systemic Problem

The broader issue here goes beyond one Magento vulnerability. Content Security Policy has been the web's primary defense against injected scripts for over a decade. It works by restricting which sources a page can load scripts from and which domains it can communicate with. The entire security model assumes that "communication" means HTTP.

WebRTC DataChannels break that assumption. They're a legitimate browser API available on every modern browser, and they communicate over a protocol that CSP doesn't govern. The W3C has discussed adding WebRTC to CSP for years, but as of today, there's no finalized standard. Chrome's experimental directive is the closest thing we have, and it's Chrome-only.

This means every website that relies on CSP as a defense against data exfiltration has a blind spot. The WebRTC skimmer is the first documented case of attackers exploiting it at scale, but it won't be the last. Now that the technique is public, expect it to show up in other attack toolkits.

Payment skimming is just the obvious use case. The same technique works for exfiltrating any data a malicious script can access — form inputs, session tokens, page content, keystroke logs. Any scenario where an attacker has script execution on a page and needs to get data out without triggering CSP can use this channel.

The next move is on browser vendors and the web standards bodies. WebRTC needs to be brought under CSP's control, and it needed to happen yesterday.

Sources: Sansec — WebRTC Skimmer Research, Sansec — Magento PolyShell, The Hacker News, BleepingComputer, Searchlight Cyber