StyleSmuggler doesn't care about your patch level

There's a zero-day being actively exploited against Magento and Adobe Commerce right now. Sansec disclosed it on 5 September 2026, they've called it StyleSmuggler, and as of writing there's no Adobe patch and no CVE. If the name makes you think of a CSS trick or a Magecart skimmer, that's the wrong picture — this one hands an attacker code execution on your server, no login required.

Here's the fact that should worry you more than any of the technical detail: the first confirmed victim was running a fully patched 2.4.6-p15 store, with July and August patches applied and a clean `security:patch-status`. This isn't a story about someone who forgot to patch. Patch level does not protect you here.

What StyleSmuggler actually does

It's a two-stage chain. First, the attacker gets Magento to write a PHP payload into a file Magento already trusts and writes to itself — a log or an error report. One known route is sending a deliberately invalid store code: Magento rejects it, but logs the rejected value verbatim into `var/log/system.log`, payload and all.

Second, the attacker abuses Magento's dependency-injection code scanners — the bits of code built solely to serve `bin/magento setup:di:compile` on the command line, never meant to see an HTTP request — to `include` that poisoned file. And the thing that triggers it is Magento's own internal "Payment Transaction Failed Reminder" email being rendered. Nobody has to open it. It doesn't even need to send successfully. The moment Magento builds that email, the poisoned code runs.

The backdoor it drops

Once it's in, it drops a small Rust binary and renames itself `[kworker/u:8:0]` to look like a kernel thread in a process list. It lives a level above the docroot, so anything scanning your webroot walks straight past it, and it persists by writing a `*/5` cron line directly to the crontab spool file — which respawns it every five minutes without ever showing up as a `crontab REPLACE` in syslog. On at least one compromised store it made zero outbound network connections at all; it just sat reading the store's own Redis session data over loopback, which is why watching for suspicious outbound traffic alone won't catch it.

There's a useful forensic tell if you're checking logs: `include` on a file with no `return` statement returns `1`, so the very next line of code throws a `TypeError` straight into `system.log`. If you see that error sitting near a rejected store-code entry, treat it as evidence the exploit succeeded, not just that someone tried.

“Patch status was irrelevant here, which is the part merchants most need to hear.”— Disrex Group, on the two stores it handled this week

Why "just patch" doesn't work this time

There is no patch to apply. Adobe hasn't published a CVE, an advisory, or a fix as of writing. That flips the usual playbook. With SessionReaper, CosmicSting and PolyShell, the story was always slow patch uptake — a fix existed and most of the install base just didn't apply it fast enough. Here, patching isn't even on the table yet. The entire game right now is interim mitigation and honest detection.

What I'd actually check and do today

• Check your process list for a bracketed name like `[kworker...]` running under a real site user rather than root, with actual memory usage — genuine kernel threads never look like that.
• Grep `var/log/system.log` and `var/report/` for stray `<?php` sitting inside what should be a plain log line.
• Check crontab for anything referencing `.gvfsd` or `.kw_`, and look under `~/.local/share/.gvfsd/` for a file that has no business being there.
• Disable GraphQL if your storefront doesn't need it — most classic Luma and Hyvä storefronts don't, and it's the one interim step Sansec is recommending directly.
• Add `proc_open` to `disable_functions` and mount `/tmp` `noexec`. These aren't specific to this exploit, but they close off the exact mechanism the dropper relies on to launch its payload.

Most merchants don't have the time at 11pm to stitch this together from a Sansec advisory and three different GitHub repos, so I built on Disrex Group's mitigation package and added the web-server rules and a compromise-checker script I was already writing for clients anyway.

Why Sansec, not just my patch

I want to be straight about what my patch repo is and isn't. It's stopgap engineering from someone who builds and fixes Magento stores for a living, not a substitute for dedicated detection expertise. Sansec found this, reproduced the full unauthenticated chain within hours, and had blocking rules live in Sansec Shield before most of us had finished reading the advisory. If a client can stretch to it, Sansec's own tooling — Shield, eComscan — is the properly resourced answer here. My patches are what you run in the meantime, or if that budget genuinely isn't there.

The short version

• There is no Adobe patch yet — this is being actively exploited without one.
• Your patch level doesn't protect you. A fully patched 2.4.6-p15 store was the first confirmed victim.
• Check for compromise before you do anything else — the implant hides outside the webroot and can run with no outbound traffic at all.
• My patches and Sansec's interim advice buy you time. Neither one fixes the bug, because there isn't a fix to apply yet.
• If the budget allows, Sansec is the properly resourced answer — they found this and they're watching it live.

If you run a Magento store and want a hand applying the patches, checking for compromise, or just want someone to look over your shoulder while this plays out, that's a conversation I'm happy to have — get in touch.