9 SEP 2026 — Adobe has released an emergency hotfix for CVE-2026-75650, an unauthenticated remote code execution flaw in Adobe Commerce and Magento Open Source scored at CVSS 10.0 and exploited since at least 4 September. Applying the hotfix is not the whole remediation. The advice is to rotate the Commerce encryption key and every credential it protected, and that is the step that will be skipped.
How the attack works
Sansec, which found it, calls the technique StyleSmuggler. An unauthenticated caller smuggles PHP into Magento's template engine through styles properties, and the code executes when Magento renders its own Payment Transaction Failed Reminder email.
That last detail is what makes it awkward to detect. The malicious payload is not executed by the attacker's request; it runs later, when the store's own scheduled mail job processes a failed transaction. Request and execution are separated in time and appear in different logs.
Observed payloads deploy a Rust backdoor and a PHP web shell. Every version from 2.4.4 up to and including 2.4.9 is affected, and the fix is a composer hotfix, VULN-39341, rather than a minor release.
Why the key rotation is the real work
Magento's encryption key protects stored credentials — payment gateway keys, API tokens, integration secrets. Remote code execution on the store gives an attacker the key and therefore everything it protects.
Patching removes the way in. It does nothing about credentials already taken, which continue to work against the payment gateway and every integrated service until they are individually rotated.
This is the difference between fixing a lock and changing the locks. Only one of them helps if somebody has already been through the door, and the exploitation window opened three days before the fix existed.
The detection problem is worse than usual
Because execution happens during an email render rather than during the attacker's request, the usual first move — searching web logs around the time of compromise — can come back clean on a store that was fully compromised.
What to look for instead is the artefacts. An unexpected Rust binary, a PHP file in a directory that should hold no executable code, modifications to template records, and unexplained outbound connections from the application host.
Backups deserve the same suspicion. A store patched from a backup taken after 4 September may restore the web shell alongside the data, and a shop that responds to this by rolling back has a reasonable chance of reinstating the compromise.
Who this reaches
Magento's install base skews toward mid-market retail: shops large enough to run their own platform and small enough to have no security team. In Southeast Asia it is a common choice for merchants who outgrew a hosted storefront and did not move to an enterprise suite.
Those are also the merchants least likely to have a composer-based deployment pipeline that makes a hotfix routine, and most likely to be running a version several point releases behind because upgrades break themes.
The credential rotation compounds that. A merchant who applies the hotfix has done the part with instructions; rotating a payment gateway key means coordinating with a payment provider, and that is where the remediation stalls.
A hotfix is not a release
The fix ships as a composer hotfix rather than a minor version, and that choice has consequences beyond speed. A hotfix applies to the version already installed, which lets a store on 2.4.6 patch without the upgrade work a version bump would force.
It also means the patch is easy to lose. A merchant who later upgrades, redeploys from a build pipeline that pins package versions, or restores a container image can silently revert to unpatched code, because the hotfix is an addition to the dependency set rather than a property of the version number.
Anyone applying it should record that they have, and check for it again after the next deployment. The version string will not tell them.
The pattern this week
This is the third case in a week where exploitation preceded the fix. MikroTik routers were being taken over three days before RouterOS was patched, and N-able shipped its fourth N-central hotfix in five weeks against a flaw already in use.
All three are CVSS 9.2 or above, unauthenticated, and against software sitting at an internet-facing edge. That is not a coincidence of one week; it is where the return on an exploit is highest, and it is the class of software most likely to be run by an organisation with no one on call.
The practical consequence is the same in each case. Patch day is not day zero, so an exposed system needs examining rather than merely updating, and the examination is the part with no button to press.
View author profile → · Editorial policy
