Attackers are exploiting a new unpatched vulnerability in Magento Open Source and Adobe Commerce that lets them run malicious code on an online store’s server without logging in, Dutch e-commerce security company Sansec said in an advisory published on September 5.
Sansec, which discovered the flaw and named it StyleSmuggler, said attacks started on September 4. “Sansec is publishing early because stores are being compromised right now,” the company said.
As of September 6, Adobe has not published an advisory, a CVE identifier, a patch, or a workaround, and its Adobe Commerce security bulletin index lists nothing after the August 11 update.
A successful attack gives the attacker code execution on the store’s server and installs a persistent backdoor. Sansec said all current versions are affected, including 2.4.9, and that it reproduced the full unauthenticated chain on clean Magento Open Source installations of 2.4.7, 2.4.8, and 2.4.9.
Its first victim ran 2.4.6-p15 with Adobe’s July and August 2026 security updates applied, which is the latest patch level Adobe offers for that release line and one that Adobe’s August bulletin labels 2.4.6-2026-aug.
Sansec has not published a reproduction on Adobe Commerce or on Adobe Commerce on Cloud, and Adobe has not confirmed which versions are affected. Sansec has not said how many stores have been compromised.
The researchers’ interim advice for stores not running its Shield product is to disable GraphQL until Adobe releases a temporary fix.
Disrex Group, a Magento hosting and development company that responded to two of the compromised stores, notes that headless and progressive web app storefronts require GraphQL, whereas most classic and Hyvä storefronts do not.
Adobe’s next scheduled security release is on September 8, Sansec said, and it is not yet known whether that release will cover this bug.
Disrex’s findings are independent evidence of exploitation from outside Sansec. In an incident-response repository published on September 5, the company said it handled two stores compromised on September 5 and a third that was attacked but not breached, and that its web-server rules are based on attack traffic captured on one of the compromised stores.
That store 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. The store Disrex labels Store A was a Sansec Shield customer and was hit at 23:10 UTC on September 4, hours before Sansec’s first blocking rules went live.
The repository carries its own warning. “This repository was written with AI assistance, during a live incident, in a few hours,” its README says, adding that it has not been reviewed, that its Apache rules were never run against a live Apache server, and that most of its cleanup commands were written rather than executed.
Sansec’s indicators describe the implant as a background process disguised under [kworker/u:8:0], a name that belongs to a Linux kernel thread, with a binary installed at ~/.local/share/.gvfsd/gvfsd-user under the site user’s home directory rather than the web root, and a cron entry that 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, and said the cron entry is written straight to the spool file under /var/spool/cron/crontabs/, so the system log shows no crontab replacement.
One store carried the same 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. It read Magento’s session storage from it, Disrex said, and neither of its two packet captures, each over 200 MB and taken. At the same time, the implant was live, contained a single packet to the download host or the command-and-control address that Sansec listed.
Sansec said that for Shield customers attacked before its rules went live, it has no indication that the backdoor was actually used, and recommended rotating Magento credentials wherever the process has been identified.
The attack works in two stages, according to Sansec’s outline. It first plants PHP code in a file that Magento itself writes, for example, when generating a failure report. Then it makes Magento execute that file by triggering the platform’s standard “Payment Transaction Failed Reminder” email. The code runs while Magento renders the message, so no one has to open it, and the attack can succeed even if email delivery fails.
Sansec has not yet published the full exploit chain and said a breakdown of the chain, the dropper, and the implant will follow in an update.
Disrex’s reading of the chain, published in a mechanism write-up alongside its rules, is that 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 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. Sansec has not confirmed that reading, and Disrex does not publish the assembled request.
Two locations matter for the first stage. 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, so both directories need searching.
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, so a search should match the shape rather than the exact string.
A TypeError from array_merge() with an integer argument in system.log, immediately after the include, is evidence that the exploit succeeded, Disrex said. However, a stealthier variant returns an empty array and leaves nothing in the log.
For the process, Disrex said that 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. The implant sets its command line to the literal bracketed string, so a check written against the process’s comm field matches nothing.
Disrex also found that the binary running in memory on one store was a different build from the file on disk, and advises hashing the running process from /proc/ as well as the file. Unexpected bursts of “Payment Transaction Failed Reminder” emails are a 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_ - Cron:
*/5 * * * * exec, with a variant pointing at/.local/share/.gvfsd/gvfsd-user /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 the opposite result for one store: eComscan ran with its background-process and scheduled-task checks enabled while the implant was live, with 1,728 cron lines present, and reported the store clean. Disrex did not say which eComscan version ran or when.
There is no vendor fix to install. Until Adobe ships one, the options are Sansec’s temporary GraphQL shutdown; three unofficial mitigations published by Disrex, ProxiBlue, and Graycore; and two server settings that do not depend on the flaw.
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 said. Disrex describes the rules as stopping the campaign as it currently runs rather than the vulnerability.
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 ships it as 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, so Disrex tells administrators to search their vendor directory before touching it.
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, published the same guard on September 5, along with three unofficial patches. Neither Sansec nor Adobe has confirmed that these scanners are where the chain ends.
Graycore, LLC published a Magento module on GitHub and Packagist on September 5 whose 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, Disrex said. At one of its two stores, the first four of the six PHP functions the dropper tried were disabled; proc_open was not, and the dropper used it to start the implant, with open_basedir doing 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.
For a store that is already infected, Disrex’s cleanup guide sets the 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, and do not run composer install to clean up because it overwrites the timestamps that show what was touched.
It then recommends flushing session storage since the implant read it, and rotating the crypt/key in app/etc/env.php, as well as 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 recorded 26 distinct source addresses across its two stores, two of them hosting infrastructure sending in bulk and the rest a residential proxy pool sending two to six requests each, and said that blocking the single attacker address in Sansec’s advisory would have stopped less than a quarter of the traffic it saw. No source has named the attackers.
The Hacker News has reached out to Adobe, Sansec, Disrex and Graycore for comment, and will update the story if we hear back.
