First victim ran the supported version with July and August updates applied already. The patching was neither late, nor incomplete nor irresponsible. It just had no effect at all.
This is the nature of the so-called zero-day, and one should dwell upon it before going on.
Magento is the software a merchant installs to run their own online store. It covers the catalogue, the checkout, customer accounts and order history. Adobe bought it in 2018.
What it is not matters more here. Magento is not a hosted service that maintains itself in the background. The merchant owns the server, the updates and the patching schedule, so nobody applies a fix on their behalf. It is also not a shop window sitting in front of the real system. The store itself holds payment gateway credentials, integration tokens and customer records. That is why code execution here reaches so far.
What is CVE-2026-75650? Named StyleSmuggler, CVE-2026-75650 is a critical vulnerability affecting Adobe Commerce and Magento Open Source, with CVSS 10.0 rating. This flaw allows a remote attacker to inject arbitrary PHP code in the template engine of the store and run it during generation of the payment failure notification.
How A Failed Payment Email Runs Attacker Code
Emails in Magento use template-based content creation which uses styles as well. The exploit exploits the styling pathway to bypass all the existing defenses against such vulnerabilities in the template rendering process.
It is performed in two steps. The first step is inserting the PHP code by forcing the store to create a payment failure report. Next, the store will generate its default “Payment Transaction Failed Reminder” email.
The generation of the email will execute the PHP code inserted earlier. The exploitation process requires no authentication nor any clicks from store administrators.
Adobe Commerce from version 2.4.4 to version 2.4.9 and Adobe Commerce B2B from 1.3.3 to 1.5.3 are vulnerable. The same issue exists in Magento Open Source.
Three Days With No Patch
Exploitation started on September 4 at 22:20 UTC. Adobe shipped the hotfix on September 7, as bulletin APSB26-146.
The speed in between is the part worth noting. One Magento server was compromised within 50 minutes of the flaw first being reported publicly.
The fix arrives as a composer patch rather than a full release, downloaded separately and applied by hand. That distinction matters for anyone who equates “we are on the latest version” with being protected.
We saw the same compression of the exploitation window when a maximum-severity Adobe ColdFusion flaw put servers at risk within hours.
Fully Updated and Still Vulnerable
| Product | Versions Affected | Status After Action |
|---|---|---|
| Adobe Commerce | 2.4.4 – 2.4.9 | Patched only once VULN-39341 is applied |
| Adobe Commerce B2B | 1.3.3 – 1.5.3 | Patched only once VULN-39341 is applied |
| Magento Open Source | Current 2.4 branches | Patched only once VULN-39341 is applied |
| Any of the above | Latest release installed | Still affected before the hotfix |
Two Different Attackers, One Hole
The malware delivered to these compromised stores is the work of not one, but of multiple threat actors.
First off is a backdoor written in Rust targeting Linux. It avoids detection in process lists by initially pretending to be a kernel thread. Further versions spoof fc-cache and chronyd. Any command communications are masked as clock synchronization, beacons going out to port 123 and claiming to be NTP. Every 60 seconds the malware reports the OS version, currently logged-in user, disk status and whether it possesses root privileges.
Persistence is achieved via cron jobs at random intervals, and the malware is able to self-restart regardless of cron jobs.
Another completely unrelated threat actor deployed a rather simple exploit. Their PHP-based dropper creates a web shell that hides within the product image cache folder, alongside randomly named folders that reside there naturally. This web shell responds only to requests containing a certain header, returning a regular 404 for all others.
The reconnaissance phase for the second threat group was performed via a GraphQL request containing PHP code in its header. That two independent groups exploited the same zero-day within days of each other demonstrates how quickly a good exploit turns into a commodity tool.
The Rotation List Is The Damage Assessment
The advice from Adobe goes further than just installing the patch. The merchants are advised to change the store’s encryption key, and then every piece of data which was encrypted by this key.
That is a rather long list of things. Admin passwords, REST, SOAP and GraphQL tokens, OAuth client secrets, payment gateway credentials, database access credentials, SSH keys, deploy keys, and third-party API keys.
All these things have to be changed at their source and not just in Magento. Changing the encryption key will not affect a secret which the hacker has already read somewhere else.
When The Question Is What It Touched
Was the store breached? The answer to that question lies in process identifiers, web shell, cron jobs, beacons masquerading as time synchronizations there is more than enough information for detection to work with if you know what you are looking for.
The trickier issue becomes the scope of the code’s execution, and it is this very credential rotation that exists in order to address the inability of log-based detection to close that knowledge gap. Evidence of detection is what was seen, it is not the scope of the unseen.
The difference is all the justification needed for the approach based on enforcement and not detection, as a control that restricts access to what the code cannot reach makes a different type of record altogether. Not of activity, but of boundaries that can be proven to exist, at least when dealing with a payment data store.
Conclusion: The Store Was Patched. The Code Still Ran.
The defining lesson from StyleSmuggler is that a fully patched system can still become the first victim when the vulnerability does not yet have a patch.
CVE-2026-75650 turned Magento’s template-rendering path into unauthenticated PHP code execution. The first confirmed victim was already running the available July and August security updates, with its patch status reporting clean. That posture was correct for the vulnerabilities known at the time. It offered no answer to a flaw defenders and the vendor had not yet had the opportunity to remediate.
What followed shows why the distinction matters. One attacker deployed a Linux backdoor that disguised itself as legitimate system processes, established cron persistence, and communicated through traffic shaped to resemble NTP. A separate actor exploited the same flaw to deploy a PHP web shell inside the product image cache. By the time Adobe released the emergency hotfix on September 7, exploitation had already been occurring for three days.
Why This Threat Matters
- Fully patched does not mean invulnerable. Patch compliance measures exposure to known flaws, not vulnerabilities that have not yet been disclosed or fixed.
- Unauthenticated RCE compresses the defensive window. No stolen account or administrator interaction is required before attacker-controlled code reaches the server.
- One vulnerability can support multiple operators. Independent actors quickly used the same execution path for different payloads and persistence methods.
- Post-exploit behavior can hide inside familiar system activity. Process names such as
fc-cacheandchronyd, together with NTP-shaped traffic, were used to make malicious activity resemble normal Linux operations. - Applying the hotfix does not erase earlier compromise. Systems exposed before remediation still require investigation for backdoors, web shells, cron persistence, and other changes.
- Credential rotation is part of impact recovery. If the store encryption key was exposed, the secrets protected by it must be rotated at their actual source, not merely re-encrypted inside Magento.
Where Defensive Control Must Operate
When no patch exists, defensive control has to extend beyond vulnerability status to what the exploit is allowed to execute.
Xcitium Advanced EDR, powered by Xcitium’s patented Zero-Dwell platform provides that runtime layer on supported managed systems. When exploitation produces an unknown backdoor, dropper, script, or other untrusted execution, Execution Governance governs what that code may do before trust exists rather than depending on the vulnerability already being known.
After disclosure, Xcitium Vulnerability Assessment becomes relevant for identifying affected infrastructure, missing remediation, and systems that have not received the emergency fix. It reduces the known exposure window. It does not retroactively make the zero-day discoverable before disclosure.
Patch the Store. Hunt What Ran Before the Patch.
Applying Adobe’s emergency hotfix closes the known exploitation path, but systems reachable during the zero-day window should not be considered clean on patch status alone. Backdoors, unexpected PHP files, cron entries, disguised processes, outbound communications, and exposed secrets need separate investigation and recovery.
StyleSmuggler demonstrates the boundary clearly. Patching answers what is known. Runtime control has to answer what happens when the unknown still executes.
