StyleSmuggler Magento RCE: What It Is and What to Do Now

If your Magento store was reachable between September 4 and the moment you applied Adobe’s hotfix, you have two jobs this week, not one. Patch, then find out whether someone already walked in.

Sansec disclosed Magento StyleSmuggler on September 5. Attacks had already been running since September 4, three days before a fix existed. Here is what the vulnerability does, how to apply Adobe’s hotfix, and how to check whether your store was hit before you got to it. If you would rather not do it alone, our Magento development team has been working with the platform since 2008 and can audit your store and apply the patch for you.

What Is Magento StyleSmuggler?

The Magento StyleSmuggler vulnerability lets an unauthenticated attacker execute code on your server. No Admin account, no credentials, no user interaction. Attacker-controlled data reaches Magento’s template system through styles properties and gets executed when Magento renders content on the server, which is why the attack chain runs through the “Payment Transaction Failed Reminder” email path.

Code execution is not the end of it. Observed attacks install a persistent backdoor that lives outside the Magento document root, in the web user’s home directory, and reinstates itself through cron.

Adobe published APSB26-146 on September 7. The Magento StyleSmuggler RCE is now CVE-2026-75650, rated Critical, scored CVSS 10.0, and given Priority 1, Adobe’s highest. Adobe confirms exploitation in the wild.

Is My Magento Store Affected?

Adobe ships the fix as a hotfix, VULN-39341, not as a full release. It was tested against the 2026-aug builds of these branches:

If you are on an older Magento Open Source branch, do not assume the standard hotfix applies to you. Treat it as an urgent upgrade question as well as a security one.

Being current did not protect anyone. Sansec reproduced the full unauthenticated chain on clean installations of 2.4.7, 2.4.8 and 2.4.9. The first confirmed victim was running 2.4.6-p15 with July’s and August’s security patches applied and a clean security:patch-status. Every “are we current?” dashboard in that business was green while the store was being exploited.

One scheduling note: Adobe’s regularly scheduled September update, APSB26-138, landed on September 8. The StyleSmuggler hotfix does not replace it. Apply both.

What to Do Now

1. Apply the VULN-39341 hotfix.
2. Verify that it actually landed.
3. Check whether your store was already compromised.
4. Rotate every credential that may have been exposed.

Steps three and four are the ones teams skip. Patching closes the door. It does not remove anyone who is already inside.

How to Apply the VULN-39341 Hotfix

Take a backup and test in staging first. On a patch this urgent it is tempting to skip both, and Adobe asks for both.

Download VULN-39341-composer-patches.zip from repo.magento.com using your Magento authentication keys, unzip it, and pick the patch matching your version. Adobe’s example file name is VULN-39341_Hotfix_COMPOSER.patch. From there the procedure splits by hosting.

Adobe Commerce on cloud infrastructure

Create an m2-hotfixes directory in your project root if you do not have one, copy the patch file into it, then commit and push to trigger the deploy.

git add -A
git commit -m "Apply VULN-39341 hotfix for CVE-2026-75650"
git push origin

Adobe Commerce on-premises and Magento Open Source

Upload the patch to your Magento root and apply it over SSH. If -p1 fails, Adobe’s fallback is -p2. Then refresh the cache under System > Cache Management.

patch -p1 < VULN-39341_Hotfix_COMPOSER.patch

Verify it landed

Adobe notes there is no easy way to tell by inspection whether the fix is in place, so check it explicitly with the Quality Patches Tool.

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

VULN-39341 should come back with an Applied status. If it is missing, the patch did not take, whatever the deploy log said.

How to Check Whether Your Store Was Compromised

Run these from the Magento root as the PHP-FPM user, then repeat the process check as root.

crontab -l | grep -i gvfsd
ps -eo pid,user,comm,args | grep -iE 'kworker|fc-cache|chronyd' | grep -v ' root '
ls -la ~/.local/share/.gvfsd/ /tmp/.kw_* /tmp/.gvfsd-* 2>/dev/null
grep -ril 'x_trace_' var/report/ var/log/

A kworker process owned by anything other than root is not a kernel thread. It is the implant.

Three things to keep in mind while you look:

• A scan of the Magento directory is not enough. The implant installs outside the document root, so a malware scan limited to your project folder can report the store clean while the backdoor runs from the home directory.
• Look at outbound UDP, not just HTTPS. Command traffic has been shaped to look like NTP on port 123, pointed at typosquatted hostnames that survive a glance at a firewall log.
• An unexplained burst of “Payment Transaction Failed Reminder” emails is worth investigating. Ordinary declined payments produce the same email, so it is not proof on its own. Alongside anything above, it matters.

Payloads have changed several times a day since September 4, and a second, unrelated attacker is now exploiting the same bug to drop PHP web shells. For current file and network indicators, work from the live Sansec advisory rather than a copy of it from three days ago.

Rotate the Secrets, Including the Ones Outside Magento

If your store was reachable during the exposure window, Adobe’s own remediation says to treat your secrets as taken. That means:

• The encryption key
• Every Admin panel password
• All REST, SOAP and GraphQL integration tokens
• OAuth client secrets for connected apps
• Payment gateway credentials, rotated at the gateway itself

That last line is where teams stop short, and it is the expensive mistake. Rotating the Magento encryption key does not invalidate a credential an attacker already read. Anything the PHP process could reach, rotate at the source.

If You Find Signs of Compromise

Stop treating it as cleanup. Killing the suspicious process is not remediation, and the cron entry will simply bring it back, so remove the persistence first. Then assume there is more than one payload, because there has been on real stores. Isolate the environment, work through secondary backdoors, and rotate credentials as above before you put the store back in front of customers.

The Part That Outlasts This Week

StyleSmuggler will be cleaned up. The structural problem it exposed will not be.

A store on an unsupported Magento Open Source version has no vendor between it and the next maximum-severity bug. There was no fix for those merchants this time and there will not be one next time. If you have been treating an upgrade as a nice-to-have on a roadmap, this week is the argument for moving it. We are currently running $250 off Magento upgrade services, and if you would rather do it yourself, do it yourself. Just do not stay where you are.

Get Your Store Checked by Plumrocket

We have worked with Magento and Adobe Commerce since 2008. We will check your store against the known StyleSmuggler indicators and send you a detailed report with what we found and what to do about it.

To be clear about what that is: a check against published indicators tells you whether the known implants are present. It is not a forensic guarantee, and if we find something, what you need next is incident response, not a patch.

Get a Store Security Check →