# StyleSmuggler Gave Magento Unauth RCE. The Hotfix Does Not Clean the Store.
> StyleSmuggler is CVE-2026-75650, unauthenticated RCE in Magento and Adobe Commerce via the template engine. Sansec saw exploitation from 4 September. Adobe shipped hotfix VULN-39341 as APSB26-146 on 7 September, CVSS 10.0. July and August patches did not stop it. The hotfix does not remove implants, and rotating the encryption key does not revoke stolen credentials.
Source: https://hackerlogs.com/blog/stylesmuggler-magento-rce
Published: 2026-09-08
## Key takeaways
- CVE-2026-75650 is unauthenticated template-engine RCE. Adobe rated it CVSS 10.0 and said it has been exploited against Commerce merchants.
- The first confirmed victim was on 2.4.6-p15 with the July and August 2026 patches and a clean security:patch-status. Being current was not a defence.
- Adobe's fix is hotfix VULN-39341 under APSB26-146, tested on the 2026-aug lines. Confirm it with magento-patches status, not a version string.
- Operators dropped a Rust implant that renamed itself kworker, then fc-cache, then chronyd, plus a second actor's PHP web shell under pub/media.
- Adobe's own cleanup is rotate the encryption key and every credential that key protected, at the source. The hotfix does not do that for you.
[The Hacker News](https://thehackernews.com/2026/09/adobe-patches-magento-zero-day.html) has the headline: Adobe patched a Magento zero-day used to drop a Rust backdoor and a PHP web shell. That is the news. The operator fact is narrower. Adobe's [7 September announcement](https://experienceleague.adobe.com/en/docs/commerce-knowledge-base/kb/announcements/commerce-apsb26-146) is an emergency hotfix, not a monthly train, and the company says CVE-2026-75650 has already been exploited against Commerce merchants. A store that only applies VULN-39341 and reopens checkout is not finished.
Unauthenticated remote code execution, CVSS 10.0, in the wild from 4 September. Adobe's own note treats this as urgent for every current 2.4 line.
## What StyleSmuggler actually is
[Sansec](https://sansec.io/research/stylesmuggler-0day) named the bug and published first, on 5 September, because stores were already being hit. They reproduced the full unauthenticated chain on clean Magento Open Source 2.4.7, 2.4.8, and 2.4.9. The first confirmed victim was 2.4.6-p15 with the July and August 2026 patches applied and `security:patch-status` clean. A later probe hit 2.4.7-p10. Current on the monthly bulletin was not a control.
The chain is template injection, not a new Magento feature. Sansec's description: attacker-controlled PHP is written into Magento's template system, including through the `styles` properties that existing safeguards were not treating as code. Stage two is execution when Magento renders a failed-payment email, the standard "Payment Transaction Failed Reminder." Nobody has to open the mail. The code runs while the platform builds it, and it can run when delivery itself fails.
That is why a burst of those reminders is a hunt signal and not a proof. Real declines generate the same message. The useful tell is volume you cannot explain, plus a process or file that should not be there.
We are not reprinting the request that lands the first stage. The class is enough: an unauthenticated write into a template that a later, trusted renderer executes. GraphQL showed up as one entry. Moving sessions to Redis or the database did not stop it. Sansec recorded an attempt that failed against session storage and, eight seconds later, a second attempt from the same operator that succeeded through a file uploaded as a custom option.
> StyleSmuggler's first victim was already on the July and August 2026 patches. Adobe's answer is a later hotfix, VULN-39341. A green monthly status from August is the starting condition of this incident, not the end of it.
## Three days live, then a hotfix
Adobe's Commerce knowledge-base note is the vendor document to file. It lists Adobe Commerce 2.4.4 through 2.4.9 (2026-aug and earlier), the matching B2B 1.3.3 through 1.5.3 lines, and Magento Open Source 2.4.6 through 2.4.9. The hotfix was tested on those 2026-aug builds. Adobe says it may apply to earlier supported versions in the same branches; it has not verified that.
The fix is a composer patch, `VULN-39341-composer-patches.zip`, from `repo.magento.com`. Adobe's confirmation command is `vendor/bin/magento-patches -n status` filtered for `39341`. A version bump you already applied in August will not show this ID.
Sansec's last update on 7 September, 20:45 UTC, is the same night as the hotfix. They still recommend installing Adobe's patch even if you already run their Shield. The operators changed payloads several times a day from 4 September. A WAF rule written on Friday is not a substitute for the vendor change.
## What landed on the box
Successful exploitation launched a small Rust program as a background process. First seen name: `[kworker/u:8:0]`. On 6 September it copied itself to `~/.cache/fontconfig/fc-cache` and called itself `fc-cache`. On 7 September the same agent ID relaunched as `chronyd` under `/tmp/.chrony-/`. Sansec had not, at time of writing, seen the backdoor take a follow-on task. Waiting for commands is still a foothold.
The later builds hid command-and-control as time sync: UDP port 123, hostnames that look like NTP, datagrams that are only NTP in the first four bytes. A real `chronyd` is the process you are tempted to exclude from that hunt. Sansec's split: the implant emits a burst of server-mode packets every minute; a client does not.
A second actor used the same hole the same week and did not share tooling with the first. Their dropper wrote a PHP web shell into the product image cache under `pub/media`. Requests without a specific header got a 404. That is why killing a Rust process is not a clean bill. Look for unexpected PHP under media.
> Do not treat an empty crontab as clean. Sansec saw a chronyd build whose parent was PID 1 and a cron line written straight into the spool, with no crontab REPLACE in syslog.
## What to do
If you run Magento Open Source or Adobe Commerce:
1. Apply VULN-39341. Confirm the patch ID is Applied. If you are not on a 2026-aug line Adobe tested, treat the hotfix as unverified until you have a lab install that still boots.
2. Hunt before you declare victory. Process names above. `find pub/media -name '*.php'`. Unexpected failed-payment mail volume. Cron spool, not only `crontab -l`.
3. Then do Adobe's rotation list, in order, with maintenance mode on: encryption key, admin passwords, REST/SOAP/GraphQL integration tokens, OAuth client secrets, payment-gateway API keys at the provider, database credentials, SSH and deploy keys, shipping and tax extension keys. Rotate at the source. Flush cache. Bring cron back.
4. GraphQL-off is a leftover mitigation, not a substitute. If the storefront does not need it, leaving it off still shrinks one entry. It does not replace the hotfix.
Adobe is explicit that rotating the encryption key alone does not invalidate anything an attacker already read. That sentence is the cleanup. The 10.0 is the hole. The three days before 20:20 UTC on 7 September are the window you have to assume was used.
A patched store with yesterday's payment credentials is still the incident.
## Sources
- [StyleSmuggler: Magento and Adobe Commerce 0-day RCE (CVE-2026-75650) under active attack](https://sansec.io/research/stylesmuggler-0day) (2026-09-05)
- [Urgent Action Required: Critical Security Update Available for Adobe Commerce (APSB26-146)](https://experienceleague.adobe.com/en/docs/commerce-knowledge-base/kb/announcements/commerce-apsb26-146) (2026-09-07)
- [Adobe Patches Magento Zero-Day Exploited to Deploy Rust Backdoor and PHP Web Shell](https://thehackernews.com/2026/09/adobe-patches-magento-zero-day.html) (2026-09-08)
- [Magento StyleSmuggler zero-day exploited to deploy Linux backdoor](https://www.bleepingcomputer.com/news/security/magento-stylesmuggler-zero-day-exploited-to-deploy-linux-backdoor/) (2026-09-07)
- [Adobe Commerce Zero-Day Exploited to Backdoor Online Stores](https://www.securityweek.com/adobe-commerce-zero-day-exploited-to-backdoor-online-stores/) (2026-09-07)
- [CVE-2026-75650](https://www.cve.org/CVERecord?id=CVE-2026-75650) (2026-09-07)