StyleSmuggler: the Magento zero-day (and what we’re doing about it)

On the evening of 4 September, attackers began exploiting a previously unknown bug in Magento and Adobe Commerce. Sansec, the Dutch security firm who found it, named it StyleSmuggler and published their analysis the next morning. Adobe released a hotfix on the evening of 7 September, three days after the attacks started. Every version from 2.4.4 to 2.4.9 is affected, and the first known victim had the July and August security patches installed.

If you run a Magento or Adobe Commerce store with us: we’ve put ModSecurity rules in place that block the known forms of the attack before they reach Magento. The rest of this post explains what the bug is, what we did, and what you should do now.

Our rules were built from Sansec’s published research and the attack traffic seen so far, before any official patch existed. They are a best-effort mitigation, not a fix. Now that Adobe have released one, patching is the priority.

What StyleSmuggler is

StyleSmuggler is an unauthenticated remote code execution bug. Someone with no account and no access to your store can run their own code on the server it lives on. The attack has two parts.

Getting the code in. Magento builds emails and other content using a template system, and that system has been attacked before. After recent high-profile vulnerabilities, Adobe added checks to stop people putting code into templates. StyleSmuggler avoids those checks by putting the PHP inside the styles properties of a request, which they don’t look at. Sansec have seen it sent through the public GraphQL endpoint, and stored on disk by deliberately causing an error report to be written.

Getting Magento to run it. The attacker then triggers one of Magento’s standard notifications, the “Payment Transaction Failed Reminder” email. When Magento renders that email, the injected code runs. Nobody has to open the email, and it doesn’t matter if the email is never delivered. The code has already run on the server by then.

Payment failure emails are a normal part of running a shop, so a few extra ones are easy to miss. Nothing in the admin panel or on the storefront changes.

What gets installed

Once the code runs, it downloads a small backdoor written in Rust and starts it in the background. The process names itself [kworker/u:8:0], which looks like a Linux kernel thread, or after a common system tool such as fc-cache or chronyd. It has been renamed twice since 4 September. It copies itself into hidden directories under the user’s home and adds a cron job so it comes back if killed.

The backdoor is designed to look like innocuous system traffic. Every minute it sends a 48-byte UDP packet to port 123 on a hostname like ntp.timesync.to. To a firewall that looks like a server checking the time. Only the first four bytes are real NTP. The rest carries the store’s hostname, username, OS, memory and disk usage, and whether it’s running as root. Sansec’s words: it “passes most egress filtering unremarked”.

So far Sansec have seen no sign of the backdoor being used for anything. On an e-commerce site the usual next step is card skimming, but it’s not yet clear exactly what the backdoor’s purpose is. Sansec have also seen a second, unrelated attacker using the same bug to drop a PHP web shell, so this is no longer one group’s campaign.

What we did

We keep an eye on Sansec, Adobe’s bulletins and a few other sources as part of our routine security monitoring, so we saw the StyleSmuggler write-up on the morning of 5 September and treated it as an incident.

With no patch available, we wrote ModSecurity rules that catch the styles payloads on the entry points Sansec described, and rolled them out across our platform. If the code can’t get in, the failed payment email has nothing to run.

That has limits. We didn’t have Adobe’s view of the bug, only what Sansec had published and what we could see in requests. Sansec have since noted that the operators changed their payloads several times a day, and that the attack surface behind this bug is large. A determined attacker with a variant nobody had documented could have found a way round our rules. Until the patch landed, that was the position every Magento store was in, whoever hosted it.

Doing it at the web server has some advantages over a patch:

• It covers every version of Magento we host, whatever its patch level.
• Nobody had to change anything on their store, and there was no downtime.
• It stays in place now that Adobe have shipped a fix, which helps with stores that are slow to update.

So: a firewall rule is a workaround, not a fix. Adobe published theirs on the evening of 7 September, a day ahead of their scheduled security release. Apply it. The rules will stay in place either way.

What you should do

Patch now. Adobe’s fix is security bulletin APSB26-146, delivered as an isolated hotfix rather than a full release. Download VULN-39341-composer-patches.zip from repo.magento.com, apply it as a composer patch, then confirm it took:

vendor/bin/magento-patches -n status | grep "39341\|Status"

Adobe tested the hotfix against the August 2026 releases of 2.4.4 through 2.4.9. Older releases in those branches are affected too, but the patch hasn’t been verified on them, so if you’re behind on point releases this is the moment to catch up.

Adobe also recommend rotating your encryption key and every credential it protected: admin passwords, integration tokens, payment gateway credentials, database credentials, SSH and deploy keys. Rotate them at the source, not only inside Magento. Changing the key on its own doesn’t invalidate anything an attacker has already read.

If your store is with Prostack, our rules have been in front of your store since 5 September, but they don’t replace the patch. Apply the hotfix, or get in touch if you’d like us to help. Keep an eye out for unexpected runs of “Payment Transaction Failed Reminder” emails. If you disabled GraphQL on our earlier advice, you can turn it back on once the hotfix is confirmed installed.

If your store is hosted elsewhere, check for compromise before you patch. Stores were being exploited for three days before the hotfix existed, and patching closes the hole without cleaning up anything already inside. Sansec published the commands to look for the implant. Run them as the Magento user:

crontab -l | grep -i gvfsd
ls -la ~/.local/share/.gvfsd/ ~/.cache/fontconfig/fc-cache /tmp/.kw_* /tmp/.cache_* /tmp/.gvfsd-* /tmp/.fc-*/fc-cache /tmp/fc-cache /tmp/.chrony-*/chronyd 2>/dev/null
ps -eo pid,comm,args | grep -iE 'kworker|fc-cache|chronyd'
grep -r 'crontab command not allowed' /var/log/
grep -ril 'x_trace_' var/report/

If any of those return something you don’t recognise, treat the store as compromised, rotate your credentials and get help. If they come back clean, patch, and then ask your host what they did about StyleSmuggler in the three days before a patch existed.

Why this keeps happening

We wrote in June about the strange new world of server security. Bugs in common software are turning up more often, and the time between a bug being found and being exploited is getting shorter. With StyleSmuggler there was no gap at all. Stores were being compromised before anyone but the attackers knew the bug existed. Adobe turned a fix around in three days, which is quick for a bug like this. It was still three days of stores being compromised.

You can’t patch a zero-day. What you can do is have someone notice within hours, understand the attack well enough to block it, and get that block onto every server before the next wave.

If you run an online store and want that sort of attention on your hosting, have a look at our eCommerce hosting or talk to us.

Sources and thanks

Most of what we know about StyleSmuggler comes from Sansec, who published their findings quickly, during a live incident, so that others could act. Thanks to them.

• StyleSmuggler: Magento and Adobe Commerce 0-day RCE under active attack. Sansec’s advisory, which found the campaign, reproduced the exploit chain and published the indicators of compromise.
• Security update available for Adobe Commerce, APSB26-146. Adobe’s bulletin for CVE-2026-75650, with the VULN-39341 hotfix and the credential rotation checklist.