Five multi-billion-dollar companies in two months... the past and the future
Your Content Security Policy is strict. Your HTTP monitoring is solid. You’ve patched your web site and application as well as you can. And yet, sensitive data (payment card details, customer details, source code, etc.) is leaving your site through a channel your security tools cannot even see. What’s going on?
$US Multi-billion you say? Yes!
On 24 March 2026, Dutch e-commerce security firm Sansec published research describing a payment skimmer found on the online store of a car manufacturer with revenues exceeding US$100 billion. As it would turn out, the car maker was not an isolated case. Sansec reported finding payment skimmers on five multi-billion-dollar companies in the two months prior, including a top-three US bank and a top-ten global supermarket chain.
What made it notable was not what the attackers stole but how they got the data out. It was very interesting news at the time so we drafted a post back in March, when the attack below was fresh… but then the post sat in the queue… other work got in the way… and by the time we came back to it, the vulnerability was patched, and the technique had been written up everywhere.
The obvious assumption was that we had missed the boat.
How wrong we were!
PolyShell: how they got in… And how the data got out
There were two separate layers to the Sansec-reported attack:
- The first layer is the entry vector. The attackers most likely got their code onto the checkout page through PolyShell, an unauthenticated file-upload vulnerability in the Magento and Adobe Commerce REST API. Another exploitable software vulnerability; exciting for a moment, then patched and forgotten. There’ll be others.
- The second layer is where the real fun begins: Data exfiltration over covert channels! Instead of the usual (HTTP requests, image beacons, or WebSocket) connections, the attackers exfiltrated stolen payment data over WebRTC DataChannels, a peer-to-peer protocol designed for real-time audio, video, and data between browsers. Sansec recorded this as the first time WebRTC had been observed as a skimming channel in the wild.
Two layers result in two different defensive problems: The entry layer is a platform bug you patch tactically, according to your documented patch management strategy and plan. The exfiltration layer is where strategy comes in and that’s where we focus our long-term thinking and efforts.
On the tactical front, the world has moved on, exactly as you would expect it to. Adobe shipped the fix for PolyShell in Magento 2.4.9 on 12 May 2026, and businesses were encouraged to check the published indicators of compromise to see if they’d become victims of the attack.
All of that was tactically correct, but being tactical, it’s also the part of our original article that went out of date between March. And that is the cue for our re-write recovery!
The boat has not sailed: this is a pattern, not an event
Exfiltration over a “legitimate” but covert channel is not an e-commerce or a WebRTC quirk. It is a permanent category of problem, and the list of channels already in use is long: Take for example, DNS tunnelling, which predates the conscious existence of many people reading this article. Then there is DNS-over-HTTPS used more recently to hide exfiltration and command-and-control (C2) traffic from DNS-layer inspection.
WebRTC was a novel skimming channel in March but now, even WebRTC has become ho-hum, as the events since March have shown:
- Later in March, Check Point Research showed an AI code-execution sandbox could be made to leak a user’s uploaded documents even though the sandbox blocked outbound HTTP, by chunking the data into DNS lookups that the environment had to allow in order to resolve names at all. Different channel, different target, identical logic: When the obvious egress is closed, the data leaves over the one that is open. That has happened three times in the span this article covers, and it was not a forecast.
- In late May 2026, CrowdStrike, Google, and the Shadowserver Foundation disrupted GlassWorm, a developer-supply-chain botnet that poisoned more than 300 GitHub repositories and turned infected machines into covert proxy and remote-execution nodes. WebRTC was among the channels it used to operate over encrypted UDP rather than anything a firewall was watching.
Some new exploit will replace the current ones. The specific bug is disposable. The issue recurs.
The obvious answer may not be the best one
If the channel is the problem, the obvious response is to block the channel, right?
Wrong! There is a long-running entry in the Content Security Policy (CSP) issue tracker, opened years before the March skimmer, titled “WebRTC can be used for exfiltration”. It notes that sites were already abusing WebRTC to pull data through browsers with no per-site way to stop it.
In response the specification grew a webrtc directive to address it, but the people who maintain CSP never believed it would be a reliable fix. A Mozilla security engineer stated plainly in that discussion that CSP never had the goal of preventing exfiltration, that there are known exfiltration mechanisms it cannot stop regardless of the browser, and that it should not be expected to be reliable for this.
So the webrtc directive was a deliberately limited stopgap that its own designers doubted. And even that was never built: No major browser implements it in stable form and the exfiltration gap the March skimmer used is exactly as open today as it was then.
The answer: Assume breach
If you cannot predict the next entry bug, and you cannot block outgoing channels faster than attackers find them, the only solid position to take is assume breach: Work on the basis that you will eventually be breached through something you do not yet know about, and build controls to detect and respond to that, without knowing the details of the attack in advance.
If we do that, the question changes from “which channel” or “which bug”, and it becomes “did this page change from what we shipped?” and “is data leaving over something abnormal for this host, regardless of protocol?” Neither question cares whether the entry was PolyShell or its successor, or whether the exit was WebRTC or WebTransport.
The controls that follow from an assumed-breach posture are well understood:
- Integrity monitoring on sensitive pages, detecting changes to the page and its scripts as delivered to the browser, so an injected skimmer is caught as an unexpected modification.
- Event (including connection and traffic) anomaly detection so we’re not (probably) going to “block WebRTC”, but instead we’ll alert on outbound UDP from a web server to an unfamiliar destination on a non-standard port as abnormal regardless of the protocol.
PCI DSS already reached this conclusion
The payments industry is ahead of the game when it comes to mandating controls that are relevant to the attacks we’re discussing here, and the PCI DSS includes controls targeting browser-hijacking attacks:
- Requirement 6.4.3 (Authorise, verify, inventory): For every script that runs on your checkout page you must have three things: a method to confirm it is authorised, a method to assure its integrity, and an inventory of all scripts with a written business or technical justification for each.
- Requirement 11.6.1 (Detect and alert): Simply telling a browser to block unauthorised code isn’t enough; if a hacker breaks into your server and strips your defense rules out entirely, you are left blind. You must run a change- and tamper-detection mechanism that checks the page code and HTTP headers as received by the consumer’s browser and alerts you when a security-impacting header or a payment-page script is added, changed, or deleted (or shows other signs of compromise). It runs at least weekly, or at a frequency you justify in a targeted risk analysis, so it catches a CMS compromise or an injected skimmer and raises the alarm, rather than blocking it before the browser runs it.
Note that there are exclusions for SAQ A, but we won’t go into those here.
More importantly within the overall context of this piece, we note that nothing in this article is specific to retail. Payments got there first because that is where the money and the scrutiny were concentrated, but the logic generalises to anyone holding data worth taking: Replace cardholder data with credentials, case files, client records, or health data, and every sentence still holds. Any organisation that has a site that collects something worth taking, with monitoring that stops at HTTP, has the same blind spot.
And now the courts are saying it too
In February 2026, the Federal Court ordered FIIG Securities to pay $2.5 million in civil penalties for contravening section 912A of the Corporations Act over a four-year period, the first civil penalty for cyber security failures under the general financial services licensee obligations.
The detail that matters for everyone, regulated or not, is what the Court was careful to say: Preventing every attack is all but impossible and the mere fact of a successful cyberattack does not by itself mean an organisation failed its obligations. The finding against FIIG was not that it was breached. It was that it had not maintained adequate risk-management and monitoring systems, and had not consistently implemented the controls its own policies required.
The duty the Court enforced was not “be impenetrable.” It was “manage the risk, and be able to detect and account for what happens.” That is the same distinction this whole article turns on, but stated from the legal side: Prevention may eventually fail and if it does, the courts, insurers, and regulators are increasingly likely to ask whether you had the means to see the failure and respond to it.
The principle is not confined to financial services. Analyses of the judgment noted that the inadequacies were treated as failures of general statutory duty, building on the earlier ASIC v RI Advice decision, not breaches of a bespoke cyber standard. Layered on top are the Notifiable Data Breaches scheme and the recent privacy reforms, under which an organisation that cannot tell what was taken faces the worst of both worlds: A notification obligation it cannot properly discharge, and no evidence that it did the reasonable things beforehand.
The arithmetic from FIIG is uncomfortable: Implementing adequate controls over the relevant period would have cost roughly $1.2 million, against a total cost (penalty, legal costs, remediation, and an ongoing compliance programme) north of $4 million, before reputational damage and the 18,000 clients whose data was exposed. It remains cheaper, and far more manageable, to spend your own money on your own terms than to have the bill set by an attacker and a court.
The takeaway: Write the opera!
Security controls are only as good as their coverage, and prevention controls cover what they were told about in advance. CSP is an excellent defence against the threats it was designed for, but it was never designed to govern WebRTC. So the technique that was first reported in March continues to work, the entry bugs will probably keep coming, and the next attack may well use a channel nobody has written a control for yet.
The strategic response is not a better blocklist. It is the assumption that something will eventually run on your page that you did not put there, and the monitoring to catch it leaving, on any channel, whoever you are and whatever data you hold. If your detection and policy enforcement stop at HTTP, that is a blind spot, and it is the same blind spot whether the next attack uses WebRTC or something not yet named.
The strategic response is instead to look further ahead than patching the next vulnerability. Assume breach: Implement infrastructure and processes now, so that if preventative tactics eventually fail and if the courts, insurers, and regulators then ask whether you had the means to see the failure and respond to it, you can (with evidence) say yes!
Tactics dance to the tune of the attacker; strategies write the opera! The malware whose activity you cannot see is increasingly likely to become a breach that is much harder to defend, both technically and legally.
dotSec helps organisations across Australia identify, manage, and reduce cyber security risk, from web application and e-commerce security assessments through to managed detection and response. If you would like to understand where your exposure sits before an attacker shows you, get in touch.
References
[1] Sansec, “Novel WebRTC skimmer bypasses security controls at $100+ billion car maker,” March 2026. https://sansec.io/research/webrtc-skimmer
[2] Sansec, “PolyShell: unrestricted file upload in Magento and Adobe Commerce.” https://sansec.io/research/magento-polyshell
[3] BleepingComputer, “PolyShell attacks target 56% of all vulnerable Magento stores,” March 2026. https://www.bleepingcomputer.com/news/security/polyshell-attacks-target-56-percent-of-all-vulnerable-magento-stores/
[4] The Hacker News, “WebRTC Skimmer Bypasses CSP to Steal Payment Data from E-Commerce Sites,” March 2026. https://thehackernews.com/2026/03/webrtc-skimmer-bypasses-csp-to-steal.html
[5] W3C WebAppSec, CSP issue: “WebRTC can be used for exfiltration.” https://github.com/w3c/webappsec-csp/issues/92
[6] Mozilla Bugzilla, “Implement CSP ‘webrtc’ directive” (Bug 1783489). https://bugzilla.mozilla.org/show_bug.cgi?id=1783489
[7] Chrome for Developers, “Connection Allowlists origin trial: Secure your web application’s network,” April 2026. https://developer.chrome.com/blog/connection-allowlists-origin-trial
[8] PCI Security Standards Council, PCI DSS v4.0.1, Requirements 6.4.3 and 11.6.1 (best practice until 31 March 2025, required thereafter), June 2024. https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Standard/PCI-DSS-v4_0_1.pdf
[9] dotSec, “FIIG fined: Federal Court orders $2.5M penalty for cyber security failures,” February 2026. https://www.dotsec.com/fiig-federal-court-penalty/ — discussing Australian Securities and Investments Commission v FIIG Securities Limited [2026] FCA 92 (Federal Court of Australia, 13 February 2026).
[10] Australian Securities and Investments Commission v RI Advice Group Pty Ltd [2022] FCA 496 (Federal Court of Australia).
[11] CrowdStrike, “Inside CrowdStrike’s takedown of a developer-targeting botnet” (GlassWorm), May 2026. https://www.crowdstrike.com/en-us/blog/inside-crowdstrike-takedown-of-a-developer-targeting-botnet/
[12] Check Point Research, “When AI trust breaks: the ChatGPT data-leakage flaw,” March 2026. https://blog.checkpoint.com/research/when-ai-trust-breaks-the-chatgpt-data-leakage-flaw-that-redefined-ai-vendor-security-trust/
[13] PCI Security Standards Council, Payment Page Security and Preventing E-Skimming — Guidance for PCI DSS Requirements 6.4.3 and 11.6.1. https://docs-prv.pcisecuritystandards.org/PCI%20DSS/Supporting%20Document/Guidance-for-PCI-DSS-Requirements-6_4_3-and-11_6_1-r1.pdf
Premier Australian cyber security specialists
