
Loading

Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A maximum-severity, unauthenticated zero-day that turns Magento's own template engine into remote code execution, exploited for three days before Adobe's hotfix shipped.
A critical, unauthenticated remote code execution vulnerability in Adobe Commerce, Adobe Commerce B2B, and Magento Open Source, every version from 2.4.4 through 2.4.9, was actively exploited starting September 4, 2026, three full days before Adobe shipped a fix. E-commerce security firm Sansec, who first identified it, named it StyleSmuggler, and it's a genuinely clever piece of abuse: it turns Magento's own template engine, the thing that renders every email and page on the storefront, into an unauthenticated code-execution primitive.
CVE-2026-75650 carries the maximum possible CVSSv3 score of 10.0, and the attack chain runs in two stages, as detailed by NetSPI's technical writeup. First, an attacker plants ("poisons") malicious PHP code somewhere Magento will later process it, reportedly by abusing the platform's style-handling properties to slip past existing input safeguards. Second, that poisoned code gets executed when Magento renders a routine "Payment Transaction Failed Reminder" email, a template that fires automatically, with no attacker interaction needed after the initial injection, and no authentication required for either stage.
Once code executes, it executes with the store's own server privileges. Tenable's FAQ on the vulnerability and other researchers observed real compromised stores with a Rust-based Linux backdoor and PHP web shells dropped post-exploitation, this wasn't a theoretical proof of concept, it was a live campaign against real storefronts.
Adobe released Hotfix VULN-39341 on September 7, 2026. If your store runs any affected version and hasn't applied it yet, that's the immediate action. But because active exploitation began before the patch existed, applying the hotfix stops new intrusions, it doesn't undo one that already happened. Any store that was internet-reachable on an affected version between September 4 and 7 should be treated as a potential compromise until someone actually checks: unfamiliar admin accounts, unexpected scheduled tasks, and web shells dropped in writable directories are exactly what a proper post-incident review looks for.
The pattern here is broader than Magento. A templating or rendering engine that's trusted to process dynamic content, email templates, PDF generators, report builders, is often assumed safe because "it's just formatting," when in practice it's executing logic against attacker-influenced input. That's precisely the kind of business-logic flaw automated scanners are structurally bad at catching (see our piece on what automated scanners miss) and that a proper Secure Code Review is built to find before it becomes a live incident. For e-commerce platforms specifically, this sits alongside the same class of risk we cover for Shopify-hosted stores and WordPress/WooCommerce deployments, different platforms, the same underlying lesson that a storefront's plugin and template layer is where the real exposure usually lives.
If you run Adobe Commerce or Magento and want a second opinion on whether your instance shows any signs of the exploitation pattern researchers observed, that's exactly the kind of scoped review our Penetration Testing service covers.
Tell us about your environment and goals, we'll help you scope the right engagement.