Disclosed Flaw and Immediate Impact
Dutch e-commerce security firm Sansec disclosed a zero-day vulnerability it named StyleSmuggler on September 5, 2026, warning that unauthenticated attackers were already running remote code on Magento Open Source and Adobe Commerce installations and seizing full control of online stores. Sansec said attacks began on September 4, and that it was publishing early "because stores are being compromised right now." The bug affects every current release line, including Magento Open Source 2.4.9, and Sansec reproduced the full unauthenticated chain on clean installations of 2.4.7, 2.4.8, and 2.4.9. The first identified victim ran 2.4.6-p15 with Adobe's July and August 2026 security patches fully applied, demonstrating that fully patched stores were compromised as easily as outdated ones.
Adobe's Patch Status as of September 6
As of September 6, Adobe had not issued an advisory, assigned a CVE identifier, or released any official fix or workaround. Its Adobe Commerce security bulletin index lists nothing after the August 11, 2026 update, and Sansec has not published a reproduction against Adobe Commerce or Adobe Commerce on Cloud, with Adobe yet to confirm which versions are affected. Sansec has not stated how many stores have been compromised, and its interim advice for stores not running its Shield product is to temporarily disable GraphQL until Adobe ships a fix. Adobe's next scheduled security release is on September 8, 2026, and it is not yet known whether that release will address the flaw.
How StyleSmuggler Works
The exploit unfolds in two stages that abuse Magento's own template rendering and email systems. In the first stage, attackers plant malicious PHP code inside a file Magento writes during normal operation, such as a payment failure report, by manipulating "styles" properties within a GraphQL request to slip past existing input sanitization. Independent analysis from Magento hosting firm Disrex Group, which responded to two compromised stores, found that a crafted directive inside the injected text forces Magento's own classes to execute code meant only for the command-line dependency-injection compiler, including the attacker-poisoned log file. The second stage triggers execution: StyleSmuggler causes Magento to send its standard "Payment Transaction Failed Reminder" email, and the poisoned code runs the moment Magento renders that message internally, requiring no one to open or receive the email.
Independent Confirmation and Implant Behavior
Disrex Group published its own incident-response repository on September 5, documenting two breached stores and a third attacked but not breached, and stated that its web-server rules are based on attack traffic captured on one compromised store. Disrex told The Hacker News that both breached stores ran Magento Open Source rather than Adobe Commerce and are hosted through its RexHosting brand, with Store A on 2.4.8 and a Sansec Shield customer hit at 23:10 UTC on September 4, and Store B on 2.4.7-p2 first hit at 00:55 UTC on September 5. Once triggered, a PHP dropper cycles through six PHP functions to spawn a process, then downloads a persistent implant that Disrex described as a roughly 1.9-megabyte statically linked Rust binary built for both x86-64 and ARM64, disguised as a Linux kernel thread named "[kworker/u:8:0]" and restarted every five minutes via a cron entry written into the crontab spool file to avoid leaving normal system logs.
Detection Challenges and Defensive Caveats
Detecting an infection is complicated because the implant evades naive checks, with a legitimate Linux kernel worker thread owned by root and consuming no resident memory, so any bracketed "[kworker]" process running under a website's user account with real memory usage warrants investigation. Disrex also found that the in-memory binary sometimes differs from the on-disk file, recommending that defenders hash both. The Disrex repository carries its own warning that it was written with AI assistance during a live incident in a few hours, has not been reviewed, that its Apache rules were never run against a live Apache server, and that most of its cleanup commands were written rather than executed. Disrex characterized the gap as roughly eight hours between the first exploitation Sansec observed and any defense for it, adding: "Patch status was irrelevant here, which is the part merchants most need to hear."
Share this article
