BREAKING: CVE-2026-75650 is unauthenticated RCE in Adobe Commerce and Magento, already exploited

If you run Adobe Commerce or Magento Open Source and you have not applied today's emergency hotfix, an attacker who can reach your storefront can run PHP as your web user with no login. Adobe published APSB26-146 for CVE-2026-75650 on September 7, 2026, scored it 10.0 (AV:N/AC:L/PR:N/UI:N/S:C), Priority 1, and says it is already being exploited in the wild. The fix is a hotfix named VULN-39341, not a full minor release. Stores on the latest 2026-aug builds are still vulnerable until that patch is applied and credentials are rotated.

This is the operator write-up. The HOL Guard evidence pack for CVE-2026-75650 is the source record.

What breaks

Adobe's CNA description is short: improper neutralization of special elements in a template engine (CWE-1336) that yields arbitrary code execution in the current user context, no user interaction required, scope changed. Sansec publicly tracked the in-the-wild chain as StyleSmuggler before the CVE landed. Their write-up matches Adobe's urgency: attackers poison Magento's template path through styles properties that slip past existing safeguards, then get Magento itself to execute the payload while rendering the standard "Payment Transaction Failed Reminder" email. Nobody has to open the mail. The render path is enough, and the chain still works when delivery fails.

Sansec reproduced the unauthenticated chain on clean Magento Open Source 2.4.7, 2.4.8, and 2.4.9. Their first confirmed victim was on 2.4.6-p15 with the July and August 2026 Commerce security updates already applied and security:patch-status clean. Being current on APSB26-92 / APSB26-73 is not a substitute for VULN-39341. Adobe's bulletin lists Adobe Commerce through 2.4.9-2026-aug, Magento Open Source through the same train, and Adobe Commerce B2B through 1.5.3-2026-aug as affected.

After code execution, Sansec has been documenting implant turnover in the same campaign window: background processes disguised as [kworker/u:8:0], then fc-cache, then chronyd, plus a second actor dropping a PHP web shell under pub/media. Treat "we patched" as incomplete until you have also hunted those hosts.

Who is not in scope

• Stores that have already applied Adobe's VULN-39341 hotfix and completed the credential rotation Adobe documents. Confirm with the Quality Patches Tool status below rather than assuming a deploy succeeded.
• Adobe Experience Manager, ColdFusion, and other Adobe products outside Commerce / Magento Open Source / Commerce B2B. APSB26-146 is a Commerce bulletin.
• Frontends that only talk to Magento over a tightly locked integration and never expose a Magento/Adobe Commerce storefront, GraphQL, or payment callback surface to untrusted networks. You still want the hotfix on the Commerce host; you are not in the internet-exposed emergency class Sansec describes.
• Non-Magento carts (Shopify, WooCommerce, custom storefronts with no Magento PHP runtime). The CWE-1336 sink is in Adobe Commerce / Magento's template engine.

What this is not

This is not an admin-only bug, not a "click a crafted link" XSS story, and not fixed by upgrading to the newest 2.4.9-2026-aug tag alone. Adobe's own table says authentication required to exploit is No, and the CVSS vector is PR:N. It is unauthenticated remote code execution via the template engine, with confirmed in-the-wild use before the hotfix existed.

How to fix

Apply Adobe's hotfix, then rotate secrets. Do not stop at the composer patch.

1. Download VULN-39341-composer-patches.zip from Adobe (linked from the APSB26-146 Experience League article) and apply it with Adobe's composer-patch workflow for your version line.
2. Adobe tested the hotfix on the 2026-aug builds of Commerce 2.4.4–2.4.9, Magento Open Source 2.4.6–2.4.9, and Commerce B2B 1.3.3–1.5.3. Older builds in those branches are still listed as affected; the patch may work there but Adobe has not officially verified it.
3. Put the store in maintenance mode, disable cron, rotate the Magento encryption key, then rotate every credential that key protected at the source: Admin passwords, REST/SOAP/GraphQL integration tokens, OAuth client secrets, payment-gateway API keys, database credentials, SSH/deploy keys, and third-party extension API keys. Adobe is explicit that rotating the encryption key alone does not invalidate anything an attacker already read.
4. Flush cache, re-enable cron, leave maintenance mode. Then scan for compromise before you declare victory.

Operator check that the hotfix is actually live (Cloud example from Adobe; on-prem use the same Quality Patches Tool against your local hotfix file):

# After installing Quality Patches Tool and applying VULN-39341:
vendor/bin/magento-patches -n status | grep "39341\|Status"
# Expect an Applied row for .../m2-hotfixes/VULN-39341_Hotfix_COMPOSER.patch

# Sanity on the running tree:
php bin/magento --version
php bin/magento security:patch-status || true

Compromise hunt Sansec recommends after the three-day pre-patch window (treat hits as incident response, not as "noise"):

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

Sansec Shield customers still need the Adobe hotfix. WAF rules reduce exposure; they do not replace VULN-39341 or credential rotation on a store that may already have been hit between September 4 and the September 7 bulletin.

References

• Adobe Security Bulletin APSB26-146
• Adobe Commerce: apply hotfix for CVE-2026-75650 (VULN-39341)
• CVE-2026-75650
• Sansec: StyleSmuggler (CVE-2026-75650) under active attack