Sansec disclosed an unauthenticated remote code execution (RCE) vulnerability in Magento Open Source and Adobe Commerce on September 5, 2026, naming the flaw StyleSmuggler. The researchers observed active exploitation as early as September 4 2026. Adobe released an emergency hotfix on September 7 under APSB26-146, assigned CVE-2026-75650 a CVSS score of 10.0, and confirmed that it is aware of exploitation in the wild.
The vulnerability affects every Magento branch from 2.4.4 through 2.4.9, as well as Adobe Commerce B2B 1.3.3 through 1.5.3. Sansec's first identified compromised store was running Magento 2.4.6-p15, with the July and August 2026 security updates already applied.
In this article, we break down how StyleSmuggler turns Magento's own logging mechanism into a code execution pathway, why a routine transactional email can trigger the malicious payload, and what attackers installed after gaining execution on compromised servers. Most importantly, we explain why patching alone is not sufficient for stores that may have been exposed during the exploitation window.
1. How the Magento styles Value Bypasses Validation
Adobe classifies StyleSmuggler as improper neutralization of special elements in a template engine (CWE-1336). According to Sansec, the attack begins with an unauthenticated request to Magento's GraphQL endpoint containing a malicious styles input. The significance of the styles property is that it provides a path for Magento template directive syntax to pass through validation and filtering mechanisms that are intended to reject such content. At this stage, the attacker does not immediately execute code. Instead, the malicious request causes Magento to reject the supplied value while still recording it verbatim. This results in attacker-controlled PHP source code being written into a file generated by the application, such as:
- var/log/system.log
- An error report under var/report/
This creates the foundation for the second stage of the attack: the attacker has successfully poisoned a Magento-generated file with executable PHP code.
2. How a Failed Payment Email Triggered Code Execution
The second stage of the StyleSmuggler attack causes Magento to read and execute the poisoned file. The trigger is particularly notable because it involves the platform's Payment Transaction Failed Reminder email. When this transactional email is generated, the injected template directive passes through Magento's template filtering process. From there, attacker-controlled parameters direct execution through internal Magento classes until a dependency injection compiler scanner receives a file path and passes it to PHP's include mechanism.That file path points back to the log file compromised during the first stage. When Magento reads the file, the injected PHP code is executed.
Researchers at Disrex place the vulnerable execution sink in scanner methods designed to support setup:di:compile. These methods are intended for dependency-injection compilation and are not normally expected to execute as part of a web request. The attack therefore creates an unusual chain:
Crucially, the attacker does not need someone to open or interact with the email. The email-generation process itself reached to the execution path. This makes the technique a particularly stealthy form of local file inclusion escalation where an attacker first places executable content into a local file and then abuses application functionality to have that file interpreted as PHP.
3. What Attackers Installed After Gaining Magento RCE
Achieving remote code execution is only the beginning of the compromise. Sansec's indicators show that attackers used the access to establish persistent background processes on compromised servers. One observed payload masqueraded as a Linux kernel thread named kworker. The malicious binary was stored under the site user's home directory, outside the web root, making it less likely to be discovered by scans focused exclusively on Magento's application files. Disrex identified the malware as a stripped, statically linked Rust binary measuring approximately 1.9 MB.
The attackers also established persistence through a cron entry written to the user's spool file. This allowed the malicious process to restart automatically on a short cycle, meaning that simply terminating the running process would not necessarily remove the compromise. Later samples used filenames including fc-cache and chronyd. The chronyd variant was particularly notable because it generated traffic resembling NTP, potentially allowing malicious communications to blend into legitimate network activity where port 123 is permitted. The combination of a binary outside the web root and cron-based persistence illustrates why post-exploitation hunting is critical in a StyleSmuggler incident.
4. Why Applying the Magento Hotfix Is Not Enough
Applying Adobe's emergency hotfix closes the vulnerable entry point but it does not remove malware or persistence mechanisms that may already have been installed. This distinction is critical for any Magento or Adobe Commerce store that was exposed before the patch became available. Because the implant can reside outside the Magento web root, a scan restricted to the store's application directory may return a clean result even while a malicious process continues running on the server. Likewise, killing the malicious process is not sufficient if the corresponding cron entry remains in place. The persistence mechanism can simply launch the malware again. Adobe recommends rotating the encryption key and every credential protected by it, including:
- Admin passwords
- Integration tokens
- OAuth secrets
- Payment gateway API credentials
- Database credentials
- Deployment keys
More broadly, any credential or secret that was accessible to the compromised application during the exploitation window should be considered potentially exposed. This is especially important for e-commerce environments, where compromised credentials can provide access to payment systems, customer data, infrastructure, and other connected services and can have a known resale value on underground markets. For this reason, incident response should include both remediation and credential rotation, rather than treating successful patch installation as proof that the incident is resolved.
5. What StyleSmuggler Teaches Us About Magento Security Testing
StyleSmuggler demonstrates how a high-impact vulnerability can emerge from the interaction of several individually complex components: input handling, template processing, application logging, and a file-include mechanism that was never intended to operate in a web-request context. Finding this type of vulnerability requires more than scanning for known CVEs or testing individual endpoints in isolation.
Effective web application penetration testing should trace attacker-controlled input through the application framework, determine where that input is stored or transformed, and identify whether it can ultimately reach a dangerous execution sink. For Magento and Adobe Commerce environments, this should include:
- Testing the storefront and GraphQL/API attack surface
- Manually validating security-sensitive input-handling behavior
- Tracing user-controlled data through template and rendering workflows
- Identifying unexpected file-write and file-include paths
- Chaining related weaknesses to demonstrate real-world impact
- Providing prioritized remediation recommendations
- Conducting a retest after remediation
StyleSmuggler is a good example of why application security testing needs to follow data flows and execution paths, rather than simply checking whether individual security controls appear to work in isolation. Merchants running Magento or Adobe Commerce should assume exposure across the September 4 to September 7 window and check the server itself for the indicators, Sansec published. The hotfix is necessary, and on its own it is not evidence that a store is clean.
If you're looking to strengthen your cybersecurity posture or assess your organization's exposure to similar risks, we're here to help. Book a consultation at https://calendly.com/laburity/meeting, reach out to us at [email protected], or learn more about our services at https://laburity.com/.
