Magento StyleSmuggler Zero-Day Exploited in Active Attacks, Stores Compromised Without Authentication
Magento Open Source and Adobe Commerce users are being targeted by an actively exploited zero-day vulnerability that can allow attackers to execute malicious code on an e-commerce server without authentication. The flaw, dubbed StyleSmuggler by Dutch e-commerce security company Sansec, was disclosed on September 5, 2026, after researchers observed live attacks against Magento stores.
Sansec said attacks began on September 4 and released details early because online stores were already being compromised.
As of September 6, Adobe had not published a security advisory, CVE identifier, official patch, or confirmed workaround for the vulnerability. Sansec reported that the vulnerability affects current Magento versions, including Magento 2.4.9, and successfully reproduced the attack against clean Magento Open Source installations running versions 2.4.7, 2.4.8, and 2.4.9.
What Is the Magento StyleSmuggler Vulnerability?
The StyleSmuggler attack is an unauthenticated remote code execution vulnerability affecting Magento Open Source and potentially Adobe Commerce.
Successful exploitation can allow an attacker to execute code on the server hosting an online store and install a persistent backdoor.
Sansec reported that one of the first compromised stores was running Magento 2.4.6-p15 with Adobe's July and August 2026 security updates already installed. This demonstrates that simply applying the latest available Magento security updates did not protect that installation from the newly discovered attack.
Adobe had not yet confirmed the complete list of affected Adobe Commerce versions, and Sansec had not published a full reproduction of the attack against Adobe Commerce or Adobe Commerce on Cloud.
Active Exploitation Confirmed
The vulnerability is not merely theoretical.
Sansec observed exploitation beginning on September 4, 2026, while independent Magento hosting company Disrex Group investigated multiple compromised stores.
Disrex reported two Magento Open Source stores that were compromised and a third store that was attacked but was not breached. The company's investigation was based on attack traffic captured from one of the compromised stores.
One affected store, referred to as Store A, was running Magento Open Source 2.4.8 and had Sansec Shield installed and active. It was attacked at approximately 23:10 UTC on September 4, before the first blocking rules for the vulnerability were available.
Another victim, Store B, was running Magento 2.4.7-p2. Disrex said it was first attacked around 00:55 UTC on September 5.
Both stores were compromised during the period between the first observed exploitation and the availability of defensive rules.
How the StyleSmuggler Attack Works
According to Sansec, the attack involves a multi-stage exploitation chain.
The first stage injects PHP code into a file that Magento normally creates during its operation, such as a failure report or log file.
The attacker then triggers Magento's Payment Transaction Failed Reminder functionality. Magento processes the malicious content while rendering the email, causing the injected PHP code to execute.
Importantly, the email does not need to be successfully delivered to the recipient for the malicious code to execute.
Disrex's independent analysis suggests that injected content can drive Magento's dependency-injection classes into code associated with the command-line dependency-injection compiler.
The chain eventually reaches attacker-controlled file inclusion, allowing the malicious PHP dropper to execute and attempt to launch a process that downloads and executes the final implant. Sansec has not yet publicly confirmed Disrex's complete interpretation of this chain.
Magento Logs Can Contain Evidence of Exploitation
Investigators should not rely on a single log directory when searching for evidence.
Sansec's initial detection method searched var/report/ for the marker X_TRACE_.
However, Disrex reported that both of its compromised stores contained malicious content in:
var/log/system.log
This means defenders should inspect both directories.
The attack markers also changed during the campaign. Disrex observed headers containing patterns such as X-TRACE- followed by ten hexadecimal characters and later variations without the TRACE component.
Because the marker changed, defenders should search for the broader pattern rather than relying on one exact string.
A TypeError involving array_merge() and an integer argument in system.log immediately after the malicious include can also indicate successful exploitation. However, Disrex warned that a stealthier variant can return an empty array and leave less obvious evidence.
Persistent Backdoor Installed on Compromised Servers
The post-exploitation payload uses persistence mechanisms designed to survive process termination and system activity.
Sansec identified a malicious process disguised as:
[kworker/u:8:0]
This name resembles a legitimate Linux kernel thread.
The malware is installed at:
~/.local/share/.gvfsd/gvfsd-user
rather than directly inside the Magento web root.
A cron job repeatedly launches the binary every five minutes.
Disrex described the malware as a stripped, statically linked Rust binary of approximately 1.9 MB, with builds targeting x86-64 and ARM64 systems.
The attacker also writes the cron entry directly into the cron spool, reducing the visibility normally associated with modifying a user's crontab.
One compromised store contained the same malicious cron entry 1,728 times, and the implant restored the entry within approximately one second after removal.
Malware May Access Magento Session Data
Disrex found that the implant does not necessarily require obvious outbound network communication.
On one compromised store, the malware maintained 28 connections to the store's Redis instance on port 6379 and accessed Magento session storage.
Interestingly, packet captures exceeding 200 MB did not contain connections to the download or command-and-control infrastructure listed by Sansec.
This highlights why network-based detection alone may not be sufficient for identifying StyleSmuggler compromises.
Published Indicators of Compromise
Security teams investigating Magento environments should check the following indicators.
Suspicious Process
[kworker/u:8:0] owned by a non-root user
A legitimate Linux kernel thread should normally be associated with root and should not exhibit the characteristics of a normal user-space process.
Suspicious Files
~/.local/share/.gvfsd/gvfsd-user
~/.local/share/.gvfsd/.gvfsd_<8hex>.lock
/tmp/.gvfsd_<8hex>.lock
/tmp/.kw_<random><random>
Suspicious Cron Entry
*/5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-user
A variant may point to:
/tmp/.kw_
SHA-256 Indicators
e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7
8334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06ef
251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220
Network Indicators
Malware download domain:
247.cdnflare[.]xyz
Command-and-control IP:
99.84.67[.]186:443
Attacker source IP:
88.216.72[.]181
Additional attacker source:
5.181.86[.]133
These indicators were published by Sansec and Disrex as part of their StyleSmuggler investigations.
Why Magento Security Teams Should Act Immediately
There is currently no official Adobe patch to install for the vulnerability described in the source material.
Sansec's temporary recommendation for stores that do not use its Shield product is to disable GraphQL until Adobe provides a fix. However, this can affect headless and progressive web application storefronts because they commonly rely on GraphQL. Traditional and Hyvä storefronts may not require it.
Disrex has also published unofficial mitigations, but these should be treated as temporary defensive measures rather than official vendor fixes.
Additional Temporary Mitigations
Disrex published web-server rules intended to block requests containing parameters associated with the currently observed exploitation campaign.
However, those rules have limitations. Testing showed that requests using the same parameters in POST or JSON bodies could still reach PHP because the nginx and Apache rules inspect the URL query string.
Another mitigation modifies Magento's dependency-injection code scanners to prevent them from being executed through HTTP requests.
Disrex said this approach can be reverted by Composer installations and therefore published a Composer patch to reapply the modification during deployments. The patch was reported as applicable across Magento 2.4.6 through 2.4.9.
Graycore also released a Magento module designed to harden several points in the suspected exploitation chain. The researchers explicitly described this as hardening rather than a complete fix.
Server-Level Protection
Two server-level controls can provide additional protection regardless of the exact exploitation chain.
Disable proc_open
Disrex observed that the dropper attempted several PHP functions to launch the malware. On one affected store, proc_open remained available and was used to start the implant.
Administrators can consider adding:
proc_open
to PHP's disable_functions configuration where compatible with their application.
Mount Temporary Directories With noexec
Disrex also recommends mounting:
/tmp
/var/tmp
/dev/shm
with the noexec option.
This can prevent downloaded binaries from being directly executed from these temporary locations and provides an additional layer of defense.
If Your Magento Store Is Already Compromised
Incident response should be performed carefully to preserve evidence.
Disrex recommends preserving evidence before removing malware.
Administrators should remove the malicious cron entry before killing the malware process, because the running implant can recreate the cron persistence mechanism.
A reboot should also be avoided during initial investigation because the executable accessible through /proc may be the only remaining copy of the malware.
Disrex additionally advises against immediately running composer install as a cleanup measure because doing so can overwrite timestamps that may provide useful forensic evidence.
After containment, administrators should flush Magento session storage and rotate:
- Magento
crypt/key - Magento administrator passwords
- Payment provider API keys
- Integration credentials stored in
app/etc/env.php - Other credentials potentially accessible to the compromised application
Scanner Limitations
Sansec recommends using its eComscan scanner to identify the implant.
However, Disrex discovered that a scheduled eComscan scan initially returned a clean result on one compromised store.
The reason was scan scope: the scanner was examining the store's document root, while the malware had been installed one directory above it inside the site's home directory.
Disrex subsequently widened its scanning path.
This demonstrates why Magento incident response should include the entire hosting account, not just the web root.
Adobe Patch Status
As of September 6, 2026, the source material states that Adobe had not published a CVE, official patch, advisory, or confirmed workaround for StyleSmuggler.
Adobe's next scheduled security release was expected on September 8, but it was not known whether that release would contain a fix for the vulnerability.
Until an official fix becomes available, Magento administrators should treat the vulnerability as an active incident-response concern rather than waiting for traditional patch-cycle remediation.
Key Takeaways
- StyleSmuggler is an actively exploited Magento zero-day.
- The attack can provide unauthenticated code execution on affected servers.
- Magento Open Source versions including 2.4.7, 2.4.8 and 2.4.9 were successfully tested by Sansec.
- The attack can install a persistent Linux backdoor using cron.
- Malware may operate outside the Magento web root, making basic web-root scans insufficient.
- Attackers can potentially access Magento session information stored in Redis.
- There is no official Adobe patch confirmed in the source material as of September 6, 2026.
- Disabling GraphQL is one temporary mitigation recommended by Sansec, although it can affect headless storefronts.
proc_openrestrictions andnoexecmounts for temporary directories can provide additional defense.- Compromised stores should undergo full forensic investigation and credential rotation.
