StyleSmuggler: An Unpatched Magento 0-Day Is Already Being Used to Break Into Stores

Translated by a model; the original is in Russian.

· Security
The Dutch firm Sansec has disclosed a critical vulnerability in Magento Open Source and Adobe Commerce that allows code execution on the server without authentication. Attacks are happening right now, and there's still no patch from Adobe.

cover.svg

On September 5, the Dutch e-commerce security firm Sansec issued a warning about a new vulnerability in Magento Open Source and Adobe Commerce, dubbing it StyleSmuggler. The flaw lets an attacker execute arbitrary code on a store's server without logging in and install a persistent backdoor. The company stresses that it is publishing the details earlier than usual because stores are being compromised right now: the first attacks were recorded on September 4.

As of September 6, Adobe had released neither an advisory nor a CVE identifier, nor a patch, nor a workaround. According to Sansec, all current versions are affected — the researchers reproduced the full unauthenticated chain on clean installations of 2.4.7, 2.4.8, and 2.4.9. The first victim was running 2.4.6-p15 with the latest available Adobe updates, meaning the official patches offered no protection.

How the attack works

The attack unfolds in two stages. First, PHP code is injected into a file that Magento creates itself (for example, when generating an error report). Then the platform is made to execute that file by triggering the built-in “Payment Transaction Failed Reminder” email. The code runs at the moment the email is rendered, so no one needs to open it, and the attack succeeds even if the mail fails to send.

The implant disguises itself as the system process [kworker/u:8:0] — a name that normally belongs to a Linux kernel thread. It is a statically linked Rust program about 1.9 MB in size, installed in the site user's home directory. A cron entry restarts it every five minutes; on one store this line appeared 1,728 times, and after removal it was restored within a second. On one infected node the implant never reached out at all, instead holding 28 connections to a local Redis, reading Magento's session storage.

What to do until the patch is released

There is no official fix. Sansec advises stores that don't use its Shield product to temporarily disable GraphQL. Note that headless and PWA storefronts won't work without GraphQL, whereas classic storefronts and Hyvä usually don't need it. Disrex, which independently investigated two breaches, has published rules for nginx and Apache but admits they only block parameters in the query string, while the same data sent in a POST body still reaches PHP.

Disrex also recommends adding proc_open to disable_functions and mounting /tmp, /var/tmp, and /dev/shm with the noexec flag so that a downloaded binary can't run. When cleaning up an infected store, it's important to preserve the evidence first, remove the cron entry before killing the process, avoid rebooting the server, and not run composer install. Afterward, flush the session storage and change the encryption key in app/etc/env.php, along with all passwords and API keys.

Adobe's next scheduled update release is set for September 8, but whether a fix will be included remains unknown.


Source: The Hacker News

Comments

Sign in, to comment.

  • No comments yet.