- 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.
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.
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.logIf 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.
Fix It Yourself
Everything above is what happened. This is what to run. The check commands change nothing.
Check whether you are exposed
Print the exact Magento version and patch level, and confirm whether the GraphQL endpoint answers publicly
php bin/magento --version; curl -s -o /dev/null -w 'graphql HTTP %{http_code}\n' -X POST -H 'Content-Type: application/json' -d '{"query":"{__typename}"}' https://store.example.com/graphqlHunt the implant: fake kernel thread with a non kernel parent, the binary path, and the cron persistence line
ps -eo pid,ppid,user,comm,args | grep -F 'kworker/u:8:0'; ls -la /home/*/.local/share/.gvfsd/ 2>/dev/null; sudo grep -rn 'gvfsd-user' /var/spool/cron/crontabs/ 2>/dev/nullCount local Redis clients and read which Redis database Magento uses for sessions, both read only
redis-cli -h 127.0.0.1 -p 6379 CLIENT LIST | wc -l; grep -A12 "'session'" app/etc/env.phpClose it
No vendor patch exists yet, so contain instead: stage an nginx snippet that returns 403 on /graphql, then include it in your server block and reload only if your storefront is classic or Hyva
sudo cp -a /etc/nginx /etc/nginx.bak.$(date +%F); printf 'location /graphql { return 403; }\n' | sudo tee /etc/nginx/snippets/block-graphql.conf; sudo nginx -tQuarantine a confirmed implant: back up the cron spool, strip the persistence line first, then kill the process and move the binary aside rather than deleting it
sudo cp /var/spool/cron/crontabs/SITEUSER /root/crontab.SITEUSER.$(date +%s).bak; sudo sed -i '/gvfsd-user/d' /var/spool/cron/crontabs/SITEUSER; sudo pkill -f gvfsd-user; sudo mv /home/SITEUSER/.local/share/.gvfsd /root/quarantine-gvfsd-$(date +%s)Invalidate every Magento session after containment, since the implant read session storage out of Redis; this logs out all admins and shoppers, so confirm the database number from env.php first
redis-cli -h 127.0.0.1 -p 6379 -n SESSION_DB_NUMBER DBSIZE; echo 'confirm the count above matches your session store, then run: redis-cli -h 127.0.0.1 -p 6379 -n SESSION_DB_NUMBER FLUSHDB'Prompts for the agent you already run
Paste this on any host running Magento Open Source or Adobe Commerce to triage for StyleSmuggler before you touch anything
Paste this when deciding whether you can safely turn GraphQL off, which is the only mitigation available until Adobe ships a fix
What to alert on
The single best observable is process lineage. Alert on any process whose comm or cmdline matches 'kworker/u:8:0' but whose PPID is not 2, since genuine kernel worker threads are always children of kthreadd; in auditd this is the execve record's exe and ppid fields, and in EDR telemetry it is the process create event's parent process ID paired with the process name. Pair that with a file integrity or auditd watch on /var/spool/cron/crontabs/ for write events by any non root user, because the implant writes its five minute restart line directly into the spool file and never invokes crontab, so the usual CRON EDIT syslog line never appears. Two supporting signals close the gap: journald or /var/log/syslog CRON entries firing for the site user on an exact five minute cadence with no matching change record, and Redis CLIENT LIST or the slowlog showing dozens of persistent loopback connections on port 6379 from a process that is not php-fpm. Do not rely on egress or netflow detection here, because on one confirmed victim the implant made no outbound connection at all across two packet captures of over 200 MB each.
Questions about your exposure?
RedEye Security provides assessments for organizations that need to understand their real risk.
Talk to us