Attackers are actively exploiting an unpatched Magento zero-day that affects both Magento Open Source and Adobe Commerce, giving them unauthenticated remote code execution on online store servers. The vulnerability, dubbed StyleSmuggler, was discovered by Dutch e-commerce security firm Sansec, which said the first attacks began on September 4 and that stores were already being compromised when its advisory went public the following day. As of September 6, Adobe had not published an advisory, assigned a CVE identifier, released a patch, or offered a workaround.
The Magento Zero-Day StyleSmuggler Puts Fully Patched Stores at Risk
Sansec’s September 5 advisory warned that the attack is not theoretical. The company reproduced the full unauthenticated chain on clean Magento Open Source installations of versions 2.4.7, 2.4.8, and 2.4.9, and said every current version, including 2.4.9, is vulnerable. More striking than version coverage, however, was the first confirmed victim: a store running Magento 2.4.6-p15 with Adobe’s July and August 2026 security updates applied. That is the latest patch level Adobe offers for the 2.4.6 release line, a build Adobe’s August bulletin labels 2.4.6-2026-aug.
The same point emerged from incident response work by Disrex Group, a Magento hosting and development company that handled two compromised stores. One of those stores was running Magento Open Source 2.4.8 and was a Sansec Shield customer with the module installed, enabled, and licensed. It was hit at 23:10 UTC on September 4, hours before Sansec’s first blocking rules for StyleSmuggler went live. The other store was not a Shield customer and ran Magento 2.4.7-p2, a security patch level that Adobe’s version history dates to August 2024, eight levels behind the current 2.4.7-p10. That store was first hit at 00:55 UTC on September 5. Both stores were breached inside the roughly eight-hour window between the first exploitation Sansec observed and the moment any dedicated defense existed.
“Patch status was irrelevant here, which is the part merchants most need to hear,” Disrex said in response to questions about the incidents.
What Is the StyleSmuggler Magento Zero-Day?
StyleSmuggler is an unauthenticated remote code execution vulnerability in Magento Open Source and Adobe Commerce that allows an attacker to execute malicious code on a store’s server without logging in. Sansec named the flaw and published early because active compromises were underway. The vulnerability is unpatched, affects all current Magento versions, and can install a persistent backdoor even on fully updated installations.
Two Compromised Stores, One Clear Pattern
Disrex’s findings are independent evidence of exploitation outside Sansec’s telemetry. The company published an incident-response repository on September 5, stating that it handled two compromised stores and a third that was attacked but not breached. Its web-server rules are based on attack traffic captured on one of the compromised stores. Disrex said both compromised stores ran Magento Open Source rather than Adobe Commerce, and that it hosts them through its hosting brand RexHosting.
Store A, the Sansec Shield customer, was running Magento Open Source 2.4.8. At the time it was hit, Shield was active and blocking other malicious traffic against the store. Store B, which was not a Shield customer, ran Magento 2.4.7-p2. Disrex said its reading of the vulnerable code and its web-server rules were taken from Store B.
Both stores were contained the same day, roughly eleven and fourteen hours after first contact. Disrex found no evidence of data exfiltration, no rogue admin accounts, no injected payment skimmer, and no database backdoor. All sessions were invalidated, and credential rotation was underway as a precaution. Because Disrex runs a number of Magento stores on its own platform and found the first compromise quickly, it swept its entire estate within the hour and found the second store the same afternoon. It also published a separate incident write-up.
Neither store had a path to any other customer. Disrex said each store ran in its own isolated account with a single site owner, no sudo rights, and no route to neighboring accounts. The implant ran as the unprivileged site user and could reach nothing beyond that store. The company confirmed it found no lateral movement and no other affected site on its platform.
How the StyleSmuggler Attack Chain Works
Sansec’s outline describes a two-stage attack. The first stage plants PHP code in a file that Magento itself writes, for example when the platform generates a failure report. The second stage forces Magento to execute that file by triggering the standard “Payment Transaction Failed Reminder” email. The code runs while Magento renders the message, so no one has to open the email, and the attack can succeed even if email delivery fails.
Disrex’s independent reading of the chain, published alongside its mitigation rules, goes further. A directive within the injected text drives a sequence of Magento’s own classes into code that exists solely to serve the command-line dependency-injection compiler. That code ends by including a file path the attacker chose: the log that was poisoned a moment earlier. The executed PHP dropper attempts six PHP functions in turn to start a process, then downloads and launches the implant. Disrex names three files under setup/src/Magento/Setup/Module/Di/Code/ as the point where the chain ends, and says it identified that sink by reading Magento source on the compromised store. Sansec has not confirmed that reading, and Disrex does not publish the assembled request.
How Does the StyleSmuggler Attack Execute Code?
The attack works by using Magento’s own email notification system to execute a poisoned log file. First, the attacker plants PHP code in a file Magento writes, such as a failure report or a system log. Then the attacker triggers a “Payment Transaction Failed Reminder” email, and the malicious code runs while Magento renders the message. No authenticated session and no human click are required.
Two file locations matter for detection. Sansec’s published check searches var/report/ for the marker X_TRACE_. Disrex said both of its infections were poisoned through var/log/system.log instead, and would have been missed by that check. Both directories need to be searched. The marker has already drifted: Disrex saw a trigger header of the form X-TRACE- followed by ten hex characters on the morning of September 5, and the same header without the word TRACE by the afternoon. A robust search should match the shape rather than an exact string.
Disrex also described a log-based signal of a successful exploit: a TypeError from array_merge() with an integer argument in system.log, appearing immediately after the include. However, a stealthier variant returns an empty array and leaves nothing in the log.
Implant Behavior and Indicators of Compromise
The persistent backdoor left by StyleSmuggler is designed to evade casual inspection. Sansec’s indicators describe a background process disguised as [kworker/u:8:0], a name that belongs to a Linux kernel thread. The binary is installed at ~/.local/share/.gvfsd/gvfsd-user under the site user’s home directory rather than the web root, and a cron entry restarts it every five minutes.
Disrex described the binary as a stripped, statically linked Rust program of roughly 1.9 MB built for x86-64 and arm64. It said the cron entry is written directly to the spool file under /var/spool/cron/crontabs/, so the system log shows no crontab replacement. One store carried the same cron line 1,728 times, and the implant re-added it within a second of removal.
On one of the two stores, the implant made no outbound connection at all. It held 28 connections to the store’s own Redis instance on port 6379 and read Magento’s session storage from it, Disrex said. Neither of its two packet captures, each over 200 MB and taken while the implant was live, contained a single packet to the download host or the command-and-control address that Sansec listed.
Disrex also found that the binary running in memory on one store was a different build from the file on disk, so it advises hashing the running process from /proc/<pid>/exe as well as the file on disk. A genuine kernel thread is owned by root and has no resident memory, so a bracketed name on the site user with real memory usage is the implant. Because the implant sets its command line to the literal bracketed string, a check written against the process’s comm field matches nothing.
Unexpected bursts of “Payment Transaction Failed Reminder” emails are another reason to investigate, Sansec said, although legitimate declined payments generate the same notification.
The following indicators have been published by Sansec and in Disrex’s indicator list:
- Process: [kworker/u:8:0] owned by a non-root user
- File: ~/.local/share/.gvfsd/gvfsd-user
- File: ~/.local/share/.gvfsd/.gvfsd_<8hex>.lock
- File: /tmp/.gvfsd_<8hex>.lock
- File: /tmp/.kw_<random>
- Cron: */5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-user, with a variant pointing at /tmp/.kw_
- SHA-256: e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7 (Sansec’s sample)
- SHA-256: 8334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06ef (on disk on both Disrex stores)
- SHA-256: 251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220 (running in memory on one Disrex store)
- Domain: 247.cdnflare[.]xyz (malware download host)
- IP: 99.84.67[.]186:443 (command-and-control over WebSocket and TLS, per Sansec)
- IP: 88.216.72[.]181 (attacker source, per Sansec)
- IP: 5.181.86[.]133 (attacker source sending in bulk, per Disrex)
Sansec recommends its eComscan scanner to detect the implant, and said version 1.9.7 will terminate the process for Shield customers. Disrex reported a clean result on Store A even though it was infected. eComscan ran there roughly eleven hours after the implant first appeared and while 1,728 cron lines were present, and reported the store clean. The cause was scope rather than a scanner fault: the scheduled scan was pointed at the store’s document root, and the implant had installed one directory above it, under the account’s home directory. Disrex has since widened the scan path.
Detection Gaps and an Incident-Response Warning
Disrex’s public repository carries its own caution. Its README says the material was written with AI assistance, during a live incident, in a few hours, and that it has not been fully reviewed. The Apache rules were never run against a live Apache server, and most of its cleanup commands were written rather than executed. That transparency matters because merchants will be under pressure to act quickly, and the unofficial nature of every currently available defense cannot be overstated.
No vendor fix exists. Sansec has not published the full exploit chain, saying a breakdown of the chain, the dropper, and the implant will follow in an update. Adobe has not confirmed which versions are affected, and Sansec has not published a reproduction on Adobe Commerce or Adobe Commerce on Cloud. Neither Sansec nor Adobe has confirmed Disrex’s reading that the chain ends in the dependency-injection code scanners.
What Merchants Should Do Before Adobe Ships a Fix
With Adobe’s next scheduled security release set for September 8, and no confirmation that it will cover this bug, merchants have to make interim decisions. Sansec’s advice for stores not running its Shield product is to temporarily disable GraphQL until Adobe releases a fix. Disrex notes that headless and progressive web app storefronts require GraphQL, whereas most classic and Hyvä storefronts do not.
Several unofficial mitigations are circulating. Disrex published nginx and Apache rules that block requests carrying the exploit’s parameters in the URL query string. Its own test on a live store showed the limit: the same parameters sent in a POST body reached PHP, as did a JSON body, because nginx and Apache inspect only the query string. Disrex describes the rules as stopping the campaign as it currently runs rather than fixing the vulnerability itself.
Disrex’s main mitigation adds a check to three methods in Magento’s dependency-injection code scanners, preventing them from running outside the command line. The hand edit is reverted by every composer install, so Disrex also distributes a composer-patches source patch that reapplies on deploy and, it says, applies unchanged from 2.4.6 through 2.4.9. One of the three files, ClassesScanner.php, is called over HTTP by at least one third-party module, mageplaza/module-admin-permissions, and guarding it breaks that module’s admin screen. Disrex tells administrators to search their vendor directory before touching that file. The guard was tested on a harness rather than inside a running store, and Disrex says it is not a complete fix on its own. A GitHub user, ProxiBlue, separately published the same guard on September 5 as three unofficial patches.
Graycore, LLC published a Magento module on GitHub and Packagist on September 5. Its current code, Graycore says, hardens three points on the chain: the email template block directive refuses backend blocks, the grid row URL generator checks a class before building it, and PHP opening tags in Web API fatal error reports are broken. The version on Packagist at the time of writing was an earlier release whose only mitigation targeted a PayPal GraphQL resolver that has since been removed. The README says “That is hardening, not a fix” and warns that other paths through the vulnerability remain open and that a store may already be compromised.
Two server settings do not depend on knowing the chain at all. At one of Disrex’s two stores, the first four of the six PHP functions the dropper tried were disabled, but proc_open was not, and the dropper used it to start the implant. open_basedir did nothing to contain the child process. Adding proc_open to PHP’s disable_functions, and mounting /tmp, /var/tmp, and /dev/shm with noexec so a downloaded binary cannot run, are the layers Disrex puts ahead of every rule in its repository.
Cleanup Steps for a Compromised Store
For a store that is already infected, Disrex’s cleanup guide sets a specific order. Preserve evidence first. Remove the cron entry before killing the process, because the process restores it. Do not reboot, because the copy under /proc may be the only remaining binary. Do not run composer install to clean up, because it overwrites the timestamps that show what was touched. The guide then recommends flushing session storage, since the implant read it, and rotating the crypt/key in app/etc/env.php, along with every admin password, every payment provider API key, and every other integration credential in that file.
Hosting providers Nexcess and Liquid Web posted identical incident notices on September 5, stating they were reviewing their server environments and implementing precautionary measures. Neither claims a confirmed customer compromise or its own reproduction of the flaw. Disrex, for its part, recorded 26 distinct source addresses across its two stores, taken from the stores’ own nginx access logs and deduplicated. Two were hosting infrastructure sending in bulk; the rest were a residential proxy pool sending two to six requests each. Blocking the single attacker address in Sansec’s advisory would have stopped less than a quarter of the traffic Disrex observed. An earlier count of 28 included two of Disrex’s own servers making verification requests during the response, which it removed. No source has named the attackers.
What the StyleSmuggler Outbreak Signals for E-Commerce Security
The most uncomfortable lesson of StyleSmuggler is that patch compliance, up-to-date versions, and even an active security module did not stop the initial compromise. Fully updated stores and an outdated store fell inside the same narrow exploitation window, and in the Disrex cases the attacker used the same unauthenticated mechanism regardless of version. That makes this Magento zero-day different from the typical Adobe Commerce vulnerability, where installing the latest security release is the first and most reliable defense. Here, the defense did not exist.
The second lesson is the speed and discipline of the response. Disrex contained both stores the same day, found the second by sweeping its entire platform, preserved evidence, and published detailed indicators and cleanup guidance. The lack of observed data exfiltration or lateral movement in those two cases is reassuring, but it is not proof that every attacked store will fare as well. The attackers behind StyleSmuggler were clearly prepared to hide their implant, avoid outbound connections by reading Redis session data locally, and rebuild their payload for multiple architectures.
Between Sansec’s active monitoring, Disrex’s independent incident response, and the unofficial patches now circulating, the e-commerce security community has assembled a usable picture of this attack unusually quickly. But none of that replaces Adobe’s fix. The September 8 security release is the next opportunity to close the gap, and merchants should treat that date as a deadline to implement interim hardening, review logs for the indicators listed above, and verify that their monitoring actually covers the directories where this implant lives. A scanner pointed only at the web root is not enough when the backdoor is one directory above it.
