A zero-day vulnerability nicknamed StyleSmuggler is hitting Magento Open Source and Adobe Commerce stores right now, and there is still no official patch. Dutch security firm Sansec disclosed the flaw on September 5, tracing the first confirmed exploitation back to September 4 at 22:20 UTC. It affects every current release, including 2.4.9, and needs no authentication at all, an attacker only has to reach your storefront. Adobe has not assigned a CVE or shipped a fix as of this writing. Its next scheduled security bulletin lands September 8, and it is not yet known whether that release covers this bug.
Update – September 9, 2026
Adobe shipped a fix. The company published security bulletin APSB26-146 on September 7 at 20:20 UTC, assigning the flaw CVE-2026-75650 with a maximum CVSS score of 10.0 and shipping hotfix VULN-39341 for Adobe Commerce, Adobe Commerce B2B, and Magento Open Source across versions 2.4.4 through 2.4.9 (B2B 1.3.3 through 1.5.3). Store operators should apply the hotfix through the standard composer patch process right away, then go further than a normal patch cycle calls for: Sansec’s updated writeup and Adobe’s own bulletin both say to rotate the store’s encryption key and every credential that key protected, admin passwords, REST/SOAP/GraphQL integration tokens, OAuth secrets, payment gateway API keys, database credentials, and SSH or deploy keys included. Rotating the key alone does not invalidate anything an attacker already read while the bug was open. If your store was reachable on September 4 or later before you patched, treat it as compromised until you have checked for the indicators of compromise below and rotated credentials accordingly.
How the attack actually works
StyleSmuggler is a two-stage attack, and it does not rely on a single obvious injection point. First, an attacker plants poisoned PHP code somewhere Magento generates content on its own, such as a failure report. Then they trigger Magento’s “Payment Transaction Failed Reminder” email. The malicious code runs while Magento renders that email template, whether or not the email actually gets delivered.
According to Sansec’s writeup, the technique abuses the styles properties inside Magento’s template system to slip past existing protections. Once code execution succeeds, the researchers observed attackers dropping a small Rust-based backdoor that phones home to a remote server, sets up a cron job to relaunch itself twice an hour, and in one variant disguises its command-and-control traffic as NTP packets on port 123 to blend in with normal network noise.
What makes this one worse than the usual unauthenticated RCE report is that patch level did not matter. Sansec’s first confirmed victim was running Magento 2.4.6-p15 with July and August’s security updates fully applied, and it got compromised anyway.
What to do if you run Magento or Adobe Commerce
Every current version is exposed until Adobe ships something, so treat this as active until you have verified otherwise:
- Temporarily disable GraphQL on the storefront if your setup can tolerate it, since that is the entry point Sansec’s mitigation targets.
- Check for indicators of compromise: processes masquerading as
[kworker/u:8:0]orfc-cache, and a cron entry scheduled at13,43 * * * *. - Run a malware scan built for Magento (Sansec’s eComscan is one option) rather than a generic scanner, since the backdoor is built to look like normal system processes.
- Consider one of the unofficial community patches from Disrex, ProxiBlue, or Graycore if you cannot wait for Adobe, and review them before deploying to production.
- If you find any sign of compromise, rotate admin and API credentials. A backdoor that survived a fully patched instance is not one you want to assume is fully cleaned out.
Watch Adobe’s security bulletin page for the September 8 release and confirm it actually references this flaw before you stand down.
Why this matters past the Magento world
Most of what we cover in this space is WordPress and WooCommerce, but StyleSmuggler is a reminder that “fully patched” is not the same as “safe” on any ecommerce platform, and that a security review needs to look at what a platform executes automatically, not just what a user can reach directly. If your team is not sure whether your store’s monitoring would even catch a backdoor disguised as a font-cache process, that is worth fixing before the next one of these shows up. It is the kind of gap an Ecommerce Development audit is built to catch, especially for ecommerce businesses running store platforms they did not build in-house and cannot easily verify component by component.
This is also the second unauthenticated, actively exploited zero-day we have covered in a week, following Google’s Chrome V8 zero-day. Neither had a patch available at the time attackers started using it, which is worth keeping in mind the next time someone tells you patching on a schedule is enough.
