StyleSmuggler: The Magento Flaw That Turns a Template Into a Backdoor

Adobe patched a maximum-severity zero-day. You’ll want to apply it fast, but what if someone already got inside, and what if data is leaving your checkout right now?

Adobe has shipped emergency fixes for a flaw in Adobe Commerce and Magento Open Source that attackers were already exploiting before a patch was available. The vulnerability is tracked as CVE-2026-75650 and given a maximum score of 10.0. Researchers at Sansec named it StyleSmuggler, after they observed it being used as a zero-day beginning on September 4, 2026. It gives an attacker full remote code execution on the store’s own server, with no login, credentials, or user interaction required.

How StyleSmuggler works

The attack abuses Magento’s template engine. By injecting PHP into the flow that generates a routine “Payment Transaction Failed Reminder” email, an attacker gets their code executed on the server as that message is assembled. In the words of Disrex, a Dutch web development and hosting agency, the technique turns Magento’s own template-processing and dependency-injection code into an unauthenticated remote-code-execution chain. In other words, it turns a legitimate, built-in feature into the delivery mechanism:

1. An unauthenticated request injects PHP via the template system.
2. Code executes as the “Payment Failed Reminder” email is built.
3. Payload dropped: a Rust backdoor and a PHP web shell.

The payloads seen in the wild clearly show the intent. One is a Rust-based Linux backdoor designed to connect to an external command-and-control server for instructions. The other is a PHP dropper that writes a web shell, a small file that lets the attacker run arbitrary PHP on demand. It’s effectively a permanent remote control panel on the compromised store.

Why the timing matters

This is a case where prevention and detection are not the same thing. Disrex reported that a Magento server it manages was compromised a mere 50 minutes after the first confirmed StyleSmuggler exploitation was observed, and that store was fully patched and running an active commercial security module at the time. Disrex’s blunt takeaway was that patch status made no difference here. Any merchant still exposed when exploitation began risked closing the door on a break-in that had already happened.

What to do right now

Patching closes the door, but it doesn’t tell you who already walked through it, or what they left running.

The blind spot that outlives the patch

Here’s the part that’s keeping e-commerce security leaders up at night. Server-side code execution is rarely the endgame on a store; it’s the way in. The prize is the stream of customer and payment-card data moving through the checkout, and historically the way that data gets stolen is in the browser.

The classic follow-on to a Magento compromise is a client-side skimmer: attackers add a new snippet of JavaScript, or subtly change an existing one, so it reads what shoppers type into the payment form and ships it to a server they control. That behavior happens on the page your customers actually load, and it’s invisible to server-side EDR, invisible to your WAF’s request logs, and invisible to the patch you just applied. The upshot is that you can be fully remediated at the server and still be leaking card data from the front end.

To be precise about StyleSmuggler itself: in the two compromises Disrex documented, responders didn’t find a skimmer, and no data left the browser. One implant simply read session data from the store’s own Redis and never called out, but that won’t always be the case. The same server access that drops a quiet backdoor can also be used to plant a skimmer at any point in the future, and Magento’s breach history (Magecart, CosmicSting, last year’s SessionReaper) is overwhelmingly a story of stolen checkout data. Removing the backdoor from the server is essential, but it says nothing about what might be lingering in the browser.

Where Reflectiz fits

Watching the front end, where the money leaves

Reflectiz continuously maps every component running on your pages, including first-, third-, and fourth-party scripts, tags, trackers, and services. It then builds a baseline of what “normal” behavior looks like for each of them. It alerts you when one of them departs from that baseline and starts behaving differently, for instance:

• A new or modified script appears on your checkout or payment pages.
• An existing component starts reading form fields it never touched before.
• Data begins flowing to an unfamiliar or unexpected destination. This is the tell-tale signature of a Magecart-style skimmer siphoning checkout data.

For merchants working toward PCI DSS 4.0, this maps directly onto requirements 6.4.3 and 11.6.1, which call for inventorying and monitoring the scripts on your payment pages and detecting any unauthorized changes to them. That is precisely the behavior a checkout skimmer would trigger.

StyleSmuggler is a reminder that on an e-commerce site, the breach doesn’t end at the server; it ends at the checkout. So, the question isn’t whether your payment page will be targeted, but whether you’ll see it happening.