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.
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.
