TL;DR
- what: Sansec disclosed StyleSmuggler on September 5, 2026, an unauthenticated remote code execution chain in Magento Open Source and Adobe Commerce that has been exploited in the wild since September 4 and installs a persistent backdoor.
Attackers are executing unauthenticated code on Magento and Adobe Commerce servers today, and there is no patch. Dutch e-commerce security firm Sansec published an advisory on September 5, 2026 for a flaw it calls StyleSmuggler: an unauthenticated remote code execution chain that ends in a persistent backdoor on the store server. Exploitation began on September 4. 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 still ends at the August 11 update. Sansec said it published early because stores were being compromised while it wrote.
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. The first victim it observed was running 2.4.6-p15 with Adobe's July and August 2026 security updates applied. That is the highest patch level Adobe ships for the 2.4.6 line, the one Adobe's August bulletin labels 2.4.6-2026-aug. Being fully current did not help. Sansec has not published a reproduction on Adobe Commerce or Adobe Commerce on Cloud, and Adobe has not confirmed which versions are affected, so treat those platforms as unknown rather than safe.
Patch level was not the variable
Independent confirmation came the same day from Disrex Group, a Magento hosting and development company that handled two compromised stores and a third that was attacked but not breached. Both compromised stores ran Magento Open Source, self hosted under Disrex's RexHosting brand. Store A ran 2.4.8 and was a Sansec Shield customer with the module installed, enabled, and licensed, and Shield was actively blocking other malicious traffic at the time. It was hit at 23:10 UTC on September 4, hours before Sansec's first blocking rules for this flaw shipped. Store B, not a Shield customer, ran 2.4.7-p2, a patch level Adobe's version history dates to August 2024 and eight levels behind the current 2.4.7-p10. It was first hit at 00:55 UTC on September 5.
One store was near current with a commercial WAF in front of it. The other was thirteen months stale with nothing. Both fell inside the roughly eight hour gap between the first exploitation Sansec observed and the moment any defence for this bug existed. "Patch status was irrelevant here, which is the part merchants most need to hear," Disrex told The Hacker News.
⚠️ There is no fix to apply — The only interim mitigation Sansec offers for stores without its Shield product is to temporarily disable GraphQL until Adobe releases a fix. Disrex notes that headless and progressive web app storefronts require GraphQL, while most classic and Hyva storefronts do not. Adobe's next scheduled security release is September 8, and it is not yet known whether it will cover this bug.
The implant hides in plain sight
The payload is not a PHP webshell in the web root, which is where most Magento incident response starts and stops. Sansec's indicators describe a background process disguised under the name [kworker/u:8:0], which belongs to a legitimate Linux kernel thread, running from a binary under the site user's home directory rather than anywhere served by the web server. Disrex described that binary as a stripped, statically linked Rust program of roughly 1.9 MB, built for both x86-64 and arm64.
- Binary path: ~/.local/share/.gvfsd/gvfsd-user, under the site user's home, outside the document root
- Process name: [kworker/u:8:0], mimicking a kernel thread, but with a parent that is not PID 2
- Persistence: a cron entry that restarts the process every five minutes
- Evasion detail: the cron line is written straight into the spool file under /var/spool/cron/crontabs/, so the system log records no crontab replacement
- Resilience: one store carried the identical cron line 1,728 times, and the implant re added it within a second of removal
The traffic that was not there
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 out of it. Disrex captured two packet captures while the implant was live, each over 200 MB, and neither contained a single packet to the download host or the command and control address Sansec listed. If your detection strategy for e-commerce hosts is egress based, this implant is invisible to it. The observable is local: a fake kernel thread holding dozens of loopback connections to Redis and reading customer session data.
What contained the damage
Blast radius was limited by hosting architecture, not by the attacker's restraint. Each store ran in its own isolated account with a single site owner, no sudo rights, and no path to any other customer. The implant ran as the unprivileged site user and could reach nothing beyond that store. Disrex 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, with 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. Because Disrex runs many Magento stores on its own platform, it swept the whole estate within the hour of the first finding and located the second store that afternoon. Sansec said that for Shield customers hit before its rules went live, it has no indication the backdoor was actually used, and it still recommends rotating Magento credentials wherever the process is found.
Weigh the incident response repo carefully — Disrex's public IR repository carries its own warning: it was written with AI assistance during a live incident in a few hours, it has not been reviewed, its Apache rules were never run against a live Apache server, and most of its cleanup commands were written rather than executed. Use it as leads and indicators, not as production configuration. Test any rule in staging before it touches a live storefront.
What to run before September 8
Assume compromise is possible on any internet facing Magento install regardless of version, because the first known victim was fully patched. Disable GraphQL if your storefront does not require it, hunt for the implant on the host rather than in the web root, and watch Adobe's September 8 release. Start with these read only checks on every store host.
ps -eo pid,ppid,user,comm,args | grep -F 'kworker/u:8:0'
ls -la ~/.local/share/.gvfsd/ 2>/dev/null
sudo grep -rn 'gvfsd-user' /var/spool/cron/crontabs/ 2>/dev/null
sudo grep -c 'gvfsd' /var/spool/cron/crontabs/* 2>/dev/null
grep -c 'POST /graphql' /var/log/nginx/access.log
If any of those return a hit, treat the host as compromised, preserve the binary and the cron spool file before touching them, invalidate every Magento session, and rotate admin and integration credentials. Remove the cron line before killing the process, or the five minute restart will simply bring it back.
Originally published on RedEye Threat Intelligence.
Top comments (0)