Attackers used a previously unknown Magento flaw to compromise fully patched online stores before any specific blocking rule existed. The unauthenticated chain, named StyleSmuggler by Sansec, makes Magento execute poisoned data while rendering a failed-payment email. It then launches a native Linux implant that persists outside the shop’s document root.
Sansec first confirmed exploitation at 22:20 UTC on September 4. One store managed by Disrex was compromised 50 minutes later. Sansec’s first StyleSmuggler rules went live at 07:15 UTC on September 5, leaving roughly eight hours in which the new attack had no purpose-built public defense. “Sansec is publishing early because stores are being compromised right now,” the company wrote.
Sansec reproduced the full chain on clean Magento Open Source 2.4.7, 2.4.8, and 2.4.9 installations. Its first victim ran 2.4.6-p15 with Adobe’s July and August 2026 patches applied. Adobe had not published an advisory, CVE, official fix, or workaround when the primary records were captured. Sansec said Adobe’s next scheduled security release was September 8, but whether it would address StyleSmuggler remained unknown.
Eight hours before defenses
Disrex, a Magento hoster and developer, independently investigated two compromised Magento Open Source stores and a third store that was attacked without being breached. Both compromises occurred before Sansec’s rules were available. One affected store was a Sansec Shield customer; the attack arrived before StyleSmuggler coverage went live.
Sansec sells Shield and eComscan and recommends both in its own advisory. That commercial interest matters when reading its product claims. Disrex supplied independent incident evidence, but its emergency material also carries firm limits: AI assisted its creation during a live incident, its Apache rules were never exercised on a live Apache server, most cleanup commands were written rather than executed, and its sink guard was tested in a harness.
The published scope remains bounded. Sansec has not said how many stores were compromised. It has not published a reproduction on Adobe Commerce or Adobe Commerce on Cloud, and Adobe has not confirmed affected versions. Disrex’s two compromised stores ran Magento Open Source. Its isolated accounts gave the implant no path to other customers, and the company found no lateral movement, data exfiltration, rogue administrator, payment skimmer, or database backdoor before containment.
Sansec likewise said it had no indication that the backdoor was used on Shield customers attacked before its rules launched. Those facts narrow the observed damage. They do not erase the code-execution and persistence established on the affected hosts.
Magento executes poisoned logs
StyleSmuggler uses two requests. The first makes Magento write attacker-supplied PHP into an application-controlled file, such as a failure report or var/log/system.log. The second steers the platform’s template processor through internal objects until dependency-injection compiler code includes that chosen file. PHP then parses the poisoned log or report as executable code.
The trigger is Magento’s standard “Payment Transaction Failed Reminder” message. No recipient has to open it: the PHP runs while Magento renders the email, and exploitation can succeed even when delivery fails. An unexpected burst of these messages is useful recognition evidence, although legitimate declined payments generate the same notification.
Disrex traced the known sink to three scanner classes under setup/src/Magento/Setup/Module/Di/Code/. Those classes support command-line dependency-injection compilation and have no ordinary role in a web request. Sansec has confirmed the broader poison-and-render sequence but has not confirmed Disrex’s specific source-code reading, and neither organization published an assembled exploit request.
Figure details
An attacker first sends input that Magento writes as PHP into var/log/system.log or a report under var/report. A second request invokes Magento's template and dependency-injection path during failed-payment email rendering. That path includes the poisoned file, causing PHP to execute it. The dropper starts a native Linux implant outside the webroot. The implant runs under the site user as [kworker/u:8:0] and adds a cron entry that restarts it every five minutes.
The observed dropper tried shell_exec, exec, system, passthru, proc_open, and popen in sequence to launch a process. The implant then disguised itself as [kworker/u:8:0], moved to ~/.local/share/.gvfsd/gvfsd-user, and installed the cron entry */5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-user. Disrex found that the process could restore the cron line within a second of removal.
Hunt beyond the webroot
A clean Magento directory cannot clear this incident. The native implant sits above the document root, and a running copy can differ from the file left on disk. Disrex advises preserving and hashing /proc/<pid>/exe as well as the filesystem copy. A genuine bracketed kernel thread runs as root and has no normal resident memory; the reported implant uses a bracketed name under the unprivileged site user and consumes memory.
Start with the primary sources’ read-only checks, adapted to the store’s account and paths:
ps -eo pid,user,rss,args --no-headers | awk '$4 ~ /^\[/ && $2 != "root"'
crontab -l 2>/dev/null | grep -i 'gvfsd\|\.kw_'
ls -la ~/.local/share/.gvfsd/ /tmp/.kw_* /tmp/.gvfsd-* 2>/dev/null
grep -rl 'X_TRACE_\|<?php' var/report/ var/log/ 2>/dev/null
grep -acE 'styles(\[|%5B)|generatorClass|with_resolved|cdnflare' /path/to/access.logSearch both var/report/ and var/log/. Sansec first published the X_TRACE_ marker in report files, while Disrex’s infections poisoned var/log/system.log. Disrex also saw the request header drift from X-TRACE- plus ten hexadecimal characters to the same shape without TRACE. A TypeError from array_merge() immediately after the include can mean the poisoned file already executed; a quieter variant can return an empty array and leave no such error.
Sansec and Disrex published these network values in defensive context: 247[.]cdnflare[.]xyz, 99[.]84[.]67[.]186:443, windwsecurity[.]run:443, ntp[.]timesysnc[.]net:123, time[.]microsft[.]run:123, pool[.]microsft[.]studio:123, 88[.]216[.]72[.]181, 5[.]181[.]86[.]133, and 91[.]238[.]181[.]19. In one Disrex infection, the implant made no suspicious outbound connection and instead held 28 connections to the store’s own Redis service on port 6379. A network-only hunt can therefore miss an active process.
The known filesystem patterns are ~/.local/share/.gvfsd/.gvfsd_<8hex>.lock, /tmp/.gvfsd_<8hex>.lock, and /tmp/.kw_<random><random>. Published SHA-256 values are:
e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7b79dfdc1eed860e0b76c629d6adfce251db379b0b45a6d728d4ef483f75514208334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06ef251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220
The last value came from a running process whose build differed from the file on disk. Hashes, paths, and infrastructure can change, so retain process ownership, resident memory, cron behavior, Magento logs, access logs, and failed-payment email evidence alongside the published values.
Contain before temporary mitigation
Preserve process state, open files, network connections, logs, cron entries, and the running binary before cleanup. Remove the persistence mechanism before stopping the process; otherwise the five-minute job can immediately restart it. Scope every credential available to the Magento filesystem user, including database, administrator, encryption, and integration secrets, and inspect administrator accounts, API integrations, SSH keys, shell profiles, systemd timers, PHP configuration, Magento code, CMS content, and database configuration for secondary access.
Sansec recommends temporarily disabling GraphQL for stores that can operate without it. Headless and progressive web applications generally depend on GraphQL, so that option can interrupt the storefront. Disrex’s defensive repository provides query-string rules and an unofficial source patch that makes the three scanner methods CLI-only. Its own live-store measurement found that moving the same parameters into a POST body bypassed the URL-query rules. The sink-level guard is intended to hold regardless of request placement, but its limited test record requires staging and environment-specific validation.
Neither temporary control cleans an infected host. After removing known persistence and processes, wait longer than one five-minute cron cycle. Repeat the non-root bracketed-process check, inspect the crontab and known paths again, and confirm that the relevant Magento log and access-log signals have stopped. The expected result is no suspicious site-user process, no recreated cron line or dropped file, and no new exploit-shaped request reaching PHP. If any element returns, containment has failed and the host still requires incident response or rebuild.
StyleSmuggler proves that current patch status and host trust answer different questions. Until Adobe publishes and operators validate an official correction, exposure is defined by reachable Magento behavior and retained host evidence. A version string alone cannot answer whether the implant ran during those first unprotected hours.