Online stores running Magento Open Source and Adobe Commerce are being broken into through a security flaw that has no patch, no CVE number and, as of Saturday, no acknowledgment from Adobe. The company that found it says it went public before finishing its own investigation because merchants were already getting hit while it worked.
Dutch e-commerce security firm Sansec disclosed the vulnerability on September 5 and named it StyleSmuggler, saying it was releasing details early "because stores are being compromised right now." Sansec traces the first attacks to September 4, a day before it went public.
The flaw lets an attacker run code on a store's server with no login at all. Sansec says it reproduced the entire chain on clean installs of Magento Open Source 2.4.7, 2.4.8 and 2.4.9, and that every currently supported version is exposed. The first store it observed getting hit was running 2.4.6-p15, fully caught up on Adobe's July and August updates, the highest patch level Adobe offers that release line. Being current did not save it.
Adobe has said nothing so far. Its Commerce security bulletin index still shows August 11 as the latest entry, with no advisory, CVE or workaround. Its next scheduled security release lands September 8, though whether that covers this bug is unknown. Sansec has not tested the exploit against Adobe Commerce or Adobe Commerce on Cloud specifically, so those platforms remain unconfirmed rather than cleared.
Independent confirmation
Magento hosting firm Disrex Group backed up the account within a day, saying it handled two customers that were actually breached and a third that was targeted but held. One breached store was running a patch level Adobe issued back in August 2024, eight versions behind current, and was hit hours before Sansec's first blocking rules went live. Disrex posted its findings and cleanup tools to GitHub the same day, along with an unusually blunt disclaimer: the material was assembled with AI help during a live incident in a few hours, has not been peer reviewed, and some of its own commands were never actually tested against a running server.
How it works
Sansec says the attack abuses "styles properties" inside Magento's template engine to dodge normal safeguards, in two stages. First, it plants PHP code somewhere Magento itself writes, such as a failure log. Second, it triggers Magento's standard "Payment Transaction Failed Reminder" email, and the planted code runs the moment Magento builds that message internally. Nobody has to open the email, and the attack still works even if delivery fails.
Disrex's own analysis, published separately, suggests a crafted directive pushes Magento's internal classes into running code meant only for its command-line compiler tool, which then loads the very file poisoned in stage one. A dropper cycles through six system functions until one launches a process, then fetches the final backdoor. Neither Sansec nor Adobe has confirmed that specific mechanism.
Once installed, the backdoor disguises itself as a kernel process named [kworker/u:8:0] and hides its binary in the site user's home directory rather than the web root, with a cron job rewriting itself every five minutes in a way that dodges typical crontab logging. On one victim it read session data straight out of the store's own Redis database rather than contacting outside infrastructure; on another it reached command-and-control servers matching Sansec's published indicators.
No fix yet
With Adobe silent, defenses are all third-party stopgaps. Sansec recommends disabling GraphQL entirely unless a store runs its Shield product, though that breaks headless and progressive-web-app storefronts. Disrex, a developer known as ProxiBlue, and a firm called Graycore have each released community patches or firewall rules targeting different points in the chain, but all three call their own work partial hardening, not a real fix. Disrex also found attackers could dodge its firewall rule simply by moving parameters into a POST body.
Two settings that don't depend on understanding the exploit at all: disabling the PHP function proc_open, which one dropper used after other functions were already blocked, and mounting temporary directories with the noexec flag so a downloaded binary cannot run. For stores already compromised, guidance calls for preserving evidence first, killing the process before removing its cron job, never rebooting since the only surviving copy of the binary may live only in memory, and rotating every credential in the store's environment file rather than trusting a scan alone. One security firm's own detection scanner reportedly missed the backdoor entirely on a store where it was actively running.
Two hosting providers said this week they were reviewing their environments as a precaution, though neither has confirmed a breach. No group has been tied to the campaign, and the number of affected stores overall is still unknown.
