Magento StyleSmuggler zero‑day exploit is actively backdooring online stores

E‑commerce sites built on Magento are now being targeted by a live zero‑day exploit that can install a backdoor without any login. The flaw, dubbed StyleSmuggler by the security firm Sansec, lets an unauthenticated attacker run code on the server and persistently control the store.

Scope of the problem

All supported Magento versions, from the classic 1.9 line up to the latest 2.4.9, are vulnerable. Sansec reproduced the full attack chain on clean installations of 2.4.7, 2.4.8 and 2.4.9, confirming that the issue spans the entire product line. As of 6 September, Adobe has not published an advisory, CVE identifier, patch or official workaround, leaving merchants to rely on interim measures.

Evidence of exploitation

Independent analysis by the Disrex Group found two Magento Open Source stores that had been compromised and a third that was attacked but not breached. Both compromised sites were running the open‑source edition, not Adobe Commerce. The implanted code runs under the unprivileged site user and does not spread laterally, and Disrex saw no signs of data theft, rogue admin accounts, payment skimmers or database backdoors in the two breached stores.

Immediate actions you can take

Sansec’s short‑term advice for stores that are not using its Shield product is to temporarily disable the GraphQL endpoint, GraphQL is a query language that lets front‑end applications talk to Magento’s back‑end, until Adobe releases an official fix. In addition, the following steps are recommended:

Photo by Christina Morillo on Pexels

• Rotate every Magento admin password and API key that may have been exposed.
• Apply unofficial mitigations published by Disrex, ProxiBlue and Graycore. These patches rewrite the vulnerable code paths and can be applied without waiting for an Adobe update.
• Add proc_open to PHP’s disable_functions list. proc_open is a PHP function that can launch external programs; disabling it removes a common way for the backdoor to execute further commands.
• Mount /tmp, /var/tmp and /dev/shm with the noexec option. The noexec flag tells the operating system not to run any binaries from those temporary directories, blocking a typical payload drop location.
• Remove any malicious cron entry left by the implant and kill the running malicious process.
• Flush Magento’s session storage after cleanup to clear any lingering malicious data.
• Regenerate the encryption key in app/etc/env.php (the file that stores Magento’s cryptographic secret) to invalidate any stolen credentials.

These actions form a layered defence that limits what an attacker can do even if the vulnerability is exploited.

Why the vulnerability matters now

The exploit is already being used in the wild, and because there is no vendor‑issued patch, the window for attackers to gain footholds remains open. Merchants that run Magento should treat this as a high‑priority incident, the backdoor gives the attacker full control of the web server and the ability to modify site content, inject malicious code or launch further attacks against visitors.

Photo by Lewis Kang'ethe Ngugi on Pexels

Bottom line

Until Adobe publishes an official advisory and patch, the safest path is to shut down GraphQL, rotate credentials, apply the community‑sourced patches and harden the underlying PHP and filesystem configuration. Monitoring for the Indicators of Compromise shared by Disrex (available on their GitHub page) will also help spot any lingering infection.

Terms used in this article

• GraphQL, a language that lets applications request exactly the data they need from an API.
• proc_open, a PHP function that can start external programs on the host system.
• noexec, a mount option that prevents execution of binaries from the mounted directory.
• Backdoor, malicious code that remains on a system and allows an attacker to regain access at will.
• Unauthenticated, the attacker does not need valid credentials to exploit the flaw.