Attackers are actively exploiting a newly discovered vulnerability in Magento Open Source and Adobe Commerce that can allow them to run malicious code on an online store’s server without authentication.
Dutch e-commerce security company Sansec discovered the flaw, named it StyleSmuggler, and warned that stores were already being compromised when it published its advisory on September 5.
As of September 6, Adobe had not released a security advisory, CVE identifier, patch, or workaround for the vulnerability. Adobe’s Magento security bulletin index also had no newer update beyond its August 11 release. Sansec said all current Magento Open Source versions are affected, including version 2.4.9, and confirmed the complete unauthenticated attack chain on clean installations of versions 2.4.7, 2.4.8, and 2.4.9.
The company said its first known victim was running Magento 2.4.6-p15 with Adobe’s July and August 2026 security updates installed. That was the latest patch level Adobe offered for that release line. However, Sansec has not reproduced the vulnerability on Adobe Commerce or Adobe Commerce on Cloud, and Adobe has not confirmed which versions of those products are affected. The number of compromised stores is also unknown.
For stores that do not use Sansec’s Shield product, the researchers’ temporary recommendation is to disable GraphQL until Adobe releases an official fix. That can be difficult for some modern Magento deployments because headless and progressive web app storefronts rely on GraphQL, while most traditional and Hyvä storefronts do not.
Adobe’s next scheduled security release is September 8, although Sansec said it is not yet known whether that release will address the StyleSmuggler vulnerability.
Independent evidence of active exploitation has also come from Disrex Group, a Magento hosting and development company that responded to two compromised stores. The company said it handled two breached stores and another that was attacked but was not compromised. Its investigation and mitigation rules were based on attack traffic captured from one of the affected stores. Both compromised sites were running Magento Open Source rather than Adobe Commerce.
One of the stores, identified as Store A, was running Magento Open Source 2.4.8 and was also a Sansec Shield customer. It was attacked at 23:10 UTC on September 4, before Sansec’s first blocking rules for the vulnerability were available. Disrex said Shield was active and blocking other malicious traffic against the store at the time.
Store B was running Magento 2.4.7-p2 and was not a Shield customer. Disrex said the store was first attacked at 00:55 UTC on September 5. The company used this compromise to analyze the vulnerable code and develop its web-server rules.
According to Disrex, both stores were compromised during the roughly eight-hour period between the first exploitation observed by Sansec and the availability of defenses. The company emphasized that the normal patch status of the stores did not prevent the attacks, making the absence of an official fix particularly concerning.
The malware installed during the attack is designed to remain on the compromised server. Sansec identified a background process disguised as the Linux kernel thread name [kworker/u:8:0]. The malicious binary is placed under ~/.local/share/.gvfsd/gvfsd-user, outside the website’s normal document root, while a cron job attempts to restart it every five minutes.
Disrex described the malware as a stripped and statically linked Rust program of about 1.9MB, built for both x86-64 and arm64 systems. The company also found that the cron entry could be written directly into the cron spool file, allowing the malware to avoid the usual system logging associated with replacing a user’s crontab.
In one case, the same malicious cron entry appeared 1,728 times and was restored within a second after being removed. Interestingly, Disrex said the malware on one store made no outbound network connections. Instead, it maintained 28 connections to the store’s own Redis service on port 6379 and read Magento session data from it. Packet captures taken while the malware was running showed no traffic to the download server or command-and-control address identified by Sansec.
Disrex said the affected stores were isolated accounts with a single site owner and no sudo access. The malware was running as the unprivileged site user and could not reach other customers. The company found no evidence of lateral movement or additional affected sites on its platform. Both compromised stores were contained on the same day, and the investigation found no evidence of data theft, unauthorized administrator accounts, payment skimmers, or database backdoors. Sessions were invalidated and credentials were being rotated as a precaution.
Sansec said the attack happens in two stages. First, attackers inject PHP code into a file that Magento writes itself, such as a file created during a failure report. They then trigger Magento’s standard “Payment Transaction Failed Reminder” email, causing the platform to execute the injected file while rendering the message. The attack does not require anyone to open the email, and it can reportedly succeed even when the email itself fails to reach its destination.
Sansec has not yet released the complete exploit chain and said it will provide more details about the attack chain, dropper, and implant in a future update. Disrex’s independent analysis suggests the injected content abuses Magento classes intended for the command-line dependency-injection compiler, eventually causing Magento to include a file chosen by the attacker.
The initial malicious code can appear in more than one location. Sansec’s detection checks var/report/ for the marker X_TRACE_, but Disrex said both of its compromised stores had been infected through var/log/system.log instead. The company therefore recommends checking both directories. The marker itself also changed during the campaign, meaning defenders should look for the general pattern rather than relying on one exact string.
Disrex said a TypeError involving array_merge() and an integer in system.log immediately after the suspicious include can indicate a successful exploit. However, attackers can use a quieter variation that returns an empty array and leaves no obvious error in the log. The company also warned that a process using the [kworker/u:8:0] name should be investigated when it belongs to a regular site user and consumes memory, since genuine kernel threads are owned by root and do not behave this way.
The investigation also found that the binary running in memory on one store was different from the copy stored on disk. Disrex therefore recommends checking the hash of the running executable through /proc/<pid>/exe as well as checking the file itself. A sudden increase in “Payment Transaction Failed Reminder” emails can also be a warning sign, although legitimate failed payments can produce the same messages.
Sansec and Disrex have published several indicators of compromise, including the suspicious [kworker/u:8:0] process, malicious files under .local/share/.gvfsd, temporary files under /tmp, recurring cron entries, several SHA-256 hashes, and infrastructure associated with the campaign.
Sansec recommends using its eComscan scanner to look for the implant and said version 1.9.7 can terminate the process for Shield customers. However, Disrex found that an eComscan scan of Store A initially reported a clean result because the scheduled scan only covered the website’s document root while the malware had been installed one directory above it in the account’s home directory. Disrex has since widened its scan path.
There is currently no official vendor fix to install. Until Adobe releases one, Sansec’s temporary GraphQL shutdown remains an option, while unofficial mitigations have also been published by Disrex, ProxiBlue, and Graycore. Disrex has also recommended server-level protections that do not depend on understanding the complete vulnerability chain.
Disrex published nginx and Apache rules designed to block requests containing the parameters used in the current attacks. However, the company warned that these rules are not a complete fix because the same parameters can be delivered through POST or JSON request bodies, which may still reach PHP. The rules are intended to stop the campaign as it is currently being observed rather than eliminate the underlying vulnerability.
Another mitigation modifies three Magento dependency-injection scanner methods so they cannot run outside the command line. Disrex said the manual change is overwritten by Composer installations, so it also published a Composer patch that can be reapplied during deployment. However, the company warned that one of the affected files is used over HTTP by at least one third-party Magento module, meaning the protection can break that module’s admin functionality.
Graycore has also released a Magento module that hardens several points in the suspected attack chain. The company has warned that its protection is hardening rather than a complete fix and that other paths through the vulnerability may remain open. It also warns that a store could already be compromised before the mitigation is installed.
Disrex recommends two additional server-level protections that do not depend on identifying the exact exploit chain. The first is disabling proc_open through PHP’s disable_functions, while the second is mounting /tmp, /var/tmp, and /dev/shm with noexec so downloaded binaries cannot be executed.
For stores that may already be infected, Disrex says administrators should preserve evidence before beginning cleanup. The company recommends removing the malicious cron entry before killing the process because the malware can restore it, avoiding a reboot because the executable may only remain available through /proc, and avoiding Composer installations during cleanup because they can overwrite timestamps that may help investigators determine what was modified.
Disrex also recommends flushing session storage because the malware accessed it and rotating the Magento crypt/key stored in app/etc/env.php. Administrators should also rotate administrator passwords, payment provider API keys, and other integration credentials contained in that file.
If this article helped you, please consider supporting our work. Every small contribution keeps Abijita.com independent and running.
Hosting providers Nexcess and Liquid Web posted incident notices on September 5 saying they were reviewing their server environments and applying precautionary measures. Neither provider reported a confirmed customer compromise or its own reproduction of the vulnerability.
Disrex recorded 26 unique source addresses attacking its two compromised stores. The company said two were hosting infrastructure sending requests in bulk, while the rest appeared to be part of a residential proxy pool. Blocking the single attacker address listed in Sansec’s advisory would have stopped less than a quarter of the traffic Disrex observed. The attackers have not yet been identified.
(via: https://thehackernews.com/2026/09/unpatched-magento-and-adobe-commerce.html)
Magento Zero-Day Under Active Attack With No Patch Available
