Attackers are actively exploiting a critical security hole in Magento Open Source and Adobe Commerce that allows them to execute malicious code on e-commerce servers without any login credentials, according to a security advisory published September 5 by Dutch firm Sansec. The company, which discovered the vulnerability and named it StyleSmuggler, said the campaign began September 4. As of September 6, Adobe has issued no advisory, patch, or workaround, and its security bulletin index stops at an August 11 update. A successful breach grants attackers code execution on the store's server and plants a persistent backdoor.

Sansec reports that all current versions are vulnerable, including 2.4.9, and the firm reproduced the complete unauthenticated attack chain on fresh Magento Open Source installs of versions 2.4.7, 2.4.8, and 2.4.9. The first known victim operated version 2.4.6-p15 with Adobe's July and August 2026 security patches applied—the most recent patch level Adobe provides for that release line. Disrex Group, a Magento hosting and development firm, independently confirmed exploitation after handling two compromised stores and one unsuccessful attack. Both breached stores ran Magento Open Source rather than Adobe Commerce, and both fell within roughly eight hours between the first observed exploitation and the moment any defense existed. One store ran version 2.4.8 with Sansec's Shield protection module active and licensed, but was hit at 23:10 UTC on September 4, hours before blocking rules went live. The second store ran version 2.4.7-p2, a security patch from August 2024 that's eight levels behind the current 2.4.7-p10, and was first struck at 00:55 UTC on September 5.

According to Sansec's outline, the attack unfolds in two stages: first, malicious PHP code is planted in a file that Magento itself generates, such as when creating a failure report; then, the platform is tricked into executing that file by triggering its standard "Payment Transaction Failed Reminder" email. The code runs while Magento renders the message, so no recipient needs to open it, and the attack succeeds even if email delivery fails. Disrex's analysis identifies that a directive embedded in the injected text forces a sequence of Magento's own classes into code designed solely for the command-line dependency-injection compiler, which ends by including a file path the attacker controls: the log poisoned moments earlier. The executed PHP dropper tries six PHP functions in sequence to spawn a process, then downloads and launches the implant. Disrex names three files under setup/src/Magento/Setup/Module/Di/Code/ as the endpoint of the chain. The implant disguises itself as a background process under the name [kworker/u:8:0], mimicking a Linux kernel thread, with a binary installed at ~/.local/share/.gvfsd/gvfsd-user and a cron entry restarting it every five minutes. On one store, the implant held 28 connections to the store's own Redis instance on port 6379 and read Magento's session storage from it, but made no outbound connection at all—no packets to the download host or command-and-control address Sansec listed appeared in over 200 MB of packet captures taken while the implant was live.

The report states that Sansec's interim guidance for stores not running its Shield product is to temporarily shut down GraphQL until Adobe releases a fix, though headless and progressive web app storefronts require GraphQL to function. Adobe's next scheduled security release is September 8, but it's unknown whether that will address this bug. Disrex found no evidence of data theft, no rogue admin accounts, no payment skimmers, and no database backdoors on either breached store, and both were contained the same day—roughly eleven and fourteen hours after initial contact. The firm has published unofficial mitigations including nginx and Apache rules blocking exploit parameters in URL query strings, plus a code patch adding checks to three methods in Magento's dependency-injection scanners to prevent them from running outside the command line. That patch, however, reverts with every composer install, and breaks at least one third-party admin module. Disrex advises two server settings that don't depend on knowing the chain: adding proc_open to PHP's disable_functions list, and mounting /tmp, /var/tmp, and /dev/shm with noexec so downloaded binaries can't run. Rick Bouma, Disrex's co-founder, told The Hacker News that one breach surfaced when the store emailed its owner a failed-transaction notice full of unresolved template variables—raw {{var ...}} tags, a customer address on a .invalid domain, and a total of zero—which he describes as exhaust from the exploitation attempt passing through Magento's template filter. Disrex recorded 26 distinct source addresses across its two stores, mostly a residential proxy pool sending two to six requests each, and noted that blocking the single attacker address in Sansec's advisory would have stopped less than a quarter of the traffic it observed. For many online merchants, this incident reveals a troubling reality: security posture often hinges on who discovers a vulnerability first and whether defenses ship before exploitation begins at scale. The confluence of residential proxy infrastructure and zero-day timing suggests attackers are professionalizing their approach faster than vendor patch cycles can reliably contain them.