"Sansec is publishing early because stores are being compromised right now," the Dutch e‑commerce security company wrote on September 5 after disclosing a newly discovered unpatched zero‑day it calls StyleSmuggler.
What Sansec found and what Adobe has not yet done
Sansec said attacks began on September 4 and published an advisory on September 5 describing an unauthenticated chain that gives attackers remote code execution and installs a persistent backdoor on Magento Open Source and Adobe Commerce stores. As of September 6, Adobe had not published an advisory, assigned a CVE identifier, issued a patch, or supplied a workaround; Adobe's Adobe Commerce security bulletin index lists nothing after the August 11 update. 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. Adobe's next scheduled security release, Sansec noted, is September 8; it was not yet known whether that release would cover this bug.
How the exploit chain operates and how the implant behaves
Sansec describes the two‑stage attack as first planting PHP code in a file Magento writes (for example when generating a failure report), then forcing Magento to execute that file by triggering the platform's standard "Payment Transaction Failed Reminder" email. The code runs while Magento renders the message, so the attack can succeed even if email delivery fails. Sansec has not published the full exploit chain but said a breakdown of the chain, the dropper, and the implant will follow.
Disrex Group — a Magento hosting and development firm that responded to compromised stores — published its own mechanism readout. Disrex said the chain drives Magento's dependency‑injection compiler to include a file the attacker chose, with the PHP dropper attempting six functions in turn to start a process and then downloading and launching a native implant. Disrex named three files under setup/src/Magento/Setup/Module/Di/Code/ as where the chain ends, though Sansec has not confirmed that detail.
Sansec and Disrex describe the implant as a background process masquerading as a kernel thread named [kworker/u:8:0], with a binary installed at ~/.local/share/.gvfsd/gvfsd-user and a cron entry restarting it every five minutes by writing straight to /var/spool/cron/crontabs/. Disrex described the binary as a stripped, statically linked Rust program of roughly 1.9 MB built for x86‑64 and arm64. In at least one case the implant made no outbound connections and instead opened 28 local connections to Redis to read Magento session storage.
Audit-ready is a season. It shouldn't be.
Evidence in spreadsheets, controls drifting between audits, frameworks multiplying on flat headcount. Nubivance runs continuous compliance on Rapid7 Cyber GRC - SOC 2, HIPAA, ISO 27001, PCI, CMMC.
End the scrambleIndicators, detection and the mixed results of scanning
Sansec and Disrex published indicators that include process and file names, cron entries, three SHA‑256 hashes, a malware download domain (247.cdnflare[.]xyz), and observed IPs and ports (including 99.84.67[.]186:443 as command‑and‑control over WebSocket and TLS, per Sansec). Sansec recommended its eComscan scanner to detect the implant and said version 1.9.7 will terminate the process for Shield customers. Disrex reported a counterexample: eComscan ran with background‑process and scheduled‑task checks enabled on one infected store while the implant was live and reported the store clean. Disrex did not specify the eComscan version used.
Community mitigations and server hardening options
There is no vendor fix at the time of the publications. Sansec's interim advice for stores not running its Shield product is to disable GraphQL until Adobe issues a temporary fix; Disrex notes headless and PWA storefronts require GraphQL while most classic and Hyvä storefronts do not. Community responses include nginx and Apache request rules from Disrex that block exploit parameters in URL query strings (which Disrex found can be bypassed via POST or JSON bodies), a composer‑patch guard that prevents certain dependency‑injection scanners from running outside the command line (distributed by Disrex and mirrored by ProxiBlue), and a Graycore Magento module that hardens three points on the chain.
Disrex also recommended two server settings that do not depend on the chain: adding proc_open to PHP's disable_functions and mounting /tmp, /var/tmp and /dev/shm with noexec so a downloaded binary cannot run. Disrex cautioned that one of its code guards breaks an admin screen in mageplaza/module-admin-permissions and that hand edits are reverted by composer install, so it publishes the change as a composer patch.
How technologists, hosting providers, and merchants are responding
- Technologists and security teams: search both var/report/ and var/log/system.log for injected markers, check for a non‑root process named like [kworker/u:8:0] that has real memory usage, hash running binaries from /proc/<pid>/exe as well as on‑disk files, and consider disabling GraphQL or applying the community hardening patches Sansec and Disrex describe.
- Hosting providers and responders: Nexcess and Liquid Web posted identical incident notices on September 5 saying they were reviewing server environments and implementing precautionary measures; Disrex recorded 26 distinct source addresses across its two stores and warned that blocking a single address would have stopped less than a quarter of the observed traffic.
- Merchants and incident responders handling infected stores: preserve evidence first, remove the cron entry before killing the process because it re‑installs itself, avoid rebooting, do not run composer install (it can overwrite forensic timestamps), flush session storage, and rotate app/etc/env.php crypt/key, every admin password, and every payment provider API key and integration credential referenced there.
Sansec plans a fuller technical breakdown; Adobe's September 8 security release is the next named milestone to watch to see whether a vendor patch arrives. In the absence of an official fix, stores face a narrow window to detect and harden against a live, reproducible zero‑day that researchers say is already in use.
