Magento Zero-Day 'StyleSmuggler' Breached Fully Patched Stores

For three days last week, thousands of online stores running on Magento and Adobe Commerce were quietly getting backdoored by hackers — and there was nothing most store owners could have done about it, even the ones who had installed every security patch Adobe had ever shipped.

A break-in that skips the login screen

The bug has been nicknamed StyleSmuggler and tracked officially as CVE-2026-75650. It's what security researchers call a zero-day: a flaw that attackers found and started exploiting before the software maker even knew it existed, let alone had a fix ready. This one carries the maximum possible severity score, a 10 out of 10, because it lets an attacker run their own code on a store's server without logging in, without tricking an admin into clicking anything, and without any prior access at all. Researchers who tracked the attacks say exploitation began around September 4, a full three days before Adobe had a hotfix ready.

What made it worse is that it hit stores running every supported version of Magento Open Source and Adobe Commerce, from 2.4.4 up through the latest release — including shops that were fully up to date on every previous patch. Being current on updates is normally the single best defence against this kind of attack. Here, it did nothing.

How the attack actually works

Magento's template engine, the part of the software that decides how emails and pages look, lets developers set style properties on different elements. StyleSmuggler abuses that mechanism: an attacker slips malicious PHP code into those style fields, and the store executes it the moment it tries to render a routine failed-payment email. No customer needs to click a link, and no admin needs to approve anything — the store does the damage to itself automatically. Once inside, attackers have been installing a lightweight backdoor and a web shell, essentially a hidden control panel that lets them come back later, read customer data, or plant more malware, even after the original hole is patched.

Patching the hole stops new break-ins. It does nothing to clean up a store that was already broken into before the patch existed — and this one had a three-day head start.

What store operators need to do right now

Adobe shipped a hotfix, VULN-39341, on September 7. But security researchers are stressing that applying it is only step one. Because attackers had unauthenticated code execution, anything the server could read is potentially compromised. Recommended cleanup steps include:

• Apply Adobe's composer patch immediately, even on stores that appear unaffected
• Scan server files for unfamiliar PHP web shells or newly created admin accounts, since the window of exposure predates the fix
• Rotate the store's encryption key and every credential it protects — admin passwords, payment gateway API keys, database logins, SSH keys, and third-party extension tokens
• Treat any store that was live between September 4 and 7 as potentially breached until proven otherwise

Why this should worry Indian online sellers specifically

Magento has long been one of the default choices for mid-sized Indian D2C brands and marketplaces that have outgrown Shopify but aren't ready to build custom infrastructure — it's cheap to host, has a large freelance developer pool in India, and doesn't lock merchants into a single platform's fees. That popularity is exactly the problem here: a huge number of Indian storefronts sit on the affected version range, often run by small teams without a dedicated security engineer to catch an unauthenticated, zero-click exploit like this one. If customer data, including payment details or personal information, was exposed during the attack window, that's also a reportable incident under India's DPDP Act and CERT-In's breach-notification rules, which require flagging significant incidents within six hours of detection. Store owners who haven't checked their logs yet are already behind on that clock.

This isn't the first time a widely used piece of web infrastructure has turned into a single point of failure for thousands of unrelated businesses at once — Chrome's own sixth zero-day of the year, covered here recently, followed a similar pattern of active exploitation racing ahead of a patch. The lesson keeps repeating: being "up to date" is necessary but no longer sufficient. The real gap now is the time between when an attacker finds a hole and when a vendor can plug it — and in that gap, patch status tells you nothing about whether you've already been hit.