E-commerce platforms **Magento** Open Source and **Adobe Commerce** are currently facing an active zero-day exploitation of a newly discovered vulnerability, named **StyleSmuggler**. The flaw enables unauthenticated attackers to achieve remote code execution (RCE) on affected online stores, leading to the installation of persistent backdoors. **Sansec**, a Dutch e-commerce security firm, identified the vulnerability and began observing attacks on September 4th. The company issued an early advisory on September 5th, emphasizing the urgency due to ongoing compromises. As of September 6th, **Adobe** has not released an official advisory, a **CVE** identifier, a patch, or a workaround.  ## Impact and Affected Versions A successful **StyleSmuggler** attack grants the adversary code execution privileges on the store's server, followed by the installation of a persistent backdoor. **Sansec** confirms that all current versions of **Magento** Open Source are affected, including 2.4.9. They successfully reproduced the full unauthenticated exploit chain on clean installations of **Magento** Open Source versions 2.4.7, 2.4.8, and 2.4.9. One observed victim was running version 2.4.6-p15, which included **Adobe**'s latest security updates for that release line, highlighting that even recently patched systems are vulnerable. While **Sansec** has not publicly reproduced the exploit on **Adobe Commerce** or **Adobe Commerce on Cloud**, the vulnerability's nature suggests a broader impact. ## Independent Confirmation and Mitigation **Disrex Group**, a **Magento** hosting and development company, independently confirmed the active exploitation. They reported handling two compromised stores and a third that was attacked but not breached. Both compromised stores were running **Magento** Open Source (versions 2.4.8 and 2.4.7-p2) under **Disrex Group**'s hosting brand, **RexHosting**. For stores not utilizing **Sansec**'s **Shield** product, the interim advice is to temporarily disable **GraphQL** until **Adobe** releases a fix. **Disrex Group** notes that while headless and progressive web app storefronts typically require **GraphQL**, most classic and **Hyvä** storefronts do not. ## The Attack Chain **Sansec**'s preliminary outline describes a two-stage attack. Initially, malicious PHP code is injected into a file that **Magento** itself writes, such as a failure report. Subsequently, **Magento** is triggered to execute this file by initiating a standard "Payment Transaction Failed Reminder" email. The code runs during the message rendering process, meaning no user interaction (like opening the email) is required for the exploit to succeed, even if email delivery fails. **Disrex Group**'s independent analysis of the chain suggests that a directive within the injected text manipulates **Magento**'s internal classes to execute code intended for the command-line dependency-injection compiler. This process ultimately includes a file path chosen by the attacker, leading to the execution of a previously poisoned log file. The PHP dropper then attempts various functions to start a process, download, and launch the implant. ## The Implant and Persistence **Sansec** identifies the implant as a background process disguised as `[kworker/u:8:0]`, a Linux kernel thread, with a binary located at `~/.local/share/.gvfsd/gvfsd-user` outside the web root. A cron entry ensures its restart every five minutes. **Disrex Group** further described the binary as a stripped, statically linked Rust program (approx. 1.9 MB) built for x86-64 and arm64 architectures. The cron entry is written directly to the spool file under `/var/spool/cron/crontabs/`, bypassing system logs that would typically record crontab modifications. In one instance, the cron entry was found to be duplicated 1,728 times, with the implant re-adding it instantly upon removal.  Despite the sophisticated persistence mechanism, **Disrex Group** reported no outbound connections from the implant on one compromised store. Instead, it maintained 28 connections to the store's Redis instance, reading **Magento**'s session storage. Initial investigations by **Disrex Group** found no evidence of data exfiltration, rogue admin accounts, injected payment skimmers, or database backdoors. However, all sessions were invalidated, and credential rotation is underway as a precautionary measure. ## Urgent Action Required Both **Sansec** and **Disrex Group** emphasize that patch status was irrelevant for the initial compromise, as attacks occurred before any defense mechanisms were in place. **Adobe**'s next scheduled security release is on September 8th, and it remains to be seen if this critical vulnerability will be addressed. Given the active exploitation and the severity of the unauthenticated RCE, IT security professionals managing **Magento** and **Adobe Commerce** installations are urged to implement the recommended mitigation of disabling **GraphQL** where possible and to monitor for any official advisories and patches from **Adobe**.