Threat actors are exploiting a newly found zero-day flaw in Magento Open Source and Adobe Commerce to install persistent backdoors and compr...
Online stores running Magento Open Source and Adobe Commerce are being broken into through a security flaw that has no patch, no CVE number and, as of Saturday, no acknowledgment from Adobe. The company that found it says it went public before finishing its own investigation because merchants were already getting hit while it worked.
Dutch e-commerce security firm Sansec disclosed the vulnerability on September 5 and named it StyleSmuggler, saying it was releasing details early "because stores are being compromised right now." Sansec traces the first attacks to September 4, a day before it went public.
The flaw lets an attacker run code on a store's server with no login at all. Sansec says it reproduced the entire chain on clean installs of Magento Open Source 2.4.7, 2.4.8 and 2.4.9, and that every currently supported version is exposed. The first store it observed getting hit was running 2.4.6-p15, fully caught up on Adobe's July and August updates, the highest patch level Adobe offers that release line. Being current did not save it.
Adobe has said nothing so far. Its Commerce security bulletin index still shows August 11 as the latest entry, with no advisory, CVE or workaround. Its next scheduled security release lands September 8, though whether that covers this bug is unknown. Sansec has not tested the exploit against Adobe Commerce or Adobe Commerce on Cloud specifically, so those platforms remain unconfirmed rather than cleared.
Independent confirmation
Magento hosting firm Disrex Group backed up the account within a day, saying it handled two customers that were actually breached and a third that was targeted but held. One breached store was running a patch level Adobe issued back in August 2024, eight versions behind current, and was hit hours before Sansec's first blocking rules went live. Disrex posted its findings and cleanup tools to GitHub the same day, along with an unusually blunt disclaimer: the material was assembled with AI help during a live incident in a few hours, has not been peer reviewed, and some of its own commands were never actually tested against a running server.
How it works
Sansec says the attack abuses "styles properties" inside Magento's template engine to dodge normal safeguards, in two stages. First, it plants PHP code somewhere Magento itself writes, such as a failure log. Second, it triggers Magento's standard "Payment Transaction Failed Reminder" email, and the planted code runs the moment Magento builds that message internally. Nobody has to open the email, and the attack still works even if delivery fails.
Disrex's own analysis, published separately, suggests a crafted directive pushes Magento's internal classes into running code meant only for its command-line compiler tool, which then loads the very file poisoned in stage one. A dropper cycles through six system functions until one launches a process, then fetches the final backdoor. Neither Sansec nor Adobe has confirmed that specific mechanism.
Once installed, the backdoor disguises itself as a kernel process named [kworker/u:8:0] and hides its binary in the site user's home directory rather than the web root, with a cron job rewriting itself every five minutes in a way that dodges typical crontab logging. On one victim it read session data straight out of the store's own Redis database rather than contacting outside infrastructure; on another it reached command-and-control servers matching Sansec's published indicators.
No fix yet
With Adobe silent, defenses are all third-party stopgaps. Sansec recommends disabling GraphQL entirely unless a store runs its Shield product, though that breaks headless and progressive-web-app storefronts. Disrex, a developer known as ProxiBlue, and a firm called Graycore have each released community patches or firewall rules targeting different points in the chain, but all three call their own work partial hardening, not a real fix. Disrex also found attackers could dodge its firewall rule simply by moving parameters into a POST body.
Two settings that don't depend on understanding the exploit at all: disabling the PHP function proc_open, which one dropper used after other functions were already blocked, and mounting temporary directories with the noexec flag so a downloaded binary cannot run. For stores already compromised, guidance calls for preserving evidence first, killing the process before removing its cron job, never rebooting since the only surviving copy of the binary may live only in memory, and rotating every credential in the store's environment file rather than trusting a scan alone. One security firm's own detection scanner reportedly missed the backdoor entirely on a store where it was actively running.
Two hosting providers said this week they were reviewing their environments as a precaution, though neither has confirmed a breach. No group has been tied to the campaign, and the number of affected stores overall is still unknown.
The recent news has notably increased the number of consumers potentially exposed in the incident. “We're deeply saddened to share the news that the recent data breach affects more customers than originally thought,” Trezor said on X.
As per Trezor, the additional 67000 customers placed orders from November 2019 to August 2021.
The leaked data consists of customers' email, phone numbers, names, addresses, order numbers, and shipping addresses. According to Trezor, the data was stored by ShipMonk even though Trezor had earlier received assurance that previous consumer data had been erased.
“Throughout our entire relationship with ShipMonk, we repeatedly requested and received written assurance confirming the deletion of the data, in line with our contract, data policy, and past communications. We are very disappointed that, despite receiving this confirmation, the data was not deleted in their systems,” Trezor said.
According to experts, the breach is not impacting Trezor’s own systems.
Trezor said its hardware wallets are safe and there are no signs that customers’ recovery seed phrases or private keys were breached in the leak.
As per Trezor, “All affected customers have been emailed directly. If you didn’t receive an email, then you are not affected.”
But Trezor and cybersecurity experts are worried that the stolen data could be exploited for social engineering and targeted phishing attacks. Threat actors could misuse customers’ details regarding their Trezor purchases to create scam phone calls or fraud messages.
This can be a serious problem for cryptocurrency users. A threat actor could mimic a company employee if they know someone owns a Trezor wallet and ask the target to verify their wallet or account.
If successful, the attacker could steal the target’s recovery seed phrase, which can allow access to cryptocurrency funds. “Trezor systems were not compromised, and your device is secure. But please be alert for fake emails, phone calls, fraudulent letters, and potential risks to physical security,” the company added.
The announcement comes after the August incident when 13,689 customers had been impacted by the same shipping-provider. At the time, Trezor estimated around 14,000 customers to have been affected by the breach. The recent disclosure of 67,000 suggests the scope of the incident was larger than expected.
This flaw arises because the default Layer 3 (L3) virtual routing and forwarding (VRF) allows access to TCP ports 43210 and 43211. If the exploit is effective, the attacker may be able to connect to the compromised device and submit manipulated input that could be run as root-level code. Additionally, if this vulnerability is exploited, the S1HAL process may crash and the device may need to reload.
The Nexus vulnerability, tracked as CVE-2026-20212, with a CVSS score of 9.8, was reported on September 2 by Cisco. The vulnerability impacts a few Nexus 9000 switches consisting of Silicon One ASICs, which can result in either device outages or remote code execution.
According to Cisco, Nexus 9000 Series Switches with the following product identifiers (PIDs) included a Silicon One ASIC, are vulnerable:
If effectively abused, the threat actor could run code with root-level privileges on the switch, This can allow attackers to modify the device, compromise traffic travelling via the infrastructure, and disturb the network operations.
According to Cisco, Nexus 9000 switches working in ACI mode and other Cisco and Nexus product families are not impacted. Admins can use the show module command to find the product ID of a Nexus switch and decide if it is in the impacted range.
The following products are not vulnerable, according to Cisco advisory:
Cisco has launched software updates to patch the flaw. It has also advised customers to upgrade to a fixed NX-OS release. Cisco has also launched a Live Protect Shield as a temporary fix for impacted executions, but urges that it is only temporary until a complete software upgrade is available.