Online stores built on Magento and Adobe Commerce have been under attack since Friday through a flaw that Adobe had no fix for. That changed late on Monday, when the company published an emergency hotfix and gave the bug the highest severity score available. By then attackers had enjoyed a three day head start, and stores with every previous patch installed had been broken into.
The vulnerability was found by Sansec, a Dutch company that specializes in the security of online shops, which named it StyleSmuggler and went public on Saturday without waiting for a patch. Its reasoning was blunt: stores were being compromised as it wrote. Adobe now tracks the flaw as CVE-2026-75650 and rates it 10.0 out of 10.
An email nobody has to open
StyleSmuggler lets someone with no account run their own code on the server behind a store. It abuses Magento's template system, and it works in two steps. First the attacker gets a snippet of PHP written into a file that Magento creates on its own, for instance when it logs a failure report. Then they make Magento process that file by triggering one of its standard messages, the reminder email sent when a payment transaction fails.
The injected code runs while the platform is putting that email together. Nobody needs to read the message, and the attack succeeds even if the email is never delivered.
Keeping up with updates offered no protection. The first victim Sansec saw had installed both the July and the August security updates from Adobe, and the company reproduced the complete attack on clean installations of Magento Open Source 2.4.7, 2.4.8 and 2.4.9.
A backdoor dressed up as a system process
On the stores that were hit, the attackers installed a small backdoor written in Rust. It runs in the background under the site's own user account and hides behind names that an administrator would expect to see on any Linux machine. Early builds called themselves [kworker/u:8:0], which looks like a kernel worker thread. Builds from September 6 switched to fc-cache, the name of a common font utility. A scheduled job restarts the program if it stops.
The newer builds also disguise their communication. They send UDP packets to port 123, the port used for network time synchronization, and the servers they talk to have names that resemble time servers. To a firewall the traffic looks like a machine checking its clock.
Sansec says it has seen no sign so far that the backdoor has been used for anything worse. That guarantees little. Code execution on a store's server puts customer records, administrator accounts and the payment flow within reach, and the people behind this have been changing their payloads several times a day.
What store owners need to do
Adobe's fix arrived as a hotfix that is applied as a composer patch, not as a full release. It carries the company's highest priority rating. Adobe tested it against the August 2026 releases of the supported 2.4 branches. Older releases in those branches are affected as well, though the patch is unverified there, and versions that are out of support get nothing.
Applying the patch stops new break ins. It does nothing about a backdoor that is already running, so every store that was exposed over the weekend needs to be checked. Sansec recommends looking for the following:
- Background processes named
kworkerorfc-cachethat belong to the website's user account. - Cron entries the site's owner did not create.
- A sudden run of failed payment reminder emails.
- PHP code inside Magento's own report or log files under
var.
Adobe also advises rotating the store's encryption key and every secret it protected. That means administrator passwords, integration tokens, OAuth client secrets, payment gateway credentials, database passwords and SSH keys, changed at their source and not only inside Magento. For stores that cannot patch immediately, Sansec's stopgap is to switch off GraphQL, with the caveat that headless storefronts depend on it.
