Critical RCE Flaw in Adobe Commerce, Magento Under Active Attack
Key Takeaways A critical zero-day vulnerability, dubbed “StyleSmuggler,” is under active exploitation in Adobe Commerce and Magento Open Source. The flaw allows unauthenticated remote...
Key Takeaways
- A critical zero-day vulnerability, dubbed “StyleSmuggler,” is under active exploitation in Adobe Commerce and Magento Open Source.
- The flaw allows unauthenticated remote code execution (RCE), giving attackers full control over affected online stores.
- All current versions, including the latest 2.4.9, are vulnerable, with exploits observed even on fully patched systems.
- As of early September 2026, no official patch or CVE identifier has been released by Adobe.
Online retailers utilizing Adobe Commerce and Magento Open Source are facing an urgent threat from a newly discovered zero-day vulnerability. Dubbed “StyleSmuggler” by Dutch e-commerce security firm Sansec, this critical flaw allows unauthenticated attackers to achieve remote code execution (RCE) and seize complete control of affected storefronts. Disturbingly, active exploitation began on September 4, 2026, with public disclosure by Sansec following on September 5, even as a definitive patch remains unavailable.
Table Of Content
Sansec made the unusual decision to publish its initial findings prematurely due to the immediate and ongoing threat to live stores. The firm emphasized that its full technical analysis was still underway, but the urgency of active compromises necessitated early public awareness.
The StyleSmuggler vulnerability impacts every current iteration of Magento and Adobe Commerce, including the very latest 2.4.9 release. Crucially, successful exploitation requires no prior authentication, making it a severe risk. Sansec successfully replicated the entire unauthenticated attack chain across clean installations of Magento Open Source versions 2.4.7, 2.4.8, and 2.4.9, confirming the flaw’s broad applicability and independence from specific outdated builds.
In a particularly alarming development, the first identified victim was running version 2.4.6-p15, with all security patches from July and August 2026 fully applied. This indicates that even diligently maintained and updated stores are just as susceptible to compromise as those with neglected security postures.
As of September 6, Adobe had not yet issued an official security advisory, assigned a CVE identifier, or released any fix or workaround. The company’s most recent Commerce security bulletin at that time dated back to August 11.
Understanding the Attack Chain
The StyleSmuggler exploit operates in two distinct phases, cleverly abusing Magento’s inherent template rendering and email systems rather than relying on a singular, obvious injection point.
Stage One: Malicious Code Injection
In the initial stage, attackers embed malicious PHP code within a file that Magento itself generates during normal operations, such as a payment failure report. This is achieved by manipulating “styles” properties within a GraphQL request, effectively bypassing existing input sanitization mechanisms.
Independent analysis from Magento hosting provider Disrex Group, which assisted two breached stores, revealed that a specially crafted directive within the injected text compels a series of Magento’s own classes to execute code. This code, originally intended only for command-line dependency-injection compiler operations, ultimately includes the attacker-poisoned log file. Disrex also discovered that this technique abuses how Magento processes certain directives, leading to unexpected code execution.
Stage Two: Execution and Persistence
The second stage triggers the execution of the injected code. Sansec found that StyleSmuggler intentionally prompts Magento to dispatch its standard “Payment Transaction Failed Reminder” email. The poisoned code then runs the moment Magento internally renders this message. This means the attack succeeds without anyone needing to open or even receive the email, making it particularly insidious.
Once triggered, a PHP dropper initiates a process that cycles through six different PHP functions until it identifies one capable of spawning a new process. It then downloads and launches a persistent implant. Disrex described this malware as a compact, statically linked Rust binary, approximately 1.9 megabytes in size, compiled for both x86-64 and ARM64 architectures. The implant masquerades as a Linux kernel thread named “[kworker/u:8:0]” and ensures its persistence by creating a cron entry directly within the crontab spool file, thereby avoiding standard system logs and restarting itself every five minutes.
Detection Challenges and Mitigation Efforts
Detecting an infection proves challenging due to the malware’s active evasion techniques. A legitimate Linux kernel worker thread typically runs under the root user and consumes minimal resident memory. Therefore, any bracketed “[kworker]” process operating under a website’s user account and exhibiting actual memory usage should be considered a significant red flag.
Disrex also discovered that the binary actively running in memory sometimes differs from the file stored on disk. This necessitates that defenders hash both the on-disk file and the live process for a thorough forensic analysis.
In one observed compromise, the implant made no outbound internet connections. Instead, it established 28 concurrent connections to the site’s own Redis instance to read live Magento session data. This tactic allowed it to operate almost entirely invisibly to network-based monitoring tools.
Sansec’s own detection guidance recommends searching Magento’s var/report directory for a specific marker string. However, Disrex found that both of the breached stores it handled were actually compromised via var/log/system.log. This highlights the need for administrators to check both locations for signs of infection.
With Adobe’s next scheduled security release slated for September 8, and no confirmation that it will address this specific flaw, store owners are currently reliant on interim measures. Sansec advises temporarily disabling GraphQL entirely for stores that do not utilize headless or progressive web app storefronts, as classic and Hyvä themes generally do not require it.
Several entities, including Disrex, security researcher ProxiBlue, and vendor Graycore, have independently published unofficial code patches. These patches aim to harden specific Magento classes and email template functions. However, all three stress that these are hardening measures, not a complete fix. Disrex specifically cautioned that its rules only block the current attack traffic pattern, not the underlying vulnerability itself.
Server-level protections, which do not rely on a deep understanding of the exploit chain, have also proven effective in preventing the dropper from launching its payload. Examples include disabling PHP’s proc_open function and mounting temporary directories with the noexec option.
What You Should Do
- Disable GraphQL: If your store does not use headless or progressive web app storefronts, temporarily disable GraphQL entirely.
- Apply Unofficial Patches: Consider applying unofficial code patches released by Disrex, ProxiBlue, or Graycore, understanding they are hardening measures, not a full fix.
- Implement Server-Level Protections: Disable PHP’s
proc_openfunction and mount temporary directories with thenoexecoption to prevent payload execution. - Monitor for Suspicious Processes: Look for “[kworker]” processes running under the website’s user account with resident memory usage, as legitimate kernel workers run as root with minimal memory.
- Inspect Log Files: Thoroughly check both
var/reportandvar/log/system.logdirectories for signs of malicious injection. - Hash Files and Processes: For any suspicious files, hash both the on-disk binary and the live process in memory for discrepancies.
- Stay Vigilant: Monitor official Adobe channels for emergency security advisories and the eventual release of an official patch.
Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.



No Comment! Be the first one.