StyleSmuggler Gave Magento Unauth RCE. The Hotfix Does Not Clean the Store.

The Hacker News 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 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.

Critical 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 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.

Three days live, then a hotfix#

1. 2026-09-04
   Sansec records the first confirmed StyleSmuggler exploitation at 22:20 UTC. eComscan flags the implant on unrelated stores the same hour.
2. 2026-09-05
   Sansec reproduces the chain on clean 2.4.7, 2.4.8, and 2.4.9, publishes, and starts blocking with Shield.
3. 2026-09-06
   The Rust implant renames itself fc-cache, version 2.1.4, and starts looking like NTP.
4. 2026-09-07
   A second, unrelated actor drops a PHP web shell under pub/media. The first implant renames itself chronyd, version 2.1.5.
5. 2026-09-07
   Adobe publishes APSB26-146 and hotfix VULN-39341 for CVE-2026-75650 at 20:20 UTC. Priority 1. CVSS 10.0.

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-<id>/. 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.

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.