On September 7, 2026, Adobe issued an out-of-band security advisory (APSB26-146) for CVE-2026-75650, a CVSS 10.0 unauthenticated remote code execution vulnerability in Adobe Commerce, Adobe Commerce B2B, and Magento Open Source. Adobe confirmed the flaw was already being exploited in the wild — and according to security firm Sansec, which tracked the attack under the name "StyleSmuggler," the first confirmed exploitation happened at 22:20 UTC on September 4, three days before a patch existed.
What happened
Adobe released 10 bulletins covering 172 unique CVEs in September 2026, and only three carried its highest deployment priority: Commerce (APSB26-146, CVSS 10.0), Campaign Classic (CVSS 10.0) and ColdFusion (CVSS 9.9), per the Zero Day Initiative's monthly review. Of those, Commerce is the one Adobe says is being exploited in the wild.
The bug is a template-engine injection, classified as CWE-1336 (improper neutralization of special elements used in a template engine). Sansec's technical writeup describes a multi-stage attack chain rather than a simple payload drop:
1. Injection — an attacker plants PHP code inside data that Magento will later process as part of a template.
2. Trigger — the attack abuses Magento's "Payment Transaction Failed Reminder" email functionality to force that data to be rendered.
3. Execution — the malicious code runs during template rendering for the email, whether or not the email actually gets delivered. No authentication and no user interaction are required.
Sansec reproduced the exploit cleanly against unpatched Magento Open Source 2.4.7, 2.4.8, and 2.4.9. Per Adobe's advisory, affected versions are Adobe Commerce 2.4.4–2.4.9, Magento Open Source 2.4.4–2.4.9, and Adobe Commerce B2B 1.3.3, 1.3.4, 1.4.2, 1.5.2 and 1.5.3 (August 2026 releases and earlier) — effectively every actively supported release line at the time.
What makes this worse than a typical critical CVE is the payload attackers dropped once in. Sansec and the Magento agency Disrex documented a statically linked Rust backdoor (dropped as ~/.local/share/.gvfsd/gvfsd-user in its first form) that disguised itself as legitimate system processes — [kworker/u:8:0] (mimicking a Linux kernel worker thread), then fc-cache and chronyd in later builds — using cron jobs and, in at least one variant, a cron-independent auto-restart mechanism to persist and evade casual inspection. Separately, researchers at Disrex reported a managed server hit only 50 minutes after the first confirmed StyleSmuggler exploitation, despite being fully patched against previously known vulnerabilities — evidence the exploitation window opened before most operators had any signature to detect it. A separate attacker also used StyleSmuggler access to plant a PHP web shell under the product-image cache.
Adobe's hotfix, VULN-39341, shipped September 7 as an out-of-band fix; Adobe's advisory marks it "URGENT ACTION REQUIRED".
Why this is different from routine patch news
Most monthly vendor patch cycles are exactly that: routine. This one isn't, for three concrete reasons. First, the vulnerability is unauthenticated and needs no user interaction — an attacker doesn't need a compromised admin account or a phished customer, just network access to a vulnerable storefront. Second, exploitation predates the patch by three days, meaning "patch on the normal cadence" was never a safe option here. Third, Adobe's own remediation guidance goes beyond applying the hotfix: it explicitly tells merchants to rotate not only the Commerce encryption key but all credentials that may have been encrypted or exposed — admin passwords, REST/SOAP/GraphQL integration tokens, OAuth client secrets, payment gateway and database credentials, because a compromised instance may have already handed those out to an attacker before the patch existed. That's Adobe implicitly acknowledging that "patched" and "clean" are not the same state for anyone running an internet-facing Commerce or Magento instance in early September.
What this changes
If you run, host, or maintain an Adobe Commerce or Magento Open Source deployment, treat this as an incident-response task, not a maintenance-window task:
- Patch immediately if you haven't. Apply Adobe's VULN-39341 hotfix for CVE-2026-75650, and keep up with Adobe's regular Commerce security releases as well — a single out-of-band hotfix is not a substitute for staying current.
- Assume compromise until proven otherwise for any instance that was internet-reachable between September 4 and when you patched. Check for the specific persistence indicators Sansec published — processes named
[kworker/u:8:0],fc-cacheorchronydrunning under the web user's (non-root) account, files under~/.local/share/.gvfsd/or~/.cache/fontconfig/, unexplained cron entries, and PHP files under product-image cache directories. - Rotate secrets, following Adobe's guidance: encryption keys, admin credentials, API tokens, payment gateway credentials, and database passwords. Rotating only the application-level password after an RCE is not sufficient — assume the attacker had shell access.
- If you're on an older, unsupported Magento branch, this is a forcing function. Unsupported versions won't get this hotfix at all, and the attack requires no admin access, so being "off the radar" isn't protection.
For engineering teams evaluating platform risk more broadly, the pattern here — template-engine injection reachable through an unauthenticated, low-friction code path (an email reminder trigger) — is worth reviewing in any framework where user- or transaction-derived data can end up inside a template rendering context. It's a reminder that template engines are an attack surface, not just a rendering convenience.
If you need a second pair of hands auditing a Commerce or Magento install for exposure to this one, see Wise Hustlers' cybersecurity services.