A newly discovered zero-day vulnerability in Magento Open Source and Adobe Commerce is being actively exploited by attackers to seize full control of online stores, and there is still no official patch available.
Dutch e-commerce security firm Sansec disclosed the flaw, dubbed StyleSmuggler, on September 5, 2026, warning that unauthenticated attackers can achieve remote code execution on vulnerable installations and that live attacks began the previous day .
The company said it was publishing its findings early, before completing its full technical analysis, “because stores are being compromised right now”.
StyleSmuggler affects every current version of Magento and Adobe Commerce, including the latest 2.4.9 release, and requires no authentication whatsoever to exploit.
Sansec reproduced the complete unauthenticated attack chain on clean installations of Magento Open Source 2.4.7, 2.4.8, and 2.4.9, confirming the bug is not tied to any single outdated build.
Disturbingly, the first identified victim was running 2.4.6-p15 with July and August 2026 security patches fully applied, meaning fully patched stores were compromised just as easily as neglected ones.
As of September 6, Adobe has not issued an advisory, assigned a CVE identifier, or released any official fix or workaround, and the company’s most recent Commerce security bulletin still dates to August 11.
The exploit unfolds in two distinct stages that abuse Magento’s own template rendering and email systems rather than a single obvious injection point. In the first stage, attackers plant malicious PHP code inside a file that Magento itself writes during normal operation, such as a payment failure report, by manipulating “styles” properties within a GraphQL request to slip past existing input sanitization.
Magento and Adobe Commerce 0-Day RCE
Independent analysis from Magento hosting firm Disrex Group, which handled two breached stores, found that a crafted directive inside the injected text forces a chain of Magento’s own classes to execute code that was only ever meant to run through the command-line dependency-injection compiler, ultimately including the attacker-poisoned log file.
The second stage triggers execution. Sansec found that StyleSmuggler deliberately causes Magento to send its standard “Payment Transaction Failed Reminder” email, and the poisoned code runs the moment Magento renders that message internally, meaning nobody has to open or even receive the email for the attack to succeed.
Once triggered, a PHP dropper cycles through six different PHP functions until it finds one capable of spawning a process, then downloads and launches a persistent implant. Disrex described the malware as a small, statically linked Rust binary of roughly 1.9 megabytes, compiled for both x86-64 and ARM64 architectures, disguised as a Linux kernel thread named “[kworker/u:8:0]” and restarted every five minutes through a cron entry written directly into the crontab spool file to avoid leaving normal system logs.
Detecting an infection is harder than it sounds because the malware actively evades naive checks. A genuine Linux kernel worker thread is owned by root and consumes no resident memory, so any bracketed “[kworker]” process running under a website’s own user account with real memory usage is a red flag.
Disrex also discovered that the binary running in memory sometimes differs from the file sitting on disk, meaning defenders should hash both the file and the live process to be thorough.
On one compromised store, the implant made no outbound internet connections at all, instead opening 28 simultaneous connections to the site’s own Redis instance to read live Magento session data, which let it operate almost invisibly to network-based monitoring.
Sansec’s own detection guidance searches Magento’s var/report directory for a marker string, but Disrex found both of its breached stores were actually poisoned through var/log/system.log instead, meaning administrators need to check both locations.
With Adobe’s next scheduled security release set for September 8 and no confirmation it will address this flaw, store owners are left relying on stopgap measures. Sansec recommends temporarily disabling GraphQL entirely for stores that don’t rely on headless or progressive web app storefronts, since classic and Hyvä themes generally don’t need it.
Disrex, security researcher ProxiBlue, and vendor Graycore have each independently published unofficial code patches that guard specific Magento classes and email template functions, though all three stress these are hardening measures rather than a genuine fix, and Disrex specifically warns its rules only block the current attack traffic pattern, not the underlying vulnerability.
Server-level protections that don’t depend on understanding the exploit chain at all, such as disabling PHP’s proc_open function and mounting temporary directories with noexec, have also proven effective at stopping the dropper from launching its payload.
Learn 7 Metric-Gated AI SOC Deployment Phases – Download Free AI SOC Deployment Playbook 2026.
