Magento Has Another Zero-Day — and Attackers Are Already Backdooring Stores
- The Mess: Attackers are actively exploiting a new zero-day in Magento Open Source and Adobe Commerce to execute code without authentication and install persistent backdoors on online stores. The flaw has been dubbed StyleSmuggler, and stores are already being compromised.
Magento store owners have a problem.
And this time, patching yesterday doesn’t necessarily save them.
Researchers at Sansec say attackers began exploiting a previously unknown vulnerability on September 4. The bug affects Magento’s server-side processing and gives an attacker a path to execute malicious code without logging into the store.
No stolen admin password.
No customer account.
No phishing campaign.
Just a vulnerable store reachable over the network.
Sansec named the vulnerability StyleSmuggler and published its findings early because attacks were already happening.
The researchers reproduced the full unauthenticated attack chain on clean Magento Open Source installations running versions 2.4.7, 2.4.8 and 2.4.9. Their first confirmed victim was running Magento 2.4.6-p15 with Adobe’s July and August 2026 security updates already applied.
That’s the part merchants really don’t want to hear.
The store was patched.
The attackers still got in.
The attack abuses Magento’s own functionality to get malicious PHP code written into files that the platform later processes.
The attacker then triggers another normal Magento feature.
Magento processes the poisoned content.
The code runs.
No employee has to open anything.
No administrator has to click a link.
The server does the work for the attacker.
- The Damage: A successful exploit gives attackers code execution on the store server and can install a persistent backdoor, opening the door to stolen sessions, payment secrets, administrator credentials and deeper access to the hosting environment.
This is not a smash-and-grab attack.
The operators behind the campaign appear interested in persistence.
Incident responders investigating compromised stores found malware disguised as a Linux kernel worker process.
The implant used a name resembling:
[kworker/u:8:0]
But it wasn’t a kernel worker.
It was a user-controlled process hiding behind a familiar-looking name.
The malware was installed outside the Magento web root, under the site user’s home directory, and configured to survive through cron-based persistence.
That matters.
A basic web-root malware scan may completely miss it.
The attacker is no longer necessarily living inside the directory administrators expect to inspect.
The compromised process can also interact with services local to the store.
In one investigated incident, responders found the implant communicating with the store’s own Redis instance and reading Magento session data.
No dramatic command-and-control traffic was required.
The malware was already inside.
And the useful data was already sitting on the local network.
Independent incident-response work from Disrex Group also supports the conclusion that this is not merely a theoretical vulnerability.
The company said it handled compromised Magento stores and observed attacks against another store that did not result in a breach.
That gives defenders a much more uncomfortable picture.
This isn’t someone publishing a scary proof of concept and waiting to see what happens.
Attackers were already moving before most store owners knew the vulnerability existed.
- The Fix: Until Adobe ships and confirms an official fix, Magento operators should reduce exposure immediately, disable GraphQL where their deployment allows it, inspect servers for persistence and assume that a previously exposed vulnerable store may already need incident response.
At the time the vulnerability was disclosed, there was no CVE identifier, official Adobe advisory, vendor patch or confirmed complete workaround specifically for StyleSmuggler.
Sansec’s immediate recommendation was to disable GraphQL where possible.
That isn’t painless.
Headless storefronts and some progressive web applications depend on GraphQL.
Classic Magento deployments may have more room to disable it temporarily.
Either way, the decision is now between operational inconvenience and leaving an actively exploited zero-day exposed.
Administrators should also hunt for signs of compromise.
Look beyond the web root.
Check the site user’s home directory.
Inspect unexpected processes with names designed to resemble Linux kernel threads.
Review cron persistence.
Look for suspicious files and processes that reappear after removal.
And investigate unusual activity around Magento session storage.
If compromise is confirmed, don’t just delete the obvious backdoor and move on.
Rotate Magento administrator credentials.
Rotate payment-provider credentials.
Rotate API keys.
Rotate secrets stored in Magento configuration.
Invalidate exposed sessions where possible.
An attacker with code execution on the store may have already copied the secrets needed to come back later.
The attackers don’t need the original zero-day forever.
One stolen key can be enough.
One persistent account can be enough.
One copied session can be enough.
This is also a reminder that “fully patched” is not the same thing as “safe.”
A zero-day does not care about your patch dashboard.
It exists in the space between the vulnerability being discovered and the vendor shipping a fix.
And that space is where attackers are operating right now.
Bugstoday’s Opinion
Magento stores have spent years dealing with a simple rule:
Patch fast, or someone else will patch your server for you.
StyleSmuggler adds an even uglier version of that rule.
Sometimes there is nothing to patch yet.
The first known victim was already running the latest available security updates.
That is the zero-day nightmare in its purest form.
You did what you were supposed to do.
The attacker still got in.
And once inside, they didn’t just vandalize the storefront.
They installed persistence.
They hid outside the web root.
They blended in with Linux process names.
They went after the infrastructure sitting behind the store.
This is why e-commerce breaches are rarely just website problems.
A compromised store can mean customer sessions.
Payment integrations.
API credentials.
Administrative access.
And potentially the entire hosting account.
For now, Magento operators need to stop asking whether this bug is theoretical.
It isn’t.
The stores are already getting backdoored.
Today’s Bugs. Tomorrow’s Breaches.
Technical Sources
Sansec — StyleSmuggler Threat Research
The Hacker News — Independent Incident Reporting
Disrex Group — Incident Response Research
Adobe Commerce Security Bulletins
