Zero-Day Backdoor Campaign Targets Magento Stores

Attackers are actively exploiting a previously unknown vulnerability in Magento Open Source and Adobe Commerce, using it to plant persistent backdoors on online store servers without any authentication. The campaign, detailed in an advisory published September 5 by Dutch e-commerce security firm Sansec, is hitting stores now, and the company says it is releasing its findings early because "stores are being compromised right now."

Sansec, which discovered the flaw and dubbed it StyleSmuggler, observed the first exploitation on September 4. As of September 6, Adobe has not yet 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. Adobe's next scheduled security release is set for September 8, Sansec said, but it remains unclear whether that update will address this particular bug.

Unauthenticated Code Execution

The vulnerability allows an attacker to execute arbitrary code on a store's server without logging in. A successful attack results in full code execution and the installation of a persistent backdoor. Sansec says all current versions are affected, including 2.4.9, and it reproduced the complete unauthenticated attack chain on clean installations of Magento Open Source 2.4.7, 2.4.8, and 2.4.9.

Sansec's first confirmed victim was running Magento Open Source 2.4.6-p15, with Adobe's July and August 2026 security updates applied. That is the latest patch level Adobe offers for the 2.4.6 release line, a version Adobe's August bulletin labels 2.4.6-2026-aug. The fact that a fully patched store was compromised underscores that this is not a case of neglected maintenance.

Notably, Sansec has not published a reproduction of the attack on Adobe Commerce or Adobe Commerce on Cloud, nor has Adobe confirmed which versions are vulnerable. The company has also not disclosed how many stores have been breached so far.

Two-Stage Attack Chain

According to Sansec's outline, the attack unfolds in two stages. First, it plants PHP code into a file that Magento itself writes, for instance when generating a failure report. Second, it tricks Magento into executing that file by triggering the platform's standard "Payment Transaction Failed Reminder" email. The injected code runs while Magento renders the message, meaning nobody needs to open the email for the attack to succeed, and it can even work if email delivery fails.

Sansec has not yet published the full exploit chain, saying a detailed breakdown of the chain, the dropper, and the implant will follow in a future update.

Independent Confirmation from Disrex

While Sansec's advisory is the primary source, independent evidence of active exploitation has emerged from Disrex Group, a Magento hosting and development company. Disrex responded to two compromised stores and published its findings in an incident-response repository on September 5. The company says it handled two stores that were breached and a third that was attacked but not compromised. Its web-server rules are based on attack traffic captured from one of the breached stores.

In answers to questions from The Hacker News, Disrex confirmed both compromised stores ran Magento Open Source rather than Adobe Commerce, and that it hosts both through its hosting brand RexHosting. This external validation is significant because it shows the attack is not limited to a single hosting environment or a specific set of configurations.

Patch status was irrelevant here, which is the part merchants most need to hear.

— Disrex Group, in a statement to The Hacker News.

Breach Timeline and Impact

Disrex's analysis reveals a narrow and dangerous window. Both stores it handled were breached within roughly eight hours between the first exploitation Sansec observed and the moment any defensive measures became available. The store Disrex labels Store A ran Magento Open Source 2.4.8 and was a Sansec Shield customer, with the security 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. 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 an older Magento version: 2.4.7-p2, a security patch level that Adobe's version history dates to August 2024. That is eight patch levels behind the current 2.4.7-p10. Store B was first hit at 00:55 UTC on September 5, and it is the store from which Disrex derived its web-server rules and its analysis of the vulnerable code.

Both stores were contained the same day, roughly eleven and fourteen hours after first contact. Disrex found no evidence of data exfiltration, no rogue admin accounts, no injected payment skimmer, and no database backdoor. It invalidated all sessions and is rotating credentials as a precaution.

Anatomy of the Backdoor

Sansec's indicators describe the implant as a background process disguised under the name [kworker/u:8:0], which normally belongs to a Linux kernel thread. The binary is installed at ~/.local/share/.gvfsd/gvfsd-user under the site user's home directory, not the web root, and a cron entry restarts it every five minutes.

Disrex's analysis adds further detail. It describes the binary as a stripped, statically linked Rust program of roughly 1.9 MB, built for x86-64 and arm64 architectures. The cron entry is written directly to the spool file under /var/spool/cron/crontabs/, so the system log shows no crontab replacement. On one store, the same cron line appeared 1,728 times, and the implant re-added it within a second of removal.

Disrex observed that on one of the two stores, the implant made no outbound network connection at all. Instead, it held 28 connections to the store's own Redis instance on port 6379 and read Magento's session storage from it. Neither of the 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. This suggests the backdoor's primary purpose is stealthy data collection rather than immediate communication with an external server.

Detection Guidance

Sansec and Disrex have published a set of indicators to help store owners detect the implant:

• 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
• Cron entry: */5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-user
• 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)

Disrex flags that genuine kernel threads are owned by root and have no resident memory, so a bracketed name on the site user with real memory usage is a strong indicator of the implant. The implant sets its command line to the literal bracketed string, meaning checks that rely solely on the process's comm field will not detect it. 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/<pid>/exe as well as the file on disk.

Sansec notes that a TypeError from array_merge() with an integer argument in system.log, immediately after the include, is evidence that the exploit succeeded. However, a stealthier variant returns an empty array and leaves no trace in the log.

Mitigation Challenges

With no vendor fix available, store owners face a difficult situation. Sansec's interim advice for stores not running its Shield product is to temporarily disable GraphQL until Adobe releases a patch. Disrex points out that headless and progressive web app storefronts require GraphQL, whereas most classic and Hyvä storefronts do not, meaning this mitigation is not viable for all stores.

Disrex has published nginx and Apache rules that block requests carrying the exploit's parameters in the URL query string. However, its own tests on a live store revealed a limitation: 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 describes the rules as stopping the campaign as it currently runs rather than fixing the underlying vulnerability.

For a more robust fix, Disrex offers a hand edit to three methods in Magento's dependency-injection code scanners, preventing them from running outside the command line. This edit is reverted by every composer install, so Disrex also ships it as a composer-patches source patch that reapplies on deploy and applies unchanged from Magento 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. Disrex advises administrators to search their vendor directory before applying the guard.

Disrex admits the guard was tested on a harness rather than inside a running store and is not a complete fix on its own. Sansec also recommends its eComscan scanner to detect the implant, and says version 1.9.7 will terminate the process for Shield customers.

Detection Gaps and Lessons

The incident reveals significant gaps in standard security scanning. Disrex reported a clean result on Store A even while it was actively compromised. eComscan ran there at 10:00 UTC on September 5, roughly eleven hours after the implant first executed and while 1,728 cron lines were present, and reported the store clean. The cause was scope rather than a scanner fault, Disrex told The Hacker News: the scheduled scan was pointed at the store's document root, and the implant had installed one directory above it, under the account's home directory. Disrex has since widened the scan path and said it would confirm the eComscan build number separately.

This episode also shows how quickly attackers could adapt. Sansec's published check searches var/report/ for the marker X_TRACE_. But Disrex said both of its infections were poisoned through var/log/system.log instead, meaning they would have been missed by that check. The marker itself has already drifted: Disrex observed 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. A search should therefore match the shape rather than the exact string.

What This Means for Merchants

This zero-day should serve as a sobering reminder that even fully patched Magento stores are not safe from sophisticated attacks. The fact that a store running the latest security updates from July and August 2026 was compromised demonstrates that patching alone is insufficient when a new vulnerability is exploited before a vendor fix exists.

The rapid adoption of a different log location and header format within hours of Sansec's disclosure suggests the attackers are actively monitoring defensive research and adjusting their techniques accordingly. Merchants need to assume that their stores could be targeted and prepare for a worst-case scenario where they must detect and respond to a backdoor without vendor support.

Having a tested incident-response plan, visibility into processes running on the server, and the ability to quickly audit web logs and file systems will be as important as applying patches when they become available. The window between first exploitation and the availability of a fix is often the most dangerous period, and this incident illustrates how defenders must be ready to act independently during that gap.