Unpatched Magento Zero-Day Exploited to Backdoor Stores

Attackers are exploiting a new unpatched vulnerability in Magento Open Source and Adobe Commerce to run malicious code on store servers without authentication. Dutch security firm Sansec, which discovered the flaw and named it StyleSmuggler, said attacks began on September 4.

Sansec published an advisory on September 5 because stores are being compromised. As of September 6, Adobe has not issued an advisory, a CVE identifier, a patch, or a workaround. Its security bulletin index shows nothing after an 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. The company reproduced the full unauthenticated attack chain on clean installations of versions 2.4.7, 2.4.8, and 2.4.9.

Its first victim ran version 2.4.6-p15 with Adobe's July and August 2026 security updates applied. This is the latest patch level Adobe offers for that release line. Sansec has not published a reproduction on Adobe Commerce or Adobe Commerce on Cloud, and Adobe has not confirmed which versions are affected.

Attack Details and Evidence

The attack works in two stages. First, it plants PHP code in a file that Magento itself writes, such as a failure report log. Then, it triggers Magento's standard "Payment Transaction Failed Reminder" email, which executes the code while the message is rendered. The attack can succeed even if email delivery fails.

Disrex Group, a Magento hosting and development company, provided independent evidence of exploitation. The company handled two compromised stores and a third that was attacked but not breached. Both compromised stores ran Magento Open Source, not Adobe Commerce.

Disrex detailed the two cases:

Store B's security patch level, 2.4.7-p2, dates to August 2024 and is eight levels behind the current 2.4.7-p10. Both stores were breached in the roughly eight-hour window between the first observed exploitation and the moment any defense existed. "Patch status was irrelevant here, which is the part merchants most need to hear," Disrex told reporters.

The Implant and Detection

The implant is a background process disguised under the name [kworker/u:8:0], which belongs to a Linux kernel thread. A binary is installed at ~/.local/share/.gvfsd/gvfsd-user under the site user's home directory. 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. The cron entry is written directly to the spool file, so the system log shows no crontab replacement. On one store, the same cron line was present 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 connections. It held 28 connections to the store's own Redis instance on port 6379 and read Magento's session storage from it. Disrex said packet captures taken while the implant was live contained no traffic to the download host or command-and-control address listed by Sansec.

Disrex confirmed the stores were isolated, with the implant running as an unprivileged site user. The company found no evidence of lateral movement, data exfiltration, rogue admin accounts, payment skimmers, or database backdoors. Both stores were contained the same day they were hit.

Mitigation and Investigation

Sansec's interim 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. Adobe's next scheduled security release is on September 8, but it is not yet known if it will cover this bug.

For detection, Sansec's published check searches var/report/ for a marker. Disrex said both of its infections poisoned var/log/system.log instead, so both directories need searching. The marker has already drifted, so a search should match the shape of the header rather than an exact string.

A TypeError from array_merge() with an integer argument in system.log is evidence the exploit succeeded. A stealthier variant returns an empty array and leaves nothing in the log. Disrex advises that a genuine kernel thread is owned by root and has no resident memory, so a bracketed process name running under the site user with real memory usage is likely the implant.

The company also found that the binary running in memory on one store was a different build from the file on disk. It recommends hashing the running process from /proc/<pid>/exe as well as the on-disk file. Unexpected bursts of "Payment Transaction Failed Reminder" emails are a reason to investigate, Sansec said. One of Disrex's compromises was surfaced by exactly that email.