StyleSmuggler Zero-Day Backdoors Fully Patched Magento Stores

Attackers are exploiting an unpatched Magento Open Source vulnerability to execute code remotely without authentication and install a persistent Linux backdoor. Adobe Commerce may also be exposed, although that product has not yet been conclusively tested.

Dutch e-commerce security company Sansec named the flaw StyleSmuggler and disclosed the campaign on September 5, 2026, after observing attacks beginning on September 4. Independent investigations by Disrex Group confirmed two successful compromises and one attempted intrusion.

As of September 6, Adobe had not released an advisory, CVE identifier, patch, or official workaround. Its Commerce security bulletin index had not been updated since August 11.

Current Magento Releases Are Confirmed Vulnerable

Sansec reproduced the complete unauthenticated exploitation chain against clean installations of Magento Open Source:

• 2.4.7
• 2.4.8
• 2.4.9

The company considers all current Magento versions affected, including 2.4.9.

Its first identified victim used Magento Open Source 2.4.6-p15, with Adobe’s July and August 2026 security updates installed. Adobe identifies that release-line patch level as 2.4.6-2026-aug, the latest available for the 2.4.6 branch.

Disrex separately investigated a compromised 2.4.8 store and another running 2.4.7-p2. The latter was eight patch levels behind the then-current 2.4.7-p10, but patch status did not determine the outcome: both systems were breached.

The product scope beyond Magento Open Source remains uncertain. Sansec has not published a successful reproduction against Adobe Commerce or Adobe Commerce on Cloud, and Adobe has not confirmed which versions are affected.

Adobe’s next scheduled security release is September 8, but it is not known whether that update will address StyleSmuggler. No CISA Known Exploited Vulnerabilities listing or associated remediation deadline had been reported as of September 6.

Malicious Email Rendering Completes the Attack Chain

StyleSmuggler uses two stages to turn data written during routine Magento operations into executable PHP code.

First, the attacker injects PHP into a file Magento can create or update, such as a failure-report file. The attacker then triggers Magento’s standard “Payment Transaction Failed Reminder” email, causing the platform to process the poisoned file while rendering the message.

A recipient does not need to open the email. The code can execute even if delivery fails.

An unusual increase in payment-failure reminders should therefore be investigated, although these messages can also result from legitimate declined transactions.

Disrex’s source-code analysis indicates that an injected directive invokes Magento classes associated with the command-line dependency-injection compiler. The resulting sequence incorporates an attacker-selected file path pointing to the file poisoned moments earlier.

Investigators traced the apparent endpoint to three files beneath:

setup/src/Magento/Setup/Module/Di/Code/

Sansec has not confirmed this interpretation, while Disrex has not released the fully assembled malicious request. The complete exploit chain, dropper, and implant analysis also remain unpublished.

Once code execution succeeds, a PHP dropper tries six process-creation functions in sequence. It then downloads and launches the backdoor.

The Implant Hides as a Linux Kernel Worker

The malware runs in the background with the deceptive process name:

[kworker/u:8:0]

That label imitates a Linux kernel thread. However, a genuine kernel worker is root-owned and has no resident user-space memory. A bracketed kworker process owned by a Magento site account and consuming memory is highly suspicious.

The implant sets its command line to the bracketed name, so detection based only on the process comm field may miss it.

The principal payload location is outside the web root:

~/.local/share/.gvfsd/gvfsd-user

Disrex described the payload as a stripped, statically linked Rust executable of approximately 1.9 MB, with builds for x86-64 and arm64. Persistence is established through a cron entry that restarts it every five minutes:

*/5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-user

A second variant launches a payload from /tmp/.kw_.

Instead of replacing the crontab through the usual command, the malware writes directly into:

/var/spool/cron/crontabs/

This technique avoids generating the expected crontab-replacement event in system logs. One compromised store contained the same malicious line 1,728 times, and the implant restored it within one second of removal.

Other relevant paths include:

~/.local/share/.gvfsd/.gvfsd_<8hex>.lock
/tmp/.gvfsd_<8hex>.lock
/tmp/.kw_<random><random>

On one system, the running executable differed from the payload stored on disk. Responders should therefore hash both the file and the executable mapped through:

/proc/<pid>/exe

Two Stores Were Breached Before Defences Arrived

Disrex, which operates Magento hosting under the RexHosting brand, confirmed two compromises on isolated customer accounts.

The first affected store ran Magento Open Source 2.4.8 and was attacked at 23:10 UTC on September 4. Sansec Shield was installed, enabled, and blocking other malicious traffic, but StyleSmuggler-specific rules were not yet available.

A second store running 2.4.7-p2 was first attacked at 00:55 UTC on September 5. It was not a Shield customer. Disrex used evidence recovered from this system to develop its technical analysis and web-server rules.

Both compromises occurred during an approximately eight-hour interval between the campaign’s first observed activity and the availability of dedicated protections.

The affected accounts had one site owner each, no sudo access, and no route into other customers’ environments. The malicious process ran as the unprivileged site user. Disrex found no lateral movement or compromise of additional hosted sites.

Both stores were contained on the day they were discovered, approximately eleven and fourteen hours after first contact. Sessions were invalidated and credential rotation began as a precaution.

Investigators found no evidence of:

• Stolen data
• Payment-card skimmers
• Rogue administrator accounts
• Database backdoors
• Lateral movement
• Compromise of neighboring sites

The number of affected stores outside these investigations is unknown.

Detection Must Extend Beyond the Document Root

Sansec’s initial detection check searches var/report/ for:

X_TRACE_

That search alone is insufficient. Both infections examined by Disrex instead poisoned:

var/log/system.log

The marker also changed during the campaign. Earlier requests used an X-TRACE--style header followed by ten hexadecimal characters; later traffic omitted the word TRACE. Detection rules should match the broader structure rather than one fixed string.

A TypeError showing array_merge() receiving an integer immediately after the relevant include operation indicates successful exploitation. This is not universal: a quieter variant returns an empty array and leaves no equivalent error.

Published SHA-256 indicators include:

e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7
8334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06ef
251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220

Network indicators are:

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

Absence of external traffic does not prove a system is clean. One implant made no observed outbound connection but opened 28 connections to the store’s Redis service on port 6379 and accessed Magento session data.

Document-root-only scans can also produce false reassurance. One compromised store returned a clean scanner result while its home directory contained the payload and 1,728 malicious cron entries.

What Magento Operators Should Do Now

With no official patch available, operators must combine temporary exposure reduction with account-level forensic checks.

Sansec recommends temporarily disabling GraphQL for stores without Shield protection. This may be impractical for headless and progressive-web-application storefronts, which depend on GraphQL, while classic and Hyvä deployments generally do not.

Disrex, ProxiBlue, and Graycore have released unofficial mitigations. Disrex’s source patch prevents three dependency-injection scanner methods from running through HTTP and limits them to command-line execution. Its composer-patches version reportedly applies across Magento 2.4.6 through 2.4.9 and survives Composer deployments.

Administrators should test compatibility first. The third-party package mageplaza/module-admin-permissions invokes ClassesScanner.php over HTTP, so the guard can break its administrative interface.

Published nginx and Apache rules block parameters used in observed attacks, but only when they appear in the query string. Equivalent parameters in POST or JSON bodies still reach PHP. These rules disrupt the current campaign; they do not repair the vulnerability.

Incident responders should search the entire hosting account, including user home directories, /tmp, cron spool files, var/report/, and var/log/system.log. They should inspect running processes through /proc, compare memory and disk hashes, invalidate Magento sessions, and rotate credentials.

A clean storefront scan is not enough. Neither is removing the visible binary without terminating the process and eliminating its cron persistence.