Unpatched Magento and Adobe Commerce Zero-Day Exploited to Backdoor Online Stores

Summary

A new unpatched zero-day vulnerability, dubbed StyleSmuggler, is being actively exploited in Magento Open Source and Adobe Commerce. The flaw allows attackers to gain unauthenticated code execution and install persistent backdoors on online store servers. All current versions are reportedly affected, and attacks began shortly before the vulnerability was publicly disclosed.

Full text

Unpatched Magento and Adobe Commerce Zero-Day Exploited to Backdoor Online Stores Swati KhandelwalSep 05, 2026Zero Day / Vulnerability 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 temporarily disable GraphQL until Adobe releases a fix. Disrex Group, a Magento hosting and development company that hosts and 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 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 questions from The Hacker News, Disrex said both stores ran Magento Open Source rather than Adobe Commerce, and that it hosts them itself through its hosting brand RexHosting. The store Disrex labels 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 that Adobe's version history dates to August 2024, eight levels behind the current 2.4.7-p10. It was first hit at 00:55 UTC on September 5, Disrex said, and it is the store from which the company's web-server rules and its reading of the vulnerable code were taken. 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. 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 and read Magento's session storage from it, Disrex said, and 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. 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.Both stores were contained the same day, roughly eleven and fourteen hours after first contact, the company said, and it 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.Because it runs a number of Magento stores on its own platform and found the first compromise quickly, Disrex said, it swept its whole estate within the hour and found the second store the same afternoon. The company has also published an incident write-up. 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, 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. 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 Type

Indicators of Compromise

• malware — StyleSmuggler
• mitre_attack — T1070.004

Entities