StyleSmuggler: Magento emergency patch is here — what merchants and developers need to do now

Update from September 8, 2026: Adobe has responded. Since September 7 at 10:20 PM, an emergency patch has been available—Bulletin APSB26-146 . The vulnerability is now officially called CVE-2026-75650 and has a severity rating of 10.0 out of 22. Install it today. Further information can be found in the situation section and the FAQs; the rest of this post remains unchanged, as the attacks continue and a patch won't fix a store that's already occupied.

On Friday evening, September 4, 2026, at 22:20 PM UTC, the first Magento shop was compromised. The owner was unaware of this at the time. His shop was running a current version, all security patches from July and August were installed, and the audit reported no missing updates . This is precisely where this incident differs from everything you've read about Magento security in recent years.

The vulnerability is called StyleSmuggler. It allows attackers to execute their own code on your server without any authentication. All current versions of Magento Open Source and Adobe Commerce are affected, including the brand-new version 2.4.9. For three days, there was no update—yet attacks still occurred on a widespread basis. An emergency patch has been available since the evening of September 7th, and the vulnerability's perfect score of 10.0 speaks volumes about the seriousness of the situation.

This article is divided into two parts. The first part explains in plain language what happened, how you can tell if you've been affected, and what to do today. The second part is aimed at developers and server administrators and provides signatures, verification commands, and the blocking measures that actually work. We personally recorded the attack wave of September 5th in a shop we manage—what happened there is described below.

What has happened since September 4th

The vulnerability was discovered and named by the Dutch security company Sansec, which has focused exclusively on attacks against e-commerce systems for years. The finding was published on September 5, 2026—explicitly before the completion of their own analysis , because by that time some shops had already been compromised. The complete technical analysis can be found in Sansec's original publication on the StyleSmuggler vulnerability.

The figures are disturbingly sobering. A specialized service provider reported two confirmed takeovers and one attack on, but not breached, within the first few days—a total of 26 different sender addresses, mostly hijacked residential connections in the USA. This isn't a targeted attack on individual brands. This is a network being cast across the board, and your shop is just one entry in a list.

The timeline shows how tight the situation was. Adobe's last regular security advisory was dated August 11th. Anyone who installed all the updates back then believed they were safe until September 4th. For three days after that, every accessible online store was unavailable without the update.

The emergency patch: APSB26-146

Adobe delivered on September 7th at 22:20 PM — out of schedule, with the highest priority level. Here's what you need to know:

• The vulnerability is now called CVE-2026-75650 and is 10.0 of 10 points Rated. The scale doesn't go any higher.
• It is a Hotfix, not a full releaseYou download it from the Magento repository and apply it as a patch — your version remains where it is.
• Covered are 2.4.4 – 2.4.9This applies to Adobe Commerce, Magento Open Source, and the B2B extension. Even older installations will find a solution.
• After installing the patch, you can check its status to see if it's actually working. Do this—a silently failed patch is worse than no patch at all, because it creates a false sense of security.

One point Adobe explicitly emphasizes, and which is easily overlooked: The manufacturer recommends changing the shop's encryption key after the patch—and with it, all access data protected by that key: administrator accounts, interface tokens, payment service provider logins, database, server keys, and extension access. And not just after a proven breach. The reason is inconvenient: An attacker who was able to execute code in recent days had access to everything the key protects. Changing it afterward doesn't undo what has already been read—it only prevents further use.

How far you implement this recommendation is a matter of weighing the options: In the case of a shop with a documented break-in, there's no way around it. In the case of a demonstrably thwarted attack without card data in the system, a different decision can be made—but deliberately, and not out of convenience.

Why "everything patched" means nothing this time

Herein lies the real news, and it's inconvenient. The first confirmed case was running Magento Open Source 2.4.6-p15, with the isolated patches from July and August 2026, and the patch check command reported an empty list. Completely up-to-date, then. Nevertheless, the shop was hijacked, just as effortlessly as an installation that had been forgotten for two years.

Patch status and security are not the same thing. That's the key takeaway for retailers from this incident. Updates close known vulnerabilities. They do nothing about those that no one knows about yet—and that's precisely the area where those targeting your shop operate. What will help in this situation are measures that work regardless of the specific vulnerability: blocked upload paths, restrictive directory permissions, a system file monitor, and a shutdown of the web server.

That sounds like effort that's wasted as long as nothing happens. However, during the week of September 4th, this effort paid off handsomely for one of our shops. More on that in a moment.

How the attack works — two stages, no click

StyleSmuggler isn't a clumsy hacking method; instead, it exploits two perfectly normal Magento functions in succession. This is what makes it so difficult to detect: nothing happens at any point that, taken individually, would seem suspicious.

Stage one: The code is smuggled in.

The attacker sends a request to your shop's GraphQL interface—the address that modern frontends, apps, and interfaces use to communicate with Magento. This request contains specially crafted parameters named stylesThis roundabout way, PHP code is inserted into a file that Magento writes itself during normal operation, for example, an error report under var/report/The name of the vulnerability comes precisely from this: The malicious code travels along disguised as a formatting instruction.

Stage two: Magento executes it itself.

The interesting part. The smuggled code is now on the disk, but it's doing nothing. So the attacker tricks Magento into generating a completely ordinary system email: a reminder about a failed payment transaction. While assembling this email, Magento reads the malicious file—and executes the code in the process. No one needs to open this email. It's enough that the server generates it.

What happens next is routine for the attackers: An intermediate loader tries six different PHP functions in sequence to start a process. If one of them works, it loads a program written in Rust from an external server and starts it. This program disguises itself in the process list as [kworker/u:8:0]As a harmless component of the Linux kernel, it places itself in an inconspicuous directory in the home folder and registers itself with the time schedule so that it survives a reboot. It then reads, among other things, your customers' session data from the cache.

From this point on, it's no longer a shop problem, but a server problem: customer data, orders, backend access data, database contents—and the possibility of your payment process being intercepted with card data theft. Günter Born has compiled a German-language analysis with the same findings on his IT blog.

The warning signal is probably already in your inbox.

And now comes the part you really need, because it costs nothing and requires no technical knowledge.

Because stage two uses the payment error email as a trigger, every attempt at exploitation generates precisely these notifications. Massive numbers. An unusually high number of messages with the subject "Reminder: Transaction Failed" is therefore not just a cosmetic flaw in your shop—it's the most visible indication that someone is trying to scam you.

There are three typical characteristics that allow you to recognize this without server access: The emails arrive in rapid succession over several hours. They contain neither a customer name nor an item. And the amount is zero. If you have seen something like this in the last few days and dismissed it as a software error, please retrieve the emails from your trash folder and check the timestamps.

There are two things you shouldn't do. First, don't turn off notifications because they're annoying. That effectively disables your only free alarm system. Instead, set up a separate mailbox that isn't checked during your daily work. Second, don't assume an empty mailbox means the all-clear. It simply means no one tried to send emails to you—or that the emails are ending up somewhere else.

From practice: an attack that came to nothing.

On Saturday, September 5th, the operator of a Magento shop we manage contacted us with around 140 of these emails in his inbox, received between 07:00 and 11:26 AM. All were for customers only, with no items ordered, and with a value of €0,00. His initial assumption—that someone was trying to order as a guest—was partially correct and ultimately far less serious than what we later found in the logs.

The error logs contained 138 rejected transactions, the last one at 11:26:03 AM. This coincided exactly with the last email. In addition, there were 184 rejected attempts at guest checkout, a feature not even enabled in this shop. The accesses originated from approximately 20 masked US connections, all using the same machine identifier in the browser address bar. And the requests contained precisely the parameters that Sansec had published as a signature the day before.

The attack failed at four independent points , and none of them involved a patch:

• The first upload attempt via the customer address function ran into a block that has been in place since April: rejected with error code 403.
• The second approach via the product add-on options failed due to directory permissions — the target directory is not writable.
• The attempt to access the backdoor, whose filename was identical to that of an attack wave in April, was unsuccessful: the file was never on the disk.
• The actual execution chain failed due to the current version, including the isolated patches from July and August.

One postscript that gave us pause: During the subsequent search, we found 762 malicious files that had been stored in a cache directory since April— one level above the area scanned by our own security software . They were inaccessible from the outside and had never been executed. Nevertheless, they had been there for months, and we hadn't noticed them. The scan area has since been expanded, and the files have been securely archived and removed. Anyone running their own security checks should take this opportunity to calculate where their search area ends and where the file system extends.

What you as a retailer should do today

Magento News - For merchants, developers and customers How can I completely uninstall an extension in Magento 2?

In this order, because the order makes a difference.

First: check if you've already been affected. Closing a vulnerability is pointless if someone's already inside—the backdoor remains, even if the path to it is blocked. This check belongs on the server, not in the backend, and it should be done today. If you need support with this: We've described the cleanup process in a separate article about removing malware from a Magento shop.

Second: install the patch. It's been available since September 7th—as a hotfix, not a version jump, for all releases from 2.4.4 onwards. This is the single most important step since yesterday, and it needs to be done today, not next week. Afterwards, check the patch status instead of just assuming it worked.

Third: close the attack vector anyway. A patch protects against this vulnerability, not the next one. If your shop exposes GraphQL externally without needing it, disable it—but first check the access logs to ensure that no one is actually using it. In addition, blocking rules on the web server and two settings in the PHP configuration will generally thwart attacks of this type. The details are in the next section.

Fourth: Change your login credentials. This includes backend accounts, databases, encryption keys, interface tokens, and access to payment service providers. Adobe now explicitly recommends this for all affected shops, not just after a proven breach—the reasoning is explained above. An attacker who has intercepted session data no longer needs your password anyway. Important: Change your login credentials at the source , i.e., with the payment service provider and the hosting provider itself, not just within the shop.

Fifth: Remember the reporting deadlines. If personal data has been compromised, there is a 72-hour deadline for reporting to the relevant data protection authority. The Federal Office for Information Security (BSI) explains on its page about reporting IT security incidents which options are available to companies. Important: A thwarted attack without data access is not a reportable incident. A successful attack is.

Sixth: leave the alarm system activated. See above — a separate mailbox for payment error emails, but do not deactivate it.

You've found something — now what?

This case deserves its own paragraph because it occurs more often than one might think, and because it is usually less bad than it initially appears.

If your scan reveals malicious code in the log files or error reports, it means the first stage has passed. It doesn't mean your shop has been compromised. These are separate events, and this distinction is precisely why an initial assessment so often fails.

In the shop we're reporting on here, the code was stored in 23 entries on the disk—but it was never executed. Three things prevented this, and you should check these on your own system before triggering the emergency plan:

• The expiration date. The inserted code carried a time window of approximately three minutes. Anyone who finds it days later will find something dead.
• The password. The code requires a specific value in the request, which only the attacker knows. Without it, nothing happens.
• The file format. If the code is embedded as a text snippet in an otherwise intact report file, it will not be treated as a program during normal operation.

The decisive factor in determining whether the code was copied or not is therefore not the entries in the logs, but rather the traces of the second stage: an unfamiliar process, an entry in the time scheduler, an unknown file in the cache, an outgoing connection. If these are missing, the code was written down but never executed. What you should still do in that case is to securely back up and remove the problematic entries in a legally compliant manner—and close the path through which they entered the system.

For developers and administrators: check, lock, harden

From here on, things get technical. All information is taken from the Sansec publication and our own analysis; please verify it against the current status, as the situation changes daily.

Recognition: Is something already happening for you?

The implant reliably leaves four traces. Look for processes whose names are in square brackets but which do not belong to the system user—the code name is... kworker, were also observed fc-cache and chronydCheck the web server user's time schedule for entries that shouldn't be there; a twice-hourly call has been documented. Check the home directory for a hidden directory named .gvfsd as well as the cache on files according to the pattern .kw_ with random attachment. And browse var/report/ and var/log/ after the string X_TRACE_ and after the PHP opening character — that's where the poisoned file from stage one is located.

E-news for ambitious developers - read up to speed 🎬 How can Renderforest, with its AI tools, be a useful aid in e-commerce? 🛒

A look at the access log completes the picture: Count the requests whose query string styles[, generatorClass or with_resolved It contains information. Anyone whose score there is higher than zero has at least been affected. Don't forget the rotated archives—the daily log only shows what happened today.

The second entry point is often overlooked. In addition to GraphQL, another path was observed: POST /paypal/transparent/response/ with a PHP opening character directly in the query string. This also results in code being written to a file by Magento itself. Anyone who only /graphql Blocking it leaves this path open.

Why your malware scanner probably isn't reporting this

We experienced this ourselves, and it's the most unpleasant part of this incident. Our own monitoring was running every fifteen minutes at the time of the attack, with a well-defined set of rules—and it reported nothing.

The reason: She was looking for filename, To *.php The errors were found in the media directory, following typical Webshell patterns, and due to archive files being in the wrong location. However, the Magento error reports are simply named after their checksum, without any extension—thus missing all of these patterns. The code was exposed and formally invisible.

Check your own monitoring system against this very question: Does it search by name or by content? And does its search scope truly cover everything? In our case, we also discovered a second issue: a cache directory one level above the defined starting point, which had been harboring malicious files undetected for months. Both have since been closed—the scan now focuses on the content of the files, using error reports and logs, and for large files, always checking the end where the most recently written data is located.

Web server blocking — with one important limitation

For nginx, there are rules that hard-reject requests with known patterns in the query string: parameter names with styles[, the identifiers generatorClass and with_resolvedMagento template instructions in double curly braces, as well as PHP opening characters in queries or browser identifiers. This makes sense, but These rules have a loophole you need to know about.Web servers only see the query string in the address. If an attacker moves the same parameters into the request body of a POST request, they will bypass all of these rules. Blocking on the web server is a delay, not a solution.

The barrier that truly works

A more effective approach is to block access at the point where the smuggled code actually ends up. The affected classes belong to the dependency scanners in the setup directory and simply have no place in web applications—they are intended for the command line. A check at the beginning of each method that aborts execution as soon as PHP is not run via the command line closes the loop regardless of how the parameters are passed. This affects the array scanner, the XML interceptor scanner, and the class scanner. Keep two things in mind: Any modification to vendor files will be lost the next time Composer is run, and it should be tested on a backup beforehand. Make a note of it and check after every update.

Two PHP settings that render the attack ineffective

We believe these two points are the most effective advice in this entire article—and they are almost never mentioned. They work without a patch, without disabling GraphQL, and without modifying the program code . For anyone running an app or a modern frontend that truly needs GraphQL, this is the only remaining option.

First: disable_functions to fill. The second stage of the attack involves downloading and starting a program. The malicious code queries, sequentially, which functions are available to start a process—and uses the first one it receives. In both installations we tested, this list was... completely emptyThis is the default configuration of many hosting providers. A populated list (exec, passthru, shell_exec, system, proc_open, popen, pcntl_execThe chain ends at this point. Magento does not need these functions in web operation; the setting is ignored for the command line.

Secondly: short_open_tag switch off. The second attack vector via the payment interface begins with a shortened PHP opening character. If this setting is set to... OffThis vector is ineffective—the injected text remains text. Again, in both tested installations, it was set to... On.

Neither of these settings can usually be configured manually, as the central PHP configuration belongs to the system administrator. It's a quick request to your hosting provider—and probably the most worthwhile one you'll make this week. Be sure to state the reason for your request; otherwise, it will end up in the queue. While you're at it, ask about a curfew for the PHP process : this prevents reloading and thus also protects against the next vulnerability that no one has yet discovered.

Further hardening, which acts independently of this gap

• Curfew for PHP processes. Stage two requires a program to be loaded from the outside. A web server, which is not allowed to establish connections to the internet on its own, breaks the chain precisely here—and will do so again with the next, as yet unknown, vulnerability.
• No executable files in the media directory. PHP files below pub/media are always a finding, never a condition.
• Close upload paths you don't need. In our case, it was the customer address uploads and the product add-on options — two of four breaking points.
• File guard over system files. Checksums of the central entry files are regularly compared, with an alarm triggered in case of deviations. And then it's recalculated whether the search scope truly covers everything.
• Rate limiting for GraphQL and REST addresses. No frontend in the world sends a hundred requests per second from a single source.

If you're unsure whether your installation meets these basic requirements: A structured walkthrough of configuration, permissions, and protocols is part of our ongoing maintenance and support ; for Magento specifically, you can find our service description on the Magento agency's website in Hamburg . We've also documented what a thorough backend audit looks like for testing the Magento backend.

Conclusion: The gap is the event, the hardening is the response.

Zero-day vulnerabilities are not an isolated incident, but a recurring phenomenon. There was CosmicSting, there was SessionReaper, now there's StyleSmuggler—and sometime next year, the next name will emerge. What changes between these events is not the existence of the vulnerabilities, but rather how far an attacker can get before something stops them.

The September 7th patch resolves this issue, and you should install it today. However, it doesn't break the pattern: there were three days between the initial attack on September 4th and the update, during which no update would have helped. This gap in the schedule is precisely why hardening is not a substitute for updates—and updates are not a substitute for hardening.

In the shop we reported on, there were four independent departments involved—and the crucial finding is that none of them were a patch. These were decisions made in April, long after the pressure had subsided and no one was paying attention. This is precisely where the outcome of a Saturday morning in September is determined: as 140 annoying emails or as a report to the data protection authority. If it does come to that, the Federal Commissioner for Data Protection's overview guides you through the reporting process for data protection violations.

And the most honest statement last: In the same scan, we found 762 malicious files that had been lying undetected since April because our own search scope was one directory level too deep. Defended doesn't mean flawless. It only means that enough layers remained.

What is the situation with you?

Did you receive an unusually high number of payment error emails on September 4th, 5th, or 6th? Is your shop running on one of the affected versions, and is GraphQL accessible from the outside? Have you already run a check on the server—and do you know where your search scope ends?

If any of these questions leave you unsure, don't wait until after the weekend. Write to us via our contact form about what you've observed; we'll review your logs and tell you whether it's routine or urgent. For existing maintenance customers, the review is already underway—for everyone else, it's an hour that's particularly worthwhile this week.