CVE-2026-75650: Patch Magento and Adobe Commerce Now

Stores were being exploited through StyleSmuggler for three days before a patch existed. Sansec logged the first confirmed hit on September 4. Adobe published bulletin APSB26-146 and hotfix VULN-39341 on September 7 under CVE-2026-75650, CVSS base score 10.0, with a plain statement that it is being exploited in the wild. No login is needed to trigger it, and no user has to click anything.

If you run Adobe Commerce, Adobe Commerce B2B or Magento Open Source on any release through the August 2026 security release, this is your afternoon, and the order matters as much as the speed.

Apply the hotfix first, because it closes the door. Then check for compromise: a patch does not evict anyone who came in while the door stood open. Then rotate the encryption key and every credential it protected; Adobe makes no exception for stores that patched quickly.

TL;DR
Affected: every Adobe Commerce, Adobe Commerce B2B and Magento Open Source release through the August 2026 (2026-aug) security release.
Fix: hotfix VULN-39341, a Composer patch, verified with the Quality Patches Tool.
Check: the six Sansec detection commands in Step 2 on every affected store.
Rotate: the encryption key and every credential it may have encrypted or exposed, on Adobe's instruction.
Severity signal: CISA gave US federal agencies until September 11 and flagged forensic triage.

What CVE-2026-75650 is

Adobe files it under CWE-1336, Improper Neutralization of Special Elements Used in a Template Engine, with a CVSS 3.1 base score of 10.0 and the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H: network-reachable, low complexity, no privileges, no user interaction, changed scope. Arbitrary code execution in the context of the current user follows. Adobe rates it priority 1, and the bulletin summary does not hedge: "Adobe is aware of CVE-2026-75650 being exploited in the wild."

Sansec found it and named it StyleSmuggler. At bulletin level the attack has two stages. First, attacker-controlled PHP lands in a file Magento will read later, such as a generated failure report. Second, a request makes Magento's template processing render the Payment Transaction Failed Reminder email, and that path runs dependency-injection scanning code which includes the poisoned file. That is as deep as a defender needs to go.

Sansec has seen two payloads on exploited stores, from two actors. The StyleSmuggler actor drops a Rust backdoor for Linux whose command-and-control traffic is disguised as NTP on UDP port 123 and WebSocket over TLS on port 443. A second attacker, who also came in through StyleSmuggler, drops a PHP web shell below pub/media to run arbitrary commands on the host.

That is three days between the first confirmed exploitation and a patch anyone could apply.

Which versions are affected

Every Adobe Commerce, Adobe Commerce B2B and Magento Open Source release up to and including the August 2026 security release is affected. There is no older version to fall back to; the only unaffected state is the hotfix applied.

The bulletin and the KB's affected table both list Open Source from 2.4.6 upward. Sansec says every version from 2.4.4 up is affected, and Adobe ships hotfix files it calls compatible with Open Source 2.4.4 through 2.4.7. Either way, 2.4.4 and 2.4.5 are past Adobe support: treat a store on them as exposed and plan the upgrade.

Run bin/magento --version on each store first and write down the exact release and patch level; the KB's download table is keyed by it. A fleet needs that list with a hotfix-status column, because Step 1 verifies one store at a time.

Step 1: Apply hotfix VULN-39341

This is a hotfix, not a release. The bulletin's Solution table lists it as the updated version for Adobe Commerce and Magento Open Source; as of September 8 no new full release is listed. You patch the release you are on.

The primary file is VULN-39341-composer-patches.zip, from https://repo.magento.com/patch/VULN-39341-composer-patches.zip. Adobe's KB table lists it against every 2026-aug and 2026-jul release from 2.4.4 to 2.4.9 and the -p levels it names. Six further files are separate downloads, each for a range of patch levels: 2.4.8 through 2.4.8-p3, 2.4.7 through 2.4.7-p8 and 2.4.6 through 2.4.6-p13, with the two 2.4.6-level files also covering 2.4.5 through 2.4.5-p15 and 2.4.4 through 2.4.4-p16. Match the KB row to the exact patch level you wrote down. It installs as a Composer patch per Adobe's "How to apply a composer patch provided by Adobe" documentation.

Staging first, but under an active exploit with a CVSS 10.0 the staging pass is hours, not days: apply, verify, walk a test order through checkout, promote. Yes, a rushed patch can break checkout. Unauthenticated remote code execution is worse.

Cloud stores run the same verification command as on-prem, so do not assume the platform applied the hotfix for you. They also follow the KB's cloud cron commands in Step 3, from vendor/bin/ece-tools cron:disable through the closing redeploy.

Verify with the Quality Patches Tool, which is what Adobe's KB points you at. If vendor/bin/magento-patches is missing, install the tool first with composer require magento/quality-patches.

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

The grep keeps the header row and any 39341 row. A 39341 row with the Applied status means the hotfix is on. No row, or any other status, means that store is still exposed.

Step 2: Check for compromise before you trust the patch

The hotfix stops new exploitation and does nothing about anyone who came in between September 4 and September 7. The implant persists through cron and, per Sansec, can relaunch itself with no cron entry at all; the second attacker's web shell sits under pub/media, untouched by the hotfix. Run this check on every affected store, patched or not, before you rotate keys.

Sansec's six detection commands, run from the Magento root as the user Magento runs as; the /var/log grep usually needs root or sudo, and "Permission denied" means it never ran, not that it came back clean:

crontab -l | grep -i gvfsd
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 -iE 'kworker|fc-cache|chronyd'
grep -r 'crontab command not allowed' /var/log/
grep -ril 'x_trace_' var/report/
find pub/media -name '*.php'

A clean store returns nothing from the crontab grep, the ls or the two log greps, and nothing from find you cannot account for. Read the ps output rather than counting it; kworker and chronyd are legitimate names on any Linux host, and the tell is an args column pointing at a path below.

The implant runs under these process names:

[kworker/u:8:0]
fc-cache
chronyd

It drops files at these paths; the last is the second attacker's web shell:

/tmp/.kw_<random><random>
/tmp/.cache_<random><random>
/tmp/.fc-<8hex>/fc-cache
/tmp/fc-cache
/tmp/.fc_<8hex>.lock
/tmp/.chrony-<8hex>/chronyd
~/.local/share/.gvfsd/gvfsd-user
~/.local/share/.gvfsd/.gvfsd_<8hex>.lock
~/.cache/fontconfig/fc-cache
pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php

It persists through cron entries shaped like these:

*/5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-user
13,43 * * * * <home>/.cache/fontconfig/fc-cache >/dev/null 2>&1
57,27 * * * * /tmp/.chrony-<8hex>/chronyd >/dev/null 2>&1

Sansec lists nine command-and-control hosts and six payload hashes:

99.84.67.186:443 (WebSocket over TLS)
windwsecurity.run:443 (WebSocket over TLS, TCP)
ntp.timesysnc.net:123 (custom NTP-shaped traffic, UDP)
time.microsft.run:123 (custom NTP-shaped traffic, UDP)
pool.microsft.studio:123 (custom NTP-shaped traffic, UDP)
ntp.timesync.to:123 (custom NTP-shaped traffic, UDP)
185.157.160.251:123 (A record for ntp.timesync.to and ntp.timesysnc.net)
ntp.synctime.to:123 (fallback)
ntp.syncstime.to:123 (fallback)

e315687a1dfe61ef4a5a5642214db6d3b2b05d81391285eebc2af664641a26a7
b79dfdc1eed860e0b76c629d6adfce251db379b0b45a6d728d4ef483f7551420
4352cabaa451e5a894535fbcc4d46628701303322a13745cb5479d7d0534ae8e
d2fbf9eb75c495bfea48790d3b228fab0c15a282419c3d3f5e49294c4e1a3e82
1a3374ffac5b0a62467612f264c49792d206304d4514409c982325c91231375d
d61217ca0bca83204302fa7b41935ce36f73764559c156d5c980f2fedddffb6e

Unexpected copies of the Payment Transaction Failed Reminder email, the template the chain renders, are a sign of exploitation attempts. Sansec also reports that the second attacker's web shell answers 404 without a proper X-Cache-Token header; the header name is an indicator only where request headers are logged, at a WAF or CDN, never in standard access logs. The reliable check is the shell path, which find pub/media covers.

Sansec, on the crontab: "This build can relaunch itself with no cron entry at all, so an empty crontab is not evidence that a host is clean." And on sessions: "Moving sessions to Redis or the database does not stop the attack."

If anything comes back, the patch is now the smaller problem. Take the store off the network or block it at the edge. Preserve evidence before you clean: copy the crontab, the dropped files, the process list and the logs somewhere the attacker cannot reach. CISA's required action includes forensic triage; hold yourself to that standard whether or not a federal deadline applies to you. Do not just delete the cron lines and call it done.

Bring in emergency Magento support or your own incident responder. Treat any backup taken after September 4 as suspect.

Step 3: Rotate the encryption key and everything it protected

Adobe's KB puts it in one sentence: "Rotate not only your encryption key but all credentials that may have been encrypted or exposed using it, including server, API, and integration credentials." Code ran as the current user, so everything the key protected was within reach and has to be treated as read.

The sequence is Adobe's, from the KB announcement; steps 4 through 11 are its full rotation list:

1. Apply hotfix VULN-39341.
2. Put the store into maintenance mode.
3. Turn cron off. On Commerce on Cloud: vendor/bin/ece-tools cron:disable.
4. Rotate the encryption keys.
5. Rotate all Admin panel user passwords.
6. Deactivate and regenerate all REST, SOAP and GraphQL integration tokens (System > Extensions > Integrations).
7. Rotate OAuth client secrets for connected third-party applications.
8. Rotate payment gateway API credentials at the provider level.
9. Rotate database credentials.
10. Rotate SSH and deploy keys and any cron or system-privileged service account credentials.
11. Rotate API keys for shipping, tax and other integrated third-party extensions.
12. Flush the cache.
13. Turn cron back on. On Commerce on Cloud: vendor/bin/ece-tools cron:enable.
14. Take the store out of maintenance mode.
15. Commerce on Cloud only: redeploy to apply the new database credentials.

Steps 2 and 3 are the bracket everyone skips. Maintenance mode stops customer traffic while the key changes; cron off stops a scheduled job from writing with the old key mid-rotation. The bracket closes at steps 13 and 14, after the whole list is rotated and the cache flushed, not after the key alone.

Each rotated credential then has to be re-entered wherever it is configured, from the payment settings in the admin to every pipeline that holds a token or key; budget time for that.

Step 4: Close the window for next time

There is no workaround. Neither the Adobe bulletin, the KB announcement nor the Sansec write-up publishes a WAF rule, feature toggle or configuration change that blocks this; the hotfix is the fix. A store that cannot apply a Composer patch on short notice has a process problem, and this bulletin just made it visible.

Sansec states that its Shield product blocks every StyleSmuggler variant it has seen so far, and still recommends installing the Adobe patch. The second half is the operative part.

Plan the upgrade off Open Source 2.4.4 or 2.4.5; the argument over whether they are even in scope is what running an unsupported release looks like from the outside.

The fix for next time is dull: every Adobe security release applied inside a fixed window, verified the way Step 1 verifies this one, on every store. That is the loop our Magento security patch service runs, with security patches applied within 24-48 hours of release, tested in staging first. To hand off the whole cycle, including the upgrade off an unsupported release, see Magento maintenance plans, one of the Magento support services.

Sources

• Adobe security bulletin APSB26-146 (opens in a new tab)
• Adobe Commerce KB announcement for APSB26-146 (opens in a new tab)
• NVD record for CVE-2026-75650 (opens in a new tab)
• CISA Known Exploited Vulnerabilities catalog (opens in a new tab)
• Sansec StyleSmuggler research write-up (opens in a new tab)

If Step 2 came back with anything, or you have a fleet and nobody free to run this loop today, that is what the emergency line is for. Orange Collar Media has been in Magento since 2008; the call goes to a Magento developer. The emergency page puts the response at under 3 hours.

Talk to a Magento developer now

Changelog

• 2026-09-09: first published.