StyleSmuggler CVE-2026-75650: Adobe hotfix for Magento RCE

On 7 September 2026 Adobe published hotfix VULN-39341 for CVE-2026-75650, bulletin APSB26-146. CVSS 10.0, priority 1. The gap Sansec named StyleSmuggler lets an attacker run code on Magento Open Source and Adobe Commerce without logging in. Attacks have run since 4 September. The hotfix closes the vector. It does not remove an implant from the three days before the fix.

Sources: Sansec analysis and the Adobe notice. This post is an operator checklist: confirm the hotfix, scan for IoCs, rotate the encryption key and secrets at their source.

Which versions are affected

Adobe lists Adobe Commerce 2.4.4 to 2.4.9, Magento Open Source 2.4.6 to 2.4.9, and Adobe Commerce B2B 1.3.3 to 1.5.3, including the 2026-aug releases and earlier builds in those lines. Sansec reproduced the unauthenticated chain on clean Magento Open Source 2.4.7, 2.4.8 and 2.4.9. The first known victim ran 2.4.6-p15 with the July and August 2026 patches. security:patch-status was clean. On 7 September Shield blocked a probe against 2.4.7-p10.

A current product version without VULN-39341 does not protect. Moving sessions to Redis or the database does not either.

Adobe tested the hotfix on the 2026-aug releases. Older builds in those branches are affected. Adobe has not confirmed patch compatibility there.

How the attack chain looks

The gap sits in the template system. The styles properties let malicious PHP in and bypass existing safeguards. Sansec describes two stages:

• Inject PHP code, for example through a crafted failure report.
• Execute that code while Magento renders the standard failed-payment message.

In traffic you see among others POST /graphql with styles parameters and payment-related paths, including /paypal/transparent/response/. The attack deliberately triggers the “Payment Transaction Failed Reminder” mail. The code runs while the message is generated. Nobody needs to open the mail. The attack can also succeed when mail delivery fails.

A sudden rise in such mails is a reason to investigate. Receiving no mail does not mean the store is clean.

What remains after a successful attack

After RCE a Rust implant appears on the server. It connects to C2 and waits for commands. As of 7 September Sansec had not confirmed further use of the implant on victims. Persistent access alone is enough to treat this as an incident.

The first process variant pretends to be [kworker/u:8:0]. From 6 September an fc-cache variant appears: a copy under ~/.cache/fontconfig/fc-cache, a cron at minutes 13 and 43, UDP traffic on port 123 to domains that look like time servers (ntp.timesync.to and similar). On 7 September the same implant on some hosts renamed itself to chronyd and the path /tmp/.chrony-<8hex>/chronyd. That is not the system NTP daemon. An empty crontab -l is not enough. The entry is sometimes written straight into the spool file.

UDP/123 traffic looks like time sync. The packets carry hostname, user, OS version and resource use, among other fields.

On 7 September Sansec also described a second, separate actor on the same victims: a short PHP dropper and a web shell in the product image cache, under a path like pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php. Killing the background process does not finish the case. There should be no PHP files under media.

What to do now

Follow Adobe's notice and a compromise scan. The patch does not replace the scan. The scan does not replace the patch.

1. Hotfix VULN-39341. Download VULN-39341-composer-patches.zip from repo.magento.com and apply it as a composer patch for your version in the Adobe table. Confirm the status:

vendor/bin/magento-patches -n status | grep "39341\|Status"

You want Applied next to VULN-39341. The Magento version number or a green August security:patch-status does not show this.

2. IoC scan. On the Magento host you can run our script (no exploit, only signals from the Sansec analysis, including chronyd under /tmp and PHP under pub/media):

curl -fsSL https://opselis.pl/scripts/stylesmuggler-check.sh -o stylesmuggler-check.sh
chmod +x stylesmuggler-check.sh
./stylesmuggler-check.sh /path/to/magento

Or by hand:

crontab -l | grep -iE 'gvfsd|fc-cache|chronyd'
ls -la ~/.local/share/.gvfsd/ ~/.cache/fontconfig/fc-cache /tmp/.kw_* /tmp/.cache_* /tmp/.gvfsd-* /tmp/.fc-*/fc-cache /tmp/fc-cache /tmp/.chrony-*/chronyd 2>/dev/null
ps -eo pid,comm,args | grep -E '\[kworker/u:8:0\]|/tmp/.chrony|fontconfig/fc-cache'
grep -ril 'x_trace_' var/report/
find pub/media -name '*.php'

Also check outbound UDP/123 from the application server and the IoCs from the Sansec analysis: NTP-shaped domains, C2 addresses, paths under /tmp, cron, and processes [kworker/u:8:0], fc-cache and chronyd that are not the system daemon.

3. Rotation after the patch. Adobe's order: maintenance mode, disable cron, rotate the Magento encryption key, then secrets at their source, not only in the panel. The key encrypts integration tokens, payment-gateway data and automation tokens. Changing the key alone does not invalidate a copy an attacker already read.

Rotate admin passwords, REST/SOAP/GraphQL tokens, OAuth secrets, payment-gateway API keys, the database password, SSH and deploy keys, and extension keys. Then flush the cache, enable cron, disable maintenance mode.

4. If you find the implant. Treat it as an incident: isolation, the hotfix if it is not on yet, rotation as above, review of cron (the spool file as well, not only crontab -l), media, reports and logs from 4 September, and the access scope. Killing one process does not remove persistence.

Temporarily disabling GraphQL was the pre-hotfix mitigation. After VULN-39341 it does not replace the scan or the rotation. A WAF and Shield limit entry. They do not replace the Magento patch.

Store layers: security. Magento operations: ecommerce.

In short: StyleSmuggler is CVE-2026-75650, unauthenticated RCE, Adobe hotfix VULN-39341 since 7 September 2026. First the hotfix and a scan for the implant. Then rotation of the key and of secrets at their source.