Unpatched Magento Zero-Day Used to Backdoor Online Stores

Sansec, a Dutch e-commerce security company, disclosed on September 5 that attackers are actively exploiting a new unpatched vulnerability in Magento Open Source and Adobe Commerce. The flaw, which Sansec named StyleSmuggler, lets an attacker run malicious code on an online store's server without logging in. Sansec says attacks began on September 4, and the company published early because stores are being compromised right now. As of September 6, Adobe has not published an advisory, a CVE identifier, a patch, or a workaround, and its security bulletin index shows 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 says all current versions are affected, including 2.4.9, and it reproduced the full unauthenticated chain on clean Magento Open Source installations of 2.4.7, 2.4.8, and 2.4.9. 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. 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. 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.

The attack works in two stages according to Sansec. First, it 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. Disrex Group, a Magento hosting and development company that handled two of the compromised stores, published a mechanism write-up. Disrex says 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, and told The Hacker News it identified that sink on its own by reading Magento source on the compromised store. Sansec has not confirmed that reading, and Disrex does not publish the assembled request. 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 incident-response repository provides independent evidence of exploitation from outside Sansec. Disrex said it handled two compromised stores 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. In answers to The Hacker News, Disrex said both stores ran Magento Open Source rather than Adobe Commerce, and it hosts them itself through its hosting brand RexHosting. Store A ran 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 this flaw went live, and Disrex said Shield was active and blocking other malicious traffic against the store at the time. Store B, which was not a Shield customer, ran Magento 2.4.7-p2, a security patch level dated August 2024, eight levels behind the current 2.4.7-p10. It 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 defence for it existed, Disrex said. "Patch status was irrelevant here, which is the part merchants most need to hear," the company told The Hacker News. Disrex told The Hacker News over email that each store ran in its own isolated account with a single site owner, no sudo rights, and no path to any other customer, that the implant ran as the unprivileged site user and could reach nothing beyond that store, and that it confirmed no lateral movement and no other affected site on its platform.

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 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. 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. Both stores were contained the same day, roughly eleven and fourteen hours after first contact, and 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 is underway as a precaution. The published indicators include the process name [kworker/u:8:0], the file paths ~/.local/share/.gvfsd/gvfsd-user and related lock files, the cron entry, and SHA-256 hashes e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7, 8334b434fa3fe9f59cebe9609b11e0b1fd19d10212c45c705adec1902a1d06ef, and 251fabd50d7b18a8b5e1b3ef5d64e7198c17244778f6461fb1ab07f6169bf220. The malware download host is 247.cdnflare[.]xyz, and command-and-control addresses include 99.84.67[.]186:443 over WebSocket and TLS, with attacker sources 88.216.72[.]181 and 5.181.86[.]133.

Detection is complicated by the implant's stealth. 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 fr