News
StyleSmuggler: The Actively-Exploited Magento Zero-Day, and What to Do Now
September 7, 2026 - by Alexandru-Manuel Carabus
There is a Magento vulnerability being exploited in the wild right now. StyleSmuggler hits current Magento Open Source and Adobe Commerce, versions 2.4.7 through 2.4.9, needs no login, and the attacks started over the weekend of 4 September. Here is what it is, who is affected, and exactly what to do now.

There is a Magento vulnerability being exploited in the wild right now, and if you run a store you should not wait until Monday to deal with it. It is called StyleSmuggler, it was found by the researchers at Sansec, it affects the current versions of Magento Open Source and Adobe Commerce, and it needs no login and no user interaction to run code on your server. The attacks started over the weekend of 4 September 2026. Here is what it is, who is affected, and exactly what to do now.
Update, 22 September 2026. This post went up while StyleSmuggler was still an unpatched zero-day. Adobe has since shipped an emergency hotfix, the flaw is now tracked as CVE-2026-75650 with a CVSS score of 10.0, and CISA added it to the Known Exploited Vulnerabilities catalogue on 8 September. The affected range is also considerably wider than was known on the day we published. The sections below have been corrected. If you have not applied the hotfix yet, do that before you read the rest.
What StyleSmuggler is
In plain terms, StyleSmuggler smuggles malicious code through Magento’s template system, hiding it inside style-related properties in a way that slips past the platform’s existing safeguards. The injected code then executes when Magento renders a specific system email, the payment-transaction-failed reminder. The dangerous part is the combination: an attacker does not need to be logged in, and the victim does not need to click anything. That is what turns a template quirk into code running on your server. We are deliberately not publishing the how, and neither did the researchers; what store owners need is the shape of the risk and the response.
Who is affected, and why upgrading will not save you
This is the part that stings, and it reaches a good deal further than the newest release. Adobe lists Adobe Commerce from 2.4.4 up to and including 2.4.9, Magento Open Source from 2.4.6 to 2.4.9, and Adobe Commerce B2B from 1.3.3 to 1.5.3. Treat any 2.4 store as affected until you have checked it. Sansec documented a victim running 2.4.6-p15 with the July and August 2026 security patches applied, so being fully patched up to the previous month did not protect these stores either. When the attacks began there was no fix in any version. This was a genuine zero-day.
It is being exploited right now
This was never a theoretical advisory. Sansec observed live attacks beginning late on Friday 4 September 2026, three days before a fix existed. That timing was not an accident. Attackers launch on Friday nights and over weekends precisely because that is when stores are least watched and slowest to respond. Adobe did not wait for its scheduled release: it published bulletin APSB26-146 out of band on the evening of Monday 7 September at 20:20 UTC, with priority 1, its highest. CISA added the CVE to its Known Exploited Vulnerabilities catalogue the following day and gave federal agencies until 11 September to remediate, which is a useful signal of how it was rated outside Adobe as well.
What to do now
Treat this as an active incident, not a maintenance ticket. In order:
- Apply the hotfix. The fix ships as a hotfix rather than a full release. Download VULN-39341-composer-patches.zip from repo.magento.com and apply it as a composer patch, then confirm it took by running vendor/bin/magento-patches -n status and looking for 39341 in the output. Test on staging first so the fix itself does not break checkout.
- Restrict GraphQL. Sansec’s recommended mitigation is to block Magento’s GraphQL endpoint at the web server or firewall level if your store does not use it. Most classic, non-headless storefronts do not need it exposed. If you run a headless or PWA storefront that depends on GraphQL, you cannot simply switch it off, so lock it down with rules and watch it closely.
- Scan for compromise. Check your store against the indicators of compromise Sansec published, and scan your codebase and database for injected code and backdoors. On compromised stores Sansec found a Rust backdoor and PHP web shells in the media directories, with the malicious processes running under ordinary-looking names such as kworker, fc-cache and chronyd. If your store was reachable over the weekend of 4 September, assume it was probed.
- Rotate the encryption key, not only the passwords. Adobe is explicit that the hotfix alone is not enough. Rotate the Magento encryption key and everything it protects: admin passwords, REST, SOAP and GraphQL integration tokens, OAuth client secrets, payment gateway API credentials, database credentials, and SSH and deploy keys. If anything looks wrong, isolate the store, clean it, and restore from a known-good backup rather than hoping you removed everything.
Why even up-to-date stores got caught
This is the second painful Magento security event in a short span, after SessionReaper, and the lesson is the same one, worth repeating because it keeps being true. Owning a self-hosted store means owning its security, and security is not a one-time upgrade you finish. It is patching fast, monitoring for the attacks that arrive before the patch does, and having someone actually watching on the Friday night when the attack lands. A store nobody is watching is the store that gets found first. We wrote the evergreen version of this in the Magento security checklist and told the SessionReaper story in the SessionReaper piece.
How we are handling it for the stores we run
For the stores we maintain, an event like this is exactly what the relationship is for. We track the security advisories so you do not have to, we put the recommended mitigations in place, and we apply the vendor patch the moment it is out and validated, tested on staging first so a rushed fix does not take down your checkout. A fast, prioritized response when something is genuinely critical is the whole point of maintenance, and it is worth the most in a week like this one. We laid out that cadence in the maintenance guide.
If you run a Magento store and you are not sure whether you are exposed, whether you have already been hit, or who is going to apply the patch when it drops, that is a conversation to have today, not next week. Book a free strategy call and we will check where you stand and what to do next.