StyleSmuggler: what the new vulnerability in Magento means for your store

Anže Voh September 7, 2026

Update, September 8, 2026: the official patch is out. Adobe published security bulletin APSB26-146 on September 7, and the vulnerability is now tracked as CVE-2026-75650 with a CVSS score of 10.0. The fix ships as a hotfix for existing versions rather than as a new Magento release, so no store upgrade is required. Applying the patch is now the first step, and the mitigation measures in this post are only a stopgap until it is in place. The patch closes the hole but does not clean a store that was already hit: attacks ran for three days before the fix existed, so a review for traces of intrusion and the replacement of keys, passwords and tokens remain a separate task. The text below has been updated to the current state.

In early September, a serious security vulnerability was discovered in Magento and Adobe Commerce, named StyleSmuggler. Attackers have been exploiting it since September 4th, and Adobe released the official patch on September 7th. Since the issue has appeared in the media and some of our clients are already asking about it, we have gathered in one place what this means in practice and what is sensible to do.

What happened, in layman's terms

A flaw was found in Magento that allows an attacker to upload and run their code on the store's server without having a user account or password. It is enough for the store to be publicly accessible online. Once successful, the attacker leaves a hidden access on the server, through which they can return.

It was discovered by the Dutch security team Sansec, which deals exclusively with the security of online stores. The unpleasant part of the story is that attacks were observed in traffic the day before the public announcement, and the first confirmed victim was a store that had all the then-existing official security patches installed. In other words, in this specific case, regularly installing patches was not enough because the patch did not exist at that time.

Does this mean Magento is unsafe and it's time to move elsewhere?

No. We understand why such a question arises, and we hear it every time something like this goes through the media, so we answer it directly.

Vulnerabilities of this kind happen to everyone. They have happened to WordPress and WooCommerce, where they are even more frequent because most come through third-party plugins. They have happened to hosted platforms and applications in their app stores. They have happened to payment providers and mail servers. Software that is widespread enough to be worth dealing with will sooner or later get something like this. This is not a characteristic of Magento but a characteristic of the web.

The difference between platforms is not whether something like this happens, but who takes care of the patch. On hosted platforms like Shopify, the provider does this, and you are likely unaware of the event. This is a real advantage, and we will not deny it. But you pay for it elsewhere: with a monthly subscription and a commission on sales, with less control over how the store operates, and with dependence on what the provider allows you. In an incident that affects them, you also wait, only you have no say in it.

With Magento, the control is yours, and so is the responsibility. Therefore, the key question for your own store is always the same: is someone regularly taking care of the store. A store that someone set up four years ago and hasn't been touched since is in serious trouble in such a week. A store that is regularly maintained gets a review and action in the first few days and most likely doesn't even know anything was wrong.

Switching platforms in response to a security event is an expensive and risky move that solves one thing and brings five new ones: data transfer, loss of custom functionality, drop in search engines, new costs. If you are considering moving for other business reasons, that is a completely legitimate conversation, and we are happy to have it. As a response to one security event, however, it is a bad exchange.

What should I do as a store owner

If you have a store on Magento 2, three steps make sense, in order:

Ask the person who takes care of your store if they have already dealt with StyleSmuggler. If you have a maintenance contract, this is a short message, and the answer should be ready. If you don't have such a person, you've just found the main problem, and it's not in Magento.
Apply the official patch now, not at the next update. Adobe released it on September 7th as a hotfix for existing versions, so upgrading Magento is not required. If for any reason it cannot be applied immediately, temporary measures apply until then, and they can be implemented quickly and just as quickly reversed. Which one is suitable in your case depends on how the store is built.
Check if anything has already happened. This is the part people most often skip. Attacks have been running since September 4th, three days before the fix existed, so an applied patch says nothing about what happened before. A system review for traces of intrusion is a separate task from protection.

What is not needed: panic, stopping the store, or conclusions about moving. The matter is serious, but it is not something that cannot be managed.

Technical part

This section is intended for developers and system administrators. If you do not manage the store yourself, you can skip it or forward it.

Status

Sansec issued a warning on September 5, 2026. It is an unauthorized remote code execution (unauthenticated RCE). The entire chain was repeated on clean installations of Magento Open Source 2.4.7, 2.4.8, and 2.4.9. The first confirmed attack was recorded on September 4th at 22:20 UTC, and the first confirmed victim was running on 2.4.6-p15 with July and August patches and a clean output of security:patch-status.

Adobe confirmed the vulnerability on September 7, 2026 in bulletin APSB26-146, two days after Sansec's warning and ahead of the regular security release. It is tracked as CVE-2026-75650 with a CVSS score of 10.0 and priority 1, and Adobe confirms exploitation in the wild. The fix is published as hotfix VULN-39341, a set of composer patches rather than a new release, and Adobe tested it against the August releases of Adobe Commerce and Magento Open Source 2.4.4 through 2.4.9 and Adobe Commerce B2B 1.3.3 through 1.5.3. Adobe also explicitly recommends rotating the encryption key and every credential it protects.

Attack chain

Intentionally at a level sufficient for defense, without details that would benefit anyone. The attack is two-stage. In the first phase, the attacker achieves the writing of raw PHP code into files that Magento creates itself, typically in error reports and logs. In the second phase, a path is triggered that includes and executes these files. The sink is in classes related to the dependency injection (DI) compiler, which should not be accessible from a web request in normal operation.

After successful execution, a persistent backdoor is installed: a statically compiled Rust file, about 1.9 MB in size, available for x86-64 and arm64, which presents itself in the process list as a kernel process. Persistence is ensured by a cron entry that restarts it every five minutes.

Signs of intrusion

A process named in the style of [kworker/u:8:0], not run by root but by the web user.
Files in ~/.local/share/.gvfsd/ and /tmp/.kw_*.
A cron entry running every five minutes pointing to a hidden folder in the home directory.
An increase in email notifications about failed payments, especially with unresolved template variables in the text.
Outgoing traffic to unknown hosts.

SHA256 hashes of known files and a list of attacker IP addresses from two waves have also been published. If you find any of the above, deleting the file is not a solution: the system should be treated as fully compromised, as backdoors are usually in multiple places at once, and all keys, passwords, and tokens need to be replaced.

Mitigation measures until the patch is applied

As of September 7, the first measure is the official patch. The list below stays useful in two cases: while the patch cannot yet be applied, and as an extra layer on stores where exploitation may already have happened.

Disable GraphQL, if the store does not need it. This is Sansec's recommendation and typically has no consequences in a classic store without a separate frontend. In PWA setups or mobile applications, this is not an option, and another path is needed.
Web server rules for nginx and Apache that filter known request patterns. They are published publicly.
Limiting the sink in the application, i.e., a safeguard that restricts dependency injection classes to execution from the command line. This is a measure that holds regardless of the path the request comes through.
Server hardening: disabling proc_open in PHP where not needed, and mounting /tmp, /var/tmp, and /dev/shm with the noexec flag.
Review for traces of intrusion backward, separate from forward protection.

On unofficial patches

In the community, at least two sets of unofficial patches appeared within a few hours, including the collection by Disrex, which offers not only patches but also server rules and detection scripts. Their authors openly state what needs to be said: they were created during an active response to the incident, they interfere with Magento's core, and no one has reviewed them as an official manufacturer's patch would be.

With the official patch out, the unofficial ones are redundant. If you rolled one out, it has to be removed when the official patch is applied, otherwise the installation can fail or leave behind an intervention nobody maintains any more. The same goes for the server rules and the GraphQL switch: once the patch is applied and verified, both can be returned to their original state.

Where we help with this

If you run a store on Magento and are unsure where you stand, get in touch. Specifically, we can do the following:

Exposure review. Version, settings, and whether GraphQL is even in use, from which it follows what is safe to disable in your case.
Review for traces of intrusion. Processes, cron, file system, logs, outgoing traffic, and checkout code.
Applying the official patch. First in a staging environment, then on production, together with removing the temporary measures and verifying that the patch is really in place.
Cleaning after an intrusion, if it turns out it happened. Removal of backdoors, replacement of keys and passwords, and restoration of a clean state.

For one-time interventions, there is Magento technical support. The execution time is coordinated after reviewing the inquiry, depending on how urgent the matter is.

Why a maintenance contract makes sense in such stories

StyleSmuggler is a good example of what a one-time store creation does not solve. The store could have been made well, and patches could have been installed regularly, yet it was still exposed. The difference between a store that was affected and a store that was spared is mainly in whether someone knew in the first days that they needed to look.

With a maintenance contract, we take over this monitoring. We monitor security announcements for Magento, WordPress, and Shopify, check your environment during such events without you having to ask, implement measures when they are current, not three months later, and you have someone to call in an incident. The content of the package otherwise goes for regular updates, security checks, backups, and minor fixes. In a month like September 2026, it goes exactly for what this post talks about.

If you have a store on Magento 2 and have not checked anything mentioned so far, this is a good moment. Write to us and tell us which version of Magento you are using and who hosts your site. From there, it goes quickly.