Adobe Commerce's 'StyleSmuggler' Zero-Day Hit Stores Three Days Before a Fix

On September 4, 2026, at 22:20 UTC, attackers began hitting Magento and Adobe Commerce storefronts with an unauthenticated remote-code-execution exploit that no vendor patch yet addressed. The flaw, tracked as CVE-2026-75650 and named StyleSmuggler by the Dutch security firm Sansec, carries a CVSS score of 10.0, the maximum. Adobe published emergency bulletin APSB26-146 and hotfix VULN-39341 on September 7, three days after the first confirmed intrusion. By the time a fix existed, attackers already had enough time to install persistent backdoors on compromised stores, and the patch does nothing to remove them.

Related reading: CISA Flags PolyShell as Exploited While the Magento Campaign Hits Hundreds of Stores · Microsoft's October 2026 Patch Tuesday Sets a Record With 1,407 Fixes.

That gap is the story. In a modern e-commerce platform, an unauthenticated code-execution bug is about as bad as a vulnerability gets: the attack surface is simply "is the store reachable from the internet," and the prize includes customer records, payment data, admin credentials and the ability to inject payment skimmers into checkout. StyleSmuggler turned out to require no exotic configuration. Sansec reproduced the full chain on clean installations of Magento Open Source 2.4.7, 2.4.8 and 2.4.9, and one confirmed victim was running 2.4.6-p15 with July and August patches applied and a clean security:patch-status report, proof that the usual "are we up to date?" check was not enough.

The two-stage chain

StyleSmuggler abuses Magento's template system in a way that splits the attack into a quiet stage and a triggering stage. First, an unauthenticated attacker sends a GraphQL request whose styles property carries an injected PHP payload. The payload does not run immediately; it is written to disk inside a file that Magento generates as part of normal operations, such as a checkout failure report. Because the payload arrives disguised as styling data, it slips past the safeguards meant to keep executable code out of templates, hence the name.

The second stage is the clever part. Magento later renders that poisoned content while building one of its own standard transactional emails, the "Payment Transaction Failed Reminder." The malicious PHP executes server-side during template rendering. Nobody has to open the email, and the attack still works if the message is never delivered, so a merchant who never sees a suspicious message is not in the clear. Sansec notes that an unexpected burst of payment-failure reminder emails is still worth investigating, even though ordinary declined payments produce the same notification.

The chain matters because it does not depend on a misconfigured theme or a careless administrator. Sansec reported that session-storage choices make no difference, and that one operator failed once against a store using Redis-backed sessions, then succeeded eight seconds later by routing the payload through a file uploaded via Magento custom options. A stock store on a current branch was in scope.

A fix that has no version

Adobe's remediation is unusual, and that has consequences for anyone trying to prove they are protected. The company did not ship a new Magento or Commerce release. Instead, APSB26-146's solution field points to the string "Hotfix for CVE-2026-75650," delivered as a Composer patch file, VULN-39341-composer-patches.zip, applied through Adobe's composer-patch process. As the security publication Severity Daily pointed out, a Composer patch does not move the product's version string: a store that has applied the hotfix and one that has not both report the same Adobe Commerce release. A conventional version-matching vulnerability scanner cannot tell them apart. Adobe's recommended verification is a shell command on the host (on Cloud, vendor/bin/magento-patches -n status filtered for 39341), which works server by server and does not scale into a fleet-wide compliance check.

The affected range is broad. Adobe lists Adobe Commerce 2.4.4 through 2.4.9, including the August 2026 releases and earlier versions in each branch; Adobe Commerce B2B 1.3.3 through 1.5.3; and Magento Open Source 2.4.6 through 2.4.9. Adobe says the hotfix has only been tested against the August 2026 releases of those branches and that compatibility with older releases has not been confirmed. Sansec separately reported reproduction against clean 2.4.7, 2.4.8 and 2.4.9 installs.

Adobe also made clear that patching is not the whole job. Because the flaw lets an attacker run code as the web server, anything the store could reach is potentially exposed, including the encryption key that protects stored secrets. The knowledge-base advisory instructs merchants to rotate the encryption key and then every credential that key protected: admin passwords, REST, SOAP and GraphQL integration tokens, OAuth client secrets, payment-gateway API credentials, database credentials, SSH and deploy keys, and third-party extension API keys. Rotating the key alone, the page warns, does not invalidate credentials an attacker already read; they have to be rotated at the source, such as at the payment gateway.

Before the hotfix landed, the interim mitigation was to disable GraphQL. That is an awkward trade-off for modern, API-driven and headless storefronts, which rely on GraphQL for their front ends. It was nonetheless the most direct way to cut off the injection stage while a fix did not exist.

A backdoor dressed as the operating system

What makes StyleSmuggler more than a patching story is what the attackers leave behind. Sansec's forensic analysis describes a small Rust program that runs as a background process and connects to a command-and-control server. Early samples contacted 99.84.67.186; later builds disguise their traffic as Network Time Protocol, sending 48-byte UDP packets to port 123 (a port and protocol most egress filters wave through) with only the first four bytes actually resembling NTP. The rest carries a MessagePack record with the agent ID, hostname, username, operating system version, memory and disk usage, uptime, whether it is running as root, and the implant version. Sansec said that as of its September 11 update the implant resolved ntp.timesync.to and ntp.timesysnc.net to 185.157.160.251, the address to block if filtering by name is not possible.

The implant hides in plain sight by adopting the names of ordinary Linux housekeeping. The first variant appeared as [kworker/u:8:0], mimicking a kernel worker thread. Later builds renamed themselves to fc-cache, copying to ~/.cache/fontconfig/fc-cache, and then to chronyd, the real name of the NTP daemon on most distributions. Persistence comes from cron entries written directly into the cron spool rather than added through crontab -e, so system logs contain no REPLACE line; observed schedules ran every 30 minutes. Sansec also noted a variant that can relaunch under parent process ID 1 with no cron entry at all, meaning an empty crontab is not evidence of a clean host.

A second, unrelated operator was seen on the same victim stores. On September 7, Sansec analyzed a 485-byte PHP dropper that writes a web shell into Magento's product-image cache under pub/media. The shell returns a 404 to any request that lacks a secret X-Cache-Token header, and when the header is present it runs arbitrary PHP from the task POST parameter. Sansec recovered the dropper from a Store: request header, still JSON-escaped from the record Magento logged it into, confirming it entered through StyleSmuggler. The two campaigns share victims but not tooling. Tenable's FAQ on the flaw reported multiple victim stores across campaigns, and that the incident-response firm Disrex had first-hand experience with at least two compromised stores; as of September 8 there was no public attribution to a named threat group.

Patching closes the hole but does not clean a store that was already hit. Stores were being exploited for three days before the hotfix existed.

Why this one lands harder

Adobe Commerce and Magento run a large share of the world's online storefronts, and many of those stores are small or mid-sized businesses without a dedicated security team. That combination amplifies every property of this incident. The exploit needed no login, so exposure was broad. The pre-patch window stretched across a weekend in some regions. And the payloads were designed to survive remediation. A merchant who patches on day one may still be hosting an attacker who arrived on day zero.

There is a compliance dimension, too. CISA added CVE-2026-75650 to its Known Exploited Vulnerabilities catalog on September 8 and set a federal remediation deadline of September 11, a three-day window that is far tighter than the weeks CISA typically allows. That entry obliges federal agencies to apply mitigations under new risk-based patch rules and to perform forensic triage, the kind of obligation that becomes difficult when the remediation is a patch with no version number and a credential-rotation checklist. The practical takeaway for private-sector operators is the same: the deadline may not bind them, but the urgency does.

The episode also reinforces a pattern in e-commerce security. The template and rendering layers keep being the way in, because they sit between user-supplied content and server-side execution, and because the email pipeline is easy to overlook. Sansec's recommendation to look for freshly written .php files under pub/media is telling (that directory is meant to serve images and cache, never code) and file-integrity monitoring is well suited to catch exactly that kind of anomaly.

What to watch

Four things will determine how this incident is remembered.

First, whether Adobe converts the hotfix into a numbered release. Composer patches are a reasonable emergency response, but the lack of a version number leaves every asset inventory and scanner blind, and it makes the difference between patched and unpatched invisible to the tools most organizations rely on.

Second, whether the implant gets weaponized. At the time Sansec published its analysis, it had no indication that the backdoor had been used for anything beyond beaconing, and the malware was not recognized by any security vendor other than Sansec. That could change quickly.

Third, whether the second operator's web shell is the leading edge of a broader Magecart-style campaign. An unauthenticated RCE that reaches checkout is a natural staging point for card-skimming code, and the window between first exploitation and disclosure gave attackers time to position themselves.

Fourth, how many stores were actually compromised. Confirmed victim counts are still small and anecdotal. The true number may only surface as merchants run compromise assessments and find processes named kworker, fc-cache or chronyd that do not belong. Until then, the honest posture for anyone who ran an internet-facing Magento store between September 4 and the moment they patched is to assume compromise until proven otherwise, and to rotate credentials only after the patch and the hunt are done, in that order.