Fully patched Magento stores are being backdoored four days ahead of Adobe's next security release
Sansec reproduced an unauthenticated code-execution chain on clean 2.4.7, 2.4.8 and 2.4.9 installs, and the first victim it saw was already on Adobe's newest patch level for its release line.
The Watch · Security desk
What happened
- Sansec published an advisory on September 5 for an unpatched unauthenticated code-execution flaw it calls StyleSmuggler in Magento Open Source and Adobe Commerce, and said attacks began September 4.
- Sansec says every current version is affected, including 2.4.9, and that it reproduced the full chain on clean Magento Open Source installs of 2.4.7, 2.4.8 and 2.4.9.
- As of September 6 Adobe had published no advisory, CVE, patch or workaround, and its Commerce bulletin index still ended at the August 11 update.
- Magento host Disrex Group independently handled two stores compromised on September 5 and a third that was attacked but not breached, and built web-server rules from traffic captured on one of them.
- Sansec's interim advice for stores not running its Shield product is to disable GraphQL until Adobe ships a temporary fix, and the flaw's exploitation installs a persistent backdoor.
Why it matters
- Who has to decide decision The only mitigation on offer is decided by frontend architecture rather than risk appetite: headless and progressive web app storefronts need GraphQL to serve pages, so switching it off is a storefront outage, while most classic and Hyva builds lose little.
- Who's exposed exposure Adobe has confirmed nothing about affected versions and nobody has published a reproduction on Adobe Commerce on Cloud, so cloud-hosted merchants cannot scope themselves either in or out of this.
- What it limits constraint A playbook that checks web-root integrity and watches for outbound callbacks will hand back a clean verdict on a host that is still backdoored, because the implant sits in the site user's home directory and one sample spoke only to local Redis.
- What it costs cost Every store where the disguised process turns up owes a full Magento credential rotation on Sansec's own advice, and its Shield customers attacked before the blocking rules shipped are in that queue too.
Next story · Security · 15h ago
Suspected China-nexus actor exploited BeyondTrust Remote Support zero-day from late AugustConfirmed8 publishers
The chain is short. Stage one plants PHP inside a file Magento writes itself, a failure report for example. Stage two triggers the platform's standard Payment Transaction Failed Reminder email, which makes Magento execute the file it just wrote [15]. No login is involved at any point [1].
Sansec's first victim ran 2.4.6-p15 with Adobe's July and August 2026 updates applied, the newest level Adobe offers for that line and the one its August bulletin labels 2.4.6-2026-aug [8], and it was still hit. The store Disrex captured attack traffic from ran 2.4.7-p2, which Adobe's version history dates to August 2024, eight levels behind 2.4.7-p10 [16] and about 25 months old by the September 5 compromise [21]. Patch level did not sort exposure: both ends of that spread fell.
Sansec Shield covered the store Disrex labels Store A, and Store A was hit at 23:10 UTC on September 4, hours before Sansec's first blocking rules went live [13]. The publicly available alternative is the Disrex repository, whose README says it was written with AI assistance in a few hours during a live incident, has not been reviewed, contains Apache rules that were never run against a live Apache server, and carries cleanup commands that were mostly written rather than executed [17]. The rules come from real captured attack traffic [12], but they have not been tested as a control.
Detection assumptions that work on Magento card skimmers do not transfer. The binary sits at ~/.local/share/.gvfsd/gvfsd-user in the site user's home directory, outside the web root, and the process presents as [kworker/u:8:0], the naming convention of a Linux kernel thread [7]. Disrex measured a stripped, statically linked Rust binary of roughly 1.9 MB built for x86-64 and arm64, with the cron line written straight into /var/spool/cron/crontabs/ so no crontab replacement appears in the system log [9]. On one of its two compromised stores the implant opened no outbound connection at all: 28 connections to the store's own Redis on port 6379, reading Magento session storage, and not one packet to Sansec's listed download host or command-and-control address across two captures of more than 200 MB each [19]. Integrity monitoring scoped to the web root sees none of that, and neither does egress alerting.
The cron entry restarts the process every five minutes, which is 288 restarts in a day [22]. One store carried the same line 1,728 times, and the implant re-added it within a second of removal [18]. If each duplicate were one cycle, 1,728 lines would be six days of appends [23], putting that infection before Sansec's September 4 start date. Sansec has not dated that store, and the observed re-add interval is a second rather than five minutes, so the arithmetic is a question for the responder, not a dwell time.
Adobe's next scheduled security release is September 8, and whether it covers this bug is not known [24]. Attacks began September 4 [2], so the floor on the window is four days [25]. Adobe's Commerce bulletin index has shown nothing after the August 11 update, 26 days as of September 6 [6][20]. There is also no CVE, which means nothing lands in a vulnerability feed and nothing shows up in a supplier questionnaire [6].
What to watch
- Whether Adobe's September 8 release ships a fix and a CVE for StyleSmuggler or leaves stores on the GraphQL workaround.
- A published reproduction on Adobe Commerce on Cloud, or an Adobe statement naming affected versions.
- Any report of the backdoor being used rather than merely installed; Sansec says it has no indication of use on Shield stores hit before its rules went live.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence78
- Adoption55
- Hype gap+15
- Incentives55
- Confidence75
Perspective Coverage
7 publishers- Builder
- Builder 29%
- Operator
- Operator 63%
- Investor
- Investor 8%
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
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, according to an advisory published on September 5 by Dutch e-commerce security company Sansec.
- [2]
Sansec discovered the flaw, named it StyleSmuggler, and said attacks started on September 4, adding that it was publishing early because stores were being compromised at the time.
- [3]
A successful attack gives the attacker code execution on the store's server and installs a persistent backdoor.
- [4]
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.
- [5]
Sansec has not published a reproduction on Adobe Commerce or on Adobe Commerce on Cloud, Adobe has not confirmed which versions are affected, and Sansec has not said how many stores have been compromised.
- [6]
As of September 6, Adobe had not published an advisory, a CVE identifier, a patch or a workaround, and its Adobe Commerce security bulletin index listed nothing after the August 11 update.
- [7]
Sansec's indicators describe the implant as a background process disguised under [kworker/u:8:0], a name belonging 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.
- [8]
Sansec's first victim ran 2.4.6-p15 with Adobe's July and August 2026 security updates applied, the latest patch level Adobe offers for that release line and the one Adobe's August bulletin labels 2.4.6-2026-aug.
- [9]
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.
- [10]
Sansec's interim advice for stores not running its Shield product is to disable GraphQL until Adobe releases a temporary fix.
- [11]
Disrex Group notes that headless and progressive web app storefronts require GraphQL, whereas most classic and Hyva storefronts do not.
- [12]
Disrex Group, a Magento hosting and development company, said in an incident-response repository published on September 5 that 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.
- [13]
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.
- [14]
Sansec said that for Shield customers attacked before its rules went live it has no indication the backdoor was actually used, and recommended rotating Magento credentials wherever the process has been identified.
- [15]
The attack works in two stages, according to Sansec's outline: it first plants PHP code in a file Magento itself writes, for example when generating a failure report, then makes Magento execute that file by triggering the platform's standard Payment Transaction Failed Reminder email.
- [16]
The store Disrex captured attack traffic from ran Magento 2.4.7-p2, a patch level Adobe's version history dates to August 2024 and which is eight levels behind the current 2.4.7-p10.
- [17]
The Disrex repository README says it was written with AI assistance during a live incident in a few hours, 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.
- [18]
One store carried the same cron line 1,728 times, and the implant re-added it within a second of removal.
- [19]
On one of the two compromised stores the implant made no outbound connection at all, holding 28 connections to the store's own Redis instance on port 6379 and reading Magento's session storage from it, and neither of two packet captures of more than 200 MB each, taken while the implant was live, contained a single packet to the download host or the command-and-control address Sansec listed.
- [20]
Adobe's Commerce security bulletin index had gone 26 days without a new entry as of September 6, counting from the August 11 update.
- [21]
The 2.4.7-p2 patch level on the store Disrex captured traffic from was about 25 months old when that store was compromised on September 5, 2026.
- [22]
A cron entry that restarts the implant every five minutes fires 288 times in 24 hours.
- [23]
If each of the 1,728 duplicate cron lines corresponded to one five-minute cycle, they would represent six days of appends.
- [24]
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.
- [25]
Attacks starting September 4 and Adobe's next scheduled security release on September 8 put a floor of four days on the exposure window, and only if that release covers the bug.
Sources
7 independent publishers whose own reporting we read for this story.
- bleepingcomputer.comMagento StyleSmuggler zero-day exploited to deploy Linux backdoor
2 articles · September 8, 2026
- StyleSmuggler
sansec.io
1 article · September 8, 2026
- securityaffairs.comStyleSmuggler: The Magento Zero-Day Behind New Store Attacks
1 article · September 7, 2026
- securityweek.comAdobe Commerce Zero-Day Exploited to Backdoor Online Stores
2 articles · September 8, 2026
- tenable.comStyleSmuggler (CVE-2026-75650): Frequently asked questions about Adobe Commerce and Magento zero-day
1 article · September 8, 2026
- thecyberexpress.comAttackers Exploit Unpatched Magento Zero-Day to Backdoor Online Stores
1 article · September 7, 2026
- thehackernews.comUnpatched Magento and Adobe Commerce Zero-Day Exploited to Backdoor Online Stores
3 articles · September 8, 2026
Topics and entities
Topics
- Zero-Day Vulnerabilities
- Linux malware
- E-commerce security