StyleSmuggler: Inside the Unpatched Magento Zero-Day Backdooring Live Stores

Summary

An unpatched vulnerability in Magento Open Source and Adobe Commerce has been disclosed that allows an attacker to execute code on a store's server without authenticating. Sansec, a Dutch e-commerce security firm, published its advisory on September 5, 2026, stating that active exploitation began the previous day and that stores were being compromised as the research went public. As of September 7, Adobe had not issued a CVE, advisory, patch, or workaround for the flaw.

A successful attack grants server-side code execution and installs a persistent backdoor disguised as a Linux kernel process. Sansec reproduced the full unauthenticated exploit chain on clean Magento Open Source 2.4.7, 2.4.8, and 2.4.9 installs, and confirmed all current versions are affected.

Background

Sansec named the flaw StyleSmuggler , noting it was releasing details early because live compromises were underway. The company's first confirmed victim ran Magento 2.4.6-p15 with Adobe's July and August 2026 security updates applied, the latest patch level available for that release line, indicating that being fully up to date on published patches did not prevent compromise.

Disrex Group, which hosts Magento stores through its RexHosting brand, independently identified two breached stores and published a mechanism write-up and indicator list in a public incident-response repository on September 5. One of its stores, a Sansec Shield customer running 2.4.8, was hit hours before Sansec's first blocking rules existed. The second, running 2.4.7-p2, was hit the following morning. Both intrusions occurred inside the roughly eight-hour gap between first observed exploitation and the existence of any defense, which Disrex characterized as evidence that patch status was not the deciding factor. Hosting providers Nexcess and Liquid Web also issued precautionary notices on September 5, though neither confirmed a customer compromise or its own reproduction of the flaw.

Vulnerability Details

CVE ID	Severity	Affected Products
SVE-110169	Critical	Magento Open Source and Adobe Commerce, all current versions including 2.4.9

Attack Methodology

1. 1. Log Poisoning: The attacker plants PHP code inside a file Magento itself writes during normal operation, such as a failure report, using a trigger marker Sansec identifies as X_TRACE_ in var/report/. Disrex found both of its infections were poisoned through var/log/system.log instead, and observed the marker shift from X-TRACE- followed by ten hex characters to the same header without the word TRACE within a single day.
2. 2. Forced Execution via Email Template: The attacker triggers Magento's standard "Payment Transaction Failed Reminder" email. A directive inside the injected text drives a sequence of Magento's own classes, normally reserved for the command-line dependency-injection compiler, into including the attacker-chosen, already-poisoned log file. The code executes while Magento renders the message, so no one needs to open the email and delivery does not need to succeed.
3. 3. Dropper Execution: The included PHP code attempts six PHP process-start functions in sequence until one succeeds, then downloads and launches the implant. On one observed store, four of the six functions were disabled, but proc_open was not, and open_basedir did not restrict the resulting child process.
4. 4. Implant Deployment: A stripped, statically linked Rust binary of roughly 1.9 MB, built for x86-64 and arm64, is written to ~/.local/share/.gvfsd/gvfsd-user under the site user's home directory, outside the web root.
5. 5. Persistence Installation: A cron entry is written directly to the spool file under /var/spool/cron/crontabs/, restarting the implant every five minutes and bypassing crontab-replacement logging. On one store the entry appeared 1,728 times, with the implant re-adding it within a second of manual removal.
6. 6. Command and Control or Local Collection: The implant runs disguised as [kworker/u:8:0], a name normally belonging to a root-owned Linux kernel thread with no resident memory. Sansec observed outbound WebSocket and TLS connections to a command-and-control address; on one Disrex store, the implant made no outbound connections at all and instead held 28 connections to the store's own Redis instance on port 6379, reading Magento's session storage directly.

Indicators of Compromise (IOCs)

Domain and IPs:

• • 247.cdnflare[.]xyz
• • 99.84.67[.]186:443
• • 88.216.72[.]181
• • 5.181.86[.]133

Files:

• • ~/.local/share/.gvfsd/gvfsd-user
• • ~/.local/share/.gvfsd/.gvfsd_<8hex>.lock
• • /tmp/.gvfsd_<8hex>.lock
• • /tmp/.kw_

Process:

• • [kworker/u:8:0]  owned by a non-root user, with real resident memory usage

Cron:

• • */5 * * * * exec /.local/share/.gvfsd/gvfsd-user  (variant points to /tmp/.kw_)

MITRE ATT&CK Mapping

Technique ID	Technique Name	Tactic
T1190	Exploit Public-Facing Application	Initial Access
T1053.003	Scheduled Task/Job: Cron	Persistence
T1036.004	Masquerading: Masquerade Task or Service	Defense Evasion
T1071.001	Application Layer Protocol: Web Protocols	Command and Control
T1005	Data from Local System	Collection

Visual Attack Flow

Mitigation

1. 1. Disable GraphQL temporarily: Sansec's interim advice for stores not running its Shield product; note that headless and progressive web app storefronts require GraphQL, while most classic and Hyvä storefronts do not.
2. 2. Restrict process spawning: Add proc_open to PHP's disable_functions , since it was the function the dropper used successfully after four of six candidate functions were already disabled on one observed store.
3. 3. Mount temp directories noexec: Mount /tmp , /var/tmp , and /dev/shm with the noexec flag so a downloaded implant binary cannot execute, since open_basedir alone does not contain the child process.
4. 4. Apply the scanner guard patch: Deploy the community guard (from Disrex or ProxiBlue) adding a PHP_SAPI !== 'cli' check to three methods under setup/src/Magento/Setup/Module/Di/Code/ , applicable unchanged from 2.4.6 through 2.4.9; check the vendor directory first, since guarding ClassesScanner.php breaks the mageplaza/module-admin-permissions admin screen.
5. 5. Deploy web-server blocking rules: Apply Disrex's or Graycore's nginx/Apache rules blocking the exploit's parameters in the URL query string, noting these do not stop the same parameters sent via POST or JSON body.

Instantly Fix Risks with Saner Patch Management

Saner patch management is a continuous, automated, and integrated software that instantly fixes risks exploited in the wild. The software supports major operating systems like Windows, Linux, and macOS, as well as 550+ third-party applications.

It also allows you to set up a safe testing area to test patches before deploying them in a primary production environment. Saner patch management additionally supports a patch rollback feature in case of patch failure or a system malfunction.

Experience the fastest and most accurate patching software here .