Magento CVE-2026-75650: patch, then rotate everything the key touched

What broke

CVE-2026-75650 is an unauthenticated remote code execution flaw in Adobe Commerce and Magento Open Source. Adobe published the fix in bulletin APSB26-146 on 7 September with a priority 1 rating. Sansec, who found it, calls it StyleSmuggler — that name is theirs, not Adobe’s, so expect to see both.

The class is CWE-1336, improper neutralisation in a template engine. Conceptually it runs in two stages: an attacker gets malicious code stored in the application’s data — for instance by causing a failure report to be generated — and Magento then executes that code later, while rendering an email. The styles properties are what let it slip past existing safeguards, hence the name.

Adobe PSIRT scores it 10.0. Worth knowing that this is Adobe’s own score as CNA; NVD has not published a primary score of its own. The Scope:Changed metric is what takes it to a perfect ten.

Sansec has not published the full gadget chain yet, and this post is not going to speculate about it.

Who is affected

There is a discrepancy in that table worth taking seriously. Adobe’s bulletin lists Magento Open Source from 2.4.6, but Sansec states every version from 2.4.4 onward is affected, and notes Adobe tested the hotfix as far back as 2.4.4. If you run 2.4.4 or 2.4.5 Open Source, treat yourself as in scope rather than out of it.

Being fully patched was not a defence. Sansec’s first confirmed victim was running 2.4.6-p15 with the July and August 2026 patches applied and a clean security:patch-status. This was a zero-day; patch discipline bought nothing.

Is it being exploited?

Yes, and it was being exploited before a fix existed.

Sansec’s timeline puts first confirmed exploitation at 4 September, 22:20 UTC. Adobe’s hotfix landed on 7 September. That is roughly three days of exposure with nothing to apply.

Within 50 minutes of that first confirmed attack, Sansec’s scanner was flagging the same implant on unrelated stores. Some coverage has rendered this as a single server being fully compromised in 50 minutes; the primary source says something a little different and, frankly, more alarming — that is how quickly it was spreading across unconnected victims.

CISA added it to the KEV catalog on 8 September with a remediation deadline of 11 September — a three-day clock, issued under BOD 26-04. The KEV entry also carries forensicTriage: Yes, meaning affected agencies are expected to investigate, not merely patch.

A note on EPSS

CVE-2026-75650 currently scores 0.00676 on EPSS — roughly the 50th percentile.

If your prioritisation pipeline keys on EPSS, this vulnerability looks utterly unremarkable: actively exploited, in KEV with a three-day deadline, CVSS 10.0, and sitting at 0.68%. EPSS is a prediction trained on observed exploitation over time, so it lags hardest exactly where it matters most — on brand-new zero-days. For comparison, last year’s SessionReaper (CVE-2025-54236) now sits at 0.945, but it did not start there either.

Do not let anyone read 0.68% as “we have time.”

What to do

1. Apply the hotfix. VULN-39341, distributed as VULN-39341-composer-patches.zip from repo.magento.com and applied as a composer patch. This is a hotfix, not a full release. Confirm it took:

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

2. Scan before you assume you are clean. Patching does not remove an implant that is already there. Adobe is explicit that rotation alone does not invalidate credentials an attacker already holds.

3. Rotate — and rotate wider than the encryption key. This is the step that gets skipped, and skipping it makes the patch cosmetic. Successful exploitation exposes the Magento encryption key, which protects stored integration and payment configuration. Rotate at the source, not just inside Magento:

• The Magento encryption key
• All admin passwords
• REST, SOAP and GraphQL integration tokens; OAuth client secrets
• Payment gateway API credentials — at the provider, not in Magento’s config
• Database credentials, SSH and deploy keys
• Third-party extension API keys

On cloud deployments, redeploy after rotating.

How to detect it

Start with the email. The execution trigger is Magento’s standard Payment Transaction Failed Reminder. An unexplained burst of those is an investigation trigger. Nobody needs to open the email — the code runs at render time, and the attack works even if delivery fails.

Process names. The implant masquerades as an ordinary system process: [kworker/u:8:0], fc-cache, chronyd, or gvfsd-user. The chronyd choice is deliberate — it invites an analyst to dismiss it as the legitimate time daemon.

Sansec’s checks:

crontab -l | grep -i gvfsd
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'

Two caveats on those, both important:

• Persistence is written straight into the cron spool file rather than through crontab -e, so there is no REPLACE line in syslog to find.
• One build relaunches with no cron entry at all. An empty crontab is not evidence of a clean host.

The strongest signal is on the network. The implant’s command-and-control mimics NTP, and does it imperfectly in two ways you can alert on:

• It emits nine 48-byte datagrams roughly 10ms apart, every 60 seconds. A real NTP client sends one.
• Every datagram is marked NTPv4 server mode. A client has no reason to ever send that.

Either one on its own is a usable rule. Together they are close to unambiguous.

Other indicators: malware download host 247.cdnflare[.]xyz; a truncated User-Agent matching no real browser, Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36.

Do not stop at the background process

Sansec observed a second, unrelated actor on the same victims, dropping a small PHP web shell into pub/media/catalog/product/cache/ under randomised directory names. It returns 404 unless a specific request header is present, which is why casual crawling of the media directory will not find it. It was preceded by reconnaissance that exfiltrated over chunked DNS labels.

Finding and removing the Rust implant does not mean the host is clean.

The part worth remembering

Session storage hardening did not help. One merchant watched an attempt fail against session storage and succeed eight seconds later through a file uploaded via Magento’s custom options.

There is no configuration that saved anyone here, and there was no patch to apply for three days. What was actually under each operator’s control was the second half: how fast the hotfix went on once it existed, and whether the credential rotation happened. That second part is still, for a lot of stores, undone.

References

• Adobe Security Bulletin APSB26-146
• Adobe Commerce Knowledge Base — APSB26-146 remediation guidance
• Sansec — StyleSmuggler 0-day research and IOCs
• NVD — CVE-2026-75650
• CISA Known Exploited Vulnerabilities catalog