StyleSmuggler: A Magento Zero-Day Adobe Hasn't Patched Yet

Sansec disclosed a Magento zero-day on September 5. They're calling it StyleSmuggler: unauthenticated remote code execution in Magento Open Source and Adobe Commerce, ending in a backdoor that runs on the store server. The first attack they confirmed was the previous evening, September 4 at 22:20 UTC. There's no CVE, no Adobe advisory and no patch.

Sansec normally sits on a write-up until the analysis is finished. They published this one with the gadget chain deliberately left out, saying stores were being compromised while they wrote it.

Being up to date doesn't get you out of it. Sansec reproduced the attack on clean installs of 2.4.7, 2.4.8 and 2.4.9, and one of the victims was running 2.4.6-p15 with July's and August's patches applied.

What's public, and what isn't

Sansec described the shape of the attack and held back the details that would let somebody rebuild it:

• It arrives as a POST to /graphql carrying a styles[...] parameter. The styles property is what gets it past the safeguards that would normally stop template injection.
• Stage one writes PHP into a file Magento generates itself, under var/report or into var/log/system.log.
• Stage two makes Magento include that file, by deliberately triggering the store's own "Payment Transaction Failed Reminder" email. The code runs when the email renders, so nobody has to open anything.

Disrex, working the same incident, put the sink in Magento's dependency-injection compiler scanners — three methods that read a PHP file from a variable path and exist only to serve bin/magento setup:di:compile. ProxiBlue published the identical guard independently. That's a community reading of the bug and not Adobe's, and Sansec's full breakdown is still to come.

What lands afterwards is well documented. A background process masquerading as [kworker/u:8:0], a crontab entry that re-executes it every five minutes, and files under ~/.local/share/.gvfsd/ and /tmp/.kw_*.

Indicators Sansec published

Check before you block

If the implant is already on the server, firewalling the entry point accomplishes nothing — it re-executes itself every five minutes and doesn't need the vulnerability again.

So run the checks first:

crontab -l | grep -i gvfsd
ls -la ~/.local/share/.gvfsd/ /tmp/.kw_* 2>/dev/null
ps aux | grep -F 'kworker/u:8:0'
grep -Ral --fixed-strings '<?' var/report/ var/log/
grep -Fal 'array_merge()' var/log/system.log

Then your access logs, for the delivery attempt itself:

grep -F -e 'styles[' -e 'styles%5B' /var/log/nginx/access.log*

eComscan 1.9.7 has signatures for the implant, and Sam James suggests running it with --skip-dashboard --format=json --min-confidence=0 --deep. None of it is conclusive. A clean pass means the checks you ran didn't match, and Sansec hasn't published the whole chain yet.

Mitigations, in the order we'd apply them

Block GraphQL if you can. This is Sansec's own interim advice for anyone not behind their firewall, and /graphql is the only delivery route anybody has published. Whether you can afford to do it depends entirely on your storefront: a PWA or headless frontend, a mobile app, and some checkout and search extensions all speak GraphQL and will stop working. A conventional Luma store usually isn't touching it. Check the access logs before you decide, and do the blocking at nginx or your CDN.

Apply the unofficial guard, with your eyes open. Disrex and ProxiBlue both add one line to three DI scanner methods:

if (PHP_SAPI !== 'cli') {
    throw new RuntimeException('Magento DI scanners are CLI-only.');
}

Those scanners exist to serve setup:di:compile and are never legitimately reached over HTTP, so the guard removes the sink without changing how the store behaves. It's tested against 2.4.6 through 2.4.9. The caveats are the authors' own: the repository was written with AI assistance during a live incident, hasn't been through review, and carries no warranty. Read the patch, apply it on staging, and take it back out when Adobe ships a real fix.

Disrex also publish web server rules that block styles[, template directives and PHP tags in query strings. They say themselves that those are bypassable by design, because nginx and Apache can't see into a POST body and the parameter can move there.

Harden the server. Add proc_open to disable_functions and mount /tmp with noexec. Do the disable_functions change on the FPM pool only — Composer and most deploy tooling go through Symfony Process, which needs proc_open, so a global ban stops your deploys.

A WAF covers the gap, not the bug. Sansec had a Shield rule out at 07:15 UTC on September 5. We have no commercial relationship with Sansec and get nothing if you buy from them; we run eComscan on client stores and Shield on stores that kept getting reinfected. A firewall blocking a known request shape is not the same thing as the hole being closed, and that distinction matters more than usual while the full chain is still unpublished.

If you find it

Assume everything on the server is gone, starting with app/etc/env.php and the encryption key. Rebuild the application from source instead of disinfecting in place, restore the database from a point you trust, then rotate the crypt key, admin credentials, API tokens, integration keys and payment gateway credentials, and invalidate customer sessions.

We've watched stores get cleaned three times because the cleanup dealt with the files and not with the rogue admin account, the database trigger or the cron entry left behind.

September 8

Adobe had a security release scheduled for September 8 before any of this started, and hasn't said whether StyleSmuggler is in it. Its most recent Commerce bulletin is still APSB26-92 from August 11.

If the fix does land on Monday, it'll arrive in the usual form — an isolated patch per version line, needing the latest -p release for that line, with September stacking on top of August the way August stacked on July. A store that's current applies it in an afternoon. A store that's a year behind on -p releases has an upgrade to do first, and this is a bad week to be finding that out.

Emyrix does Magento security work and ongoing support, including patch management, compromise investigation and cleanup on stores that have already been hit. If you think StyleSmuggler has reached your store, or you want someone to check, get in touch.

Sources: Sansec: StyleSmuggler — Magento and Adobe Commerce 0-day RCE under active attack · The Hacker News: Unpatched Magento and Adobe Commerce zero-day exploited to backdoor online stores · Disrex: StyleSmuggler emergency mitigation · Sam James: StyleSmuggler zero-day · Adobe Security Bulletin APSB26-92