StyleSmuggler: Magento Zero-Day RCE Under Attack

Another Magento emergency has arrived before most merchants could patch. Dutch e-commerce security firm Sansec disclosed StyleSmuggler, an unauthenticated remote code execution zero-day in Magento Open Source and Adobe Commerce, and warned that attackers were already using it to plant backdoors on live stores. The flaw, now tracked as CVE-2026-75650, carries the maximum CVSS score of 10.0. Adobe responded with an out-of-band emergency hotfix on September 7, 2026 — three days after the first attacks were seen in the wild.

The sequence is by now grimly familiar for the platform that powers a large share of the world’s online storefronts: a critical, pre-authentication bug; automated exploitation within hours; and a scramble to patch a codebase that sits directly in the path of customer payments. What makes StyleSmuggler stand out is the timeline. Unlike most Magento incidents, exploitation did not follow the patch — it preceded it.

What StyleSmuggler is

CVE-2026-75650 is a template-engine injection flaw, classified under CWE-1336 (improper neutralization of special elements used in a template engine). According to Sansec, the vulnerability lets an attacker smuggle malicious code through Magento’s templating system by abusing its styles properties — the mechanism the name plays on. Because the payload rides in through a channel the platform treats as benign layout data, it slips past existing input safeguards that were built to catch more obvious injection attempts.

Sansec describes the attack as a two-stage operation. First, the attacker poisons the system with PHP code — for example, by triggering a failure report that stores the attacker-controlled content. Then Magento is coaxed into executing that poisoned code through a routine server-side action, such as the rendering of a failed-payment email. The result is a classic object-injection gadget chain: untrusted input reaches a code path that ultimately performs an include, and the attacker’s code runs with the privileges of the web application.

Crucially, exploitation requires no authentication and no user interaction. An attacker needs only network access to a vulnerable storefront — the exact profile that pushes a vulnerability to a perfect 10.0 and, historically, the profile that Magento’s automated attack tooling is built to weaponize at internet scale. For background on why an unpatched, remotely exploitable flaw like this is treated as a five-alarm event, see our explainer on what a zero-day vulnerability is.

The backdoor

Successful exploitation does not stop at a single command. Sansec and independent responders report that StyleSmuggler is being used to install a persistent backdoor — a Rust-based Linux process that disguises itself as an innocuous system task. Observed samples masquerade as kworker/u:8:0 or fc-cache, running out of the font-cache directory at ~/.cache/fontconfig/fc-cache, where a stray binary is easy to overlook among legitimate housekeeping processes.

That choice of disguise matters. A kernel-worker impersonation and a fontconfig path are the kind of details that survive a casual look at a process list, which means a compromised store can keep serving customers while an attacker retains a foothold. On an e-commerce server, that foothold is the launch point for the most lucrative post-exploitation activity: injecting payment-skimming JavaScript into checkout, harvesting customer and order data, and pivoting into back-office systems.

Disrex Group, a Magento hosting provider, corroborated the in-the-wild activity, reporting exploitation across at least two stores it manages. In one detail that removes any doubt about whether this is a true zero-day, Disrex said an affected store was fully up to date on patches at the time it was breached — there was no available fix to miss. Both stores it observed were compromised within an eight-hour window between the first attacks and the availability of any defensive measure.

Every supported version is affected

The exposure is broad. StyleSmuggler affects Magento Open Source and Adobe Commerce from 2.4.4 through 2.4.9 — that is, effectively the entire supported install base, including the latest 2.4.9 release. There is no “recent enough” version that was safe before the hotfix; being current on Adobe’s regular Patch Tuesday cadence offered no protection.

That universality is what turned a single researcher’s finding into an industry-wide emergency. Magento’s install base skews heavily toward small and mid-size merchants, a population that patches slowly and often runs stores with minimal security staffing. When a flaw touches every version at once and requires no credentials, the gap between “someone has an exploit” and “thousands of stores are scanned” collapses to a matter of hours.

The disclosure timeline

The order of events is the story:

• September 4, 2026 — Sansec observes the first active exploitation against live stores.
• September 5, 2026 — Sansec publishes an early advisory, breaking from the usual practice of waiting for a vendor fix, precisely because stores were being compromised in real time and merchants needed to defend themselves immediately.
• September 7, 2026 — Adobe releases an out-of-band emergency hotfix for CVE-2026-75650, outside its normal monthly schedule.

Publishing ahead of a patch is a deliberate and contested call. Vendors and researchers generally coordinate so that a fix and the details land together, denying attackers a head start. Sansec’s decision to go early reflects a judgment that the details were already in attackers’ hands — the exploitation was live — and that silence would only leave defenders blind. It is the same logic that governs any active-exploitation event: once the secret is out, disclosure shifts from a risk to a defense.

The fix, and what to do now

Adobe’s hotfix ships as a composer patch (referenced by Adobe as VULN-39341) that merchants apply to their installations. According to analysis of the fix, it closes the object-injection path in two places: it stops Magento from instantiating an attacker-named class before the type is checked — in the BlockFactory and in the grid-row UrlGeneratorFactory — and it rejects non-string template styles, so the malicious gadget never reaches an include. In other words, it severs both the smuggling channel and the execution step.

Given confirmed in-the-wild abuse and a backdoor payload, merchants should treat this as a same-day emergency rather than a maintenance-window item:

• Apply Adobe’s hotfix immediately and verify the running build actually reflects the patched code, rather than assuming a deploy succeeded.
• Front the storefront with a web application firewall capable of blocking the exploitation pattern as an interim shield while patches roll out across staging and production.
• Hunt for the backdoor. Look for suspicious processes named kworker/u:8:0 or fc-cache, and inspect the ~/.cache/fontconfig/fc-cache path for an unexpected binary. Community responders have published compromise scanners specifically for this indicator.
• Assume patched is not the same as clean. Because stores that were current still got hit, applying the fix stops future exploitation but does not evict an attacker who is already inside. Review logs, rotate credentials and secrets, and check checkout pages for injected skimmer code.

A pattern, not an anomaly

StyleSmuggler lands in a long lineage of severe, widely exploited Magento vulnerabilities — from CosmicSting and last year’s SessionReaper to the recent Adobe Commerce account-takeover flaw, CVE-2026-71362, which drew exploitation attempts within days of its fix. It also fits this year’s broader wave of maximum-severity bugs in business-critical software, alongside events like the Metabase CVSS 10 zero-day and the Adobe ColdFusion remote code execution flaw. The common thread is software that must stay reachable on the public internet by design, running complex, long-lived codebases where a single trust gap becomes a skeleton key.

What it means

An unauthenticated, CVSS 10 RCE in every supported version of Magento and Adobe Commerce — exploited in the wild before a patch existed, and used to install a stealthy persistent backdoor — is one of the most dangerous configurations a defender can face.

Why the timeline matters. The defining feature here is that attacks came first. Merchants who rely on being “fully patched” as a safety net had none, because for three days there was nothing to apply. That inverts the usual mitigation advice and means every affected store must assume it was potentially reachable during the exposure window, not just going forward.

Who is exposed. Any store on Magento Open Source or Adobe Commerce between 2.4.4 and 2.4.9 that was internet-facing before September 7 sits in the immediate risk pool — a population that spans the platform’s entire supported base and skews toward smaller merchants that patch slowly. Because the payoff is checkout skimming and customer data, a successful compromise threatens shoppers’ payment details and the merchant’s regulatory and reputational standing at once.

What to watch. First, how quickly a public proof-of-concept circulates; its appearance historically triggers a sharp spike in opportunistic scanning against laggards. Second, whether the backdoor’s operators shift from establishing footholds to monetizing them through large-scale skimming campaigns — the usual trajectory once a Magento flaw is understood. Third, patch uptake across the long tail of stores, which is notoriously slow. The hotfix is available, but with a confirmed backdoor already in play, applying it is the start of the response, not the end of it: the stores breached during the pre-patch window will not fix themselves.