SURIQ
Applying Adobe's hotfix is the easy part, and for anyone who ran a Magento storefront online last week it may also be the least useful thing they do. The maximum-severity flaw now tracked as CVE-2026-75650, which the researchers at Sansec named StyleSmuggler, was already being exploited in the wild on September 4, three days before a fix existed. That ordering is the point. A store patched today is safe from the next probe, but the update does nothing about a backdoor that a September 4 visitor may have dropped into cron before anyone knew the hole was there.
What is CVE-2026-75650?
CVE-2026-75650, or StyleSmuggler, is an unauthenticated remote code execution flaw in Adobe Commerce and Magento Open Source, scored CVSS 10.0. An attacker with no account poisons Magento's template layer, then triggers a routine "Payment Transaction Failed Reminder" email that runs the injected PHP. Every release from 2.4.4 through 2.4.9 is affected.
How a failed-payment email runs attacker code
Sansec describes a two-stage chain. First the attacker smuggles PHP into Magento's template system by abusing its styles properties, which lets the payload slip past the checks meant to keep code out of templates. Nothing runs yet. The second stage makes Magento render one of its own stock notices, the "Payment Transaction Failed Reminder" email, and that render step executes the poisoned template. No login, no user interaction, no exotic configuration. It turns the store's ordinary dependency-injection and email plumbing into a remote shell.
Two things make this worse than a typical storefront bug. It needs no authentication, so exposure is simply "is the store reachable from the internet." And Sansec reproduced the full chain on clean installs of 2.4.7, 2.4.8 and 2.4.9, so this is not a misconfiguration you can blame on a customized theme. If you run a stock, patched-until-last-week Magento, you were in scope.
Exploited three days before the fix
The timeline is the reason this one deserves a runbook, not just a change ticket. Sansec logged the first confirmed exploitation on September 4 at 22:20 UTC. Adobe published bulletin APSB26-146 with the VULN-39341 hotfix on September 7. CISA added the CVE to its Known Exploited Vulnerabilities catalog on September 8 and set a federal remediation deadline of September 11, a three-day window that is far tighter than the usual weeks CISA grants and a fair signal of how seriously it is treating this.
So there is a hard fact every operator has to sit with: for at least three days, a working exploit was in circulation and no patch existed. This is the second actively exploited Adobe flaw we have flagged this quarter, after the ColdFusion attacks in July, and it lands weeks after we covered a separate Adobe Commerce account-takeover flaw. The rendering and template layer keeps being the way in. A storefront that is reachable, holds payment data, and shares a codebase with tens of thousands of others is a target that rewards attackers for moving first, and they did.
Why the hotfix does not clean a store that was already hit
Patching closes the injection path. It does not touch anything an attacker planted while the path was open, and that is where most of the damage will live. Sansec reports that successful exploitation drops a Rust-based Linux backdoor that reinstalls itself from cron and hides under process names lifted from normal Linux housekeeping: kworker, fc-cache, and chronyd. It calls home on UDP port 123 dressed up as NTP traffic, using fallback domains that imitate time-sync services. A separate actor was seen dropping a PHP web shell under pub/media that answers with a 404 to any request missing a secret header, so a casual scan of the store finds nothing.
This is the same trap we described with Ivanti Sentry and with the Exchange web-shell chain: the patch is the start of the work, not the end of it. If your store was internet-facing between September 4 and the moment you patched, the correct posture is assume-breach until you have proven otherwise. Grep for the implant, do not trust an uptime graph.
Detect it, then rotate what the intruder could read
The single most useful detection here is watching for files that should never exist. Magento's pub/media tree serves images and cache, not code, so any freshly written .php under it is a red flag on its own. File-integrity monitoring is built to catch exactly that, a new executable appearing where executables never belong, and it does not care whether the web shell is obfuscated. Pair it with process and cron inspection for the persistence, and with threat hunting across the fleet if you run more than one store. Feed the affected versions into your vulnerability detection so the next unpatched instance surfaces on its own rather than in an incident call.
find pub/media -name '*.php' -newermt '2026-09-04' ps -eo pid,comm,args | grep -iE 'kworker|fc-cache|chronyd' crontab -l | grep -iE 'gvfsd|fc-cache|chrony' Persistence cron entries (every few minutes): */5 * * * * exec <home>/.local/share/.gvfsd/gvfsd-user 13,43 * * * * <home>/.cache/fontconfig/fc-cache 57,27 * * * * /tmp/.chrony-<8hex>/chronyd Implant paths: ~/.local/share/.gvfsd/gvfsd-user ~/.cache/fontconfig/fc-cache /tmp/.chrony-<8hex>/chronyd Web shell: pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php (returns 404 unless an X-Cache-Token header is present) Network: C2 99.84.67.186:443 (WebSocket over TLS) and 185.157.160.251 UDP/123 callback posing as NTP; domains ntp.timesync.to, ntp.synctime.to Application signal: a burst of "Payment Transaction Failed Reminder" emails
Rotate the encryption key before you trust the storefront again
If you find nothing, patch to a build that carries VULN-39341 and move on. If you find anything, or you were exposed in the window and cannot rule it out, the step most operators skip is the one that decides whether the attacker keeps their access: rotate credentials. Adobe's guidance starts with the store's encryption key and then every secret that key protected, which covers the admin passwords, the integration tokens for REST, SOAP and GraphQL, OAuth secrets, the payment-gateway and database credentials, SSH and deploy keys, and any keys held by third-party extensions. Rotating the key while leaving the tokens it wrapped in place hands the intruder a set of still-valid credentials to walk back in with. Patch, hunt, then rotate, in that order, and treat any store you cannot clear as one to rebuild rather than reassure.