DEV Community

Anoymask
Anoymask

Posted on

StyleSmuggler: Unauthenticated RCE via Adobe Commerce Failed Payment Email Rendering

#security #threatintel

1. Basic Information

2. Executive Summary

StyleSmuggler, tracked as CVE-2026-75650, allows an unauthenticated attacker to execute code on a vulnerable Adobe Commerce or Magento Open Source installation.

The attack injects PHP into content processed by the template system, then triggers execution while the server renders a failed payment email. No recipient needs to open the email, and successful email delivery is not required.

Sansec reported active exploitation involving a Rust-based backdoor. Applying the hotfix addresses the vulnerability but does not remove malware or invalidate credentials already exposed during a compromise.

3. Attack Flow

  1. An unauthenticated attacker sends a crafted request to a vulnerable storefront.
  2. The attacker abuses template processing, including styles properties, to place PHP in content such as a template or failure report.
  3. Server-side rendering of a failed payment email causes the injected PHP to execute in the application's security context.
  4. In reported attacks, the resulting code execution deploys a Rust-based backdoor. Other observed payloads include PHP web shells and should not automatically be attributed to the same actor.
  5. Depending on the backdoor variant, it communicates through WebSocket over TLS or NTP-like traffic on UDP port 123.
  6. Persistence and relaunch behavior vary between observed installations. Some use cron; others have relaunched without a cron entry.

A parent PID of 1 does not, by itself, identify the mechanism responsible for relaunching a process.

4. Attacker Position and Execution Context

  • The attacker can reach the vulnerable web application remotely.
  • Authentication and email-recipient interaction are not required.
  • Initial code execution occurs in the application or web-service process context. It should not be described as root access without supporting evidence.

5. Visibility for Victims and Administrators

Customers and Store Operators

Customers do not need to open a malicious email for this attack to succeed. Store operators may notice unexpected bursts of failed payment notifications.

Such notifications are an investigation lead, not proof of exploitation: legitimate payment failures can also generate them.

Administrators

Relevant evidence may include altered templates or failure reports, unauthorized PHP under pub/media, unexpected processes, and new or modified cron entries.

Some backdoor variants use names such as [kworker/u:8:0], fc-cache, or chronyd. These names must be evaluated together with executable paths, file integrity, process behavior, and network activity.

6. Success and Failure Conditions

Conditions for Code Execution

  • The installation is vulnerable and the applicable fix has not been applied successfully.
  • The crafted input reaches the vulnerable processing path.
  • The injected PHP reaches server-side rendering and executes.

Conditions for Later Payload Activity

  • Deploying or running a backdoor requires the necessary permissions and a compatible execution environment.
  • Communication with an external C2 endpoint requires a usable outbound path.

Blocking outbound traffic may disrupt a backdoor without preventing the initial server-side code execution.

Risk Reduction and Recovery

  • Apply Adobe's applicable VULN-39341 hotfix and verify successful installation.
  • Follow Adobe's version-specific guidance. The hotfix's tested compatibility range is not identical to every version described as vulnerable.
  • Preserve evidence and investigate existing compromise before treating the installation as clean.
  • Remove confirmed malicious files, persistence entries, and backdoors, and block identified malicious destinations.
  • Follow Adobe's credential-rotation procedure, including encryption-key rotation and replacement of potentially exposed credentials at the systems that issue or validate them.

Do not indiscriminately delete legitimate PHP files or cron jobs, or classify all NTP traffic as malicious.

7. Potential Impact

The following includes possible consequences, not damage confirmed at every affected store:

  • Arbitrary code execution in the web application's security context.
  • Installation of backdoors or web shells.
  • Persistence and continued unauthorized access.
  • Exposure of application secrets and credentials.
  • Access to customer, order, or payment-related information where the compromised process has sufficient access.

Sansec described transmission of host and system information by the backdoor. This is distinct from proof that customer or payment data was stolen.

8. Observable Logs

Inference: The following sources can support an investigation, depending on available logging.

  • Email: Review application and delivery records for failed payment email generation. Correlate timestamps and unusual volumes with web activity. Email opens are not relevant to triggering this RCE.
  • Web / WAF / Proxy: Review suspicious requests and affected processing paths. The ability to inspect injected values depends on whether the relevant headers, parameters, or bodies were captured. Ordinary access logs may be insufficient.
  • DNS: Check resolution of known malicious destinations, while preserving the time and source host associated with each query.
  • Endpoint / EDR: Examine templates, failure reports, unauthorized PHP under pub/media, executable paths, process command lines, file changes, and cron entries.
  • Identity / IdP: Where relevant, investigate subsequent use of exposed administrative or integration credentials. Authentication logs alone cannot establish the initial exploit.
  • Application / Cloud Audit: Review template processing, payment failures, administrative changes, and access to sensitive configuration.
  • Network: Correlate TLS/WebSocket connections and suspicious UDP/123 traffic with the originating process and destination. Reported later variants send bursts of nine 48-byte datagrams roughly every minute; this pattern is a hunting clue, not a standalone verdict.

9. Determining Attack Success

Inference: These criteria separate investigation stages. They do not imply that every reported incident reached every stage.

  • Suspicious Activity — Success Unconfirmed: A crafted request or unexplained increase in failed payment emails warrants investigation. Email volume alone does not prove an attack.
  • Initial Execution Confirmed: Process evidence, execution output, or attributable subsequent behavior establishes that the injected PHP ran. Storing PHP in a template is not sufficient.
  • Malware Execution Confirmed: Evidence establishes execution of the backdoor or another malicious payload. Persistence should be assessed separately and is not required to prove execution.
  • Information Exposure or Theft Confirmed: Evidence establishes unauthorized reading or transmission of protected information. Distinguish host telemetry from application secrets and customer data.
  • Follow-On Compromise Confirmed: Evidence establishes additional commands, payload execution, credential abuse, or compromise of another system.

10. Investigation Playbook

Inference: The following steps apply the reported attack mechanism to an organizational investigation.

  • Initial Assessment: Identify the product, branch, patch level, hotfix status, exposure, and relevant incident timeline.
  • Evidence Preservation: Preserve suspicious requests, application logs, templates, failure reports, unauthorized files, running-process details, and network records.
  • Execution Review: Establish whether injected PHP executed and identify its process context and subsequent actions.
  • Persistence Review: Examine cron entries and other evidence of relaunch behavior. Compare process paths and agent identifiers across observed restarts without assuming a mechanism from the parent PID.
  • Secrets Review: Investigate possible access to the Commerce encryption key, configuration, integration credentials, and other sensitive material.
  • Containment and Recovery: Restrict malicious access and communication, apply the fix, eradicate identified persistence, and follow Adobe's recovery and credential-rotation guidance.
  • Assessment: Record request delivery, PHP storage, execution, malware activity, persistence, and information transmission as separate findings.

11. Defense and Detection Ideas

Inference: These are operational proposals.

  • Single Events: Investigate suspicious template changes, unauthorized PHP, unexpected processes, and anomalous failed payment notification bursts.
  • Time-Series Correlation: Correlate web requests, server-side rendering, file creation, process execution, and outbound communication.
  • Hunting: Combine executable paths, file integrity, cron changes, and network behavior. Do not trust or condemn a process solely because it is named chronyd or fc-cache.
  • Actor Separation: Do not assume that a PHP web shell and a Rust implant found on the same store belong to the same attacker.
  • Log Gaps: Missing request bodies or email delivery failures do not rule out code execution. Use file, process, application, and network evidence together.
  • Priority Measures: Verify the hotfix, investigate pre-patch exposure, remove confirmed persistence, and rotate potentially exposed credentials.

12. Facts / Inference / Hypothesis

Facts

  • Sansec reported active exploitation beginning on September 4, 2026.
  • Adobe released APSB26-146 on September 7 and confirmed exploitation in the wild. The bulletin rates CVE-2026-75650 as critical, with a CVSS score of 10.0 and no authentication requirement.
  • Sansec describes a two-stage mechanism: PHP injection into template-related content followed by execution during server-side rendering of a failed payment email.
  • Sansec reports affected Adobe Commerce and Magento Open Source versions from 2.4.4 through 2.4.9.
  • Adobe's bulletin lists Adobe Commerce branches 2.4.4–2.4.9, Magento Open Source branches 2.4.6–2.4.9, and specific B2B releases: 1.3.3, 1.3.4, 1.4.2, 1.5.2, and 1.5.3, including the listed August 2026 builds and earlier versions. These source scopes should not be treated as identical.
  • The reported Rust backdoor uses several disguised process names. Cron-based persistence and relaunch without a cron entry were observed in different examples.
  • Later variants transmit host and system information through NTP-like UDP traffic.
  • Sansec's September 7 report did not establish subsequent operator-command activity through the Rust backdoor. This does not mean that no information was transmitted.

Inference

Detection based on email opens or successful delivery would miss the triggering condition. The relevant event is server-side rendering and its relationship to subsequent execution.

Hypothesis

No additional hypotheses. Remaining uncertainties are listed below.

13. MITRE ATT&CK Mapping

Inference: These mappings apply to the relevant observed behaviors, not automatically to every compromised store.

  • T1190 Exploit Public-Facing Application — High Confidence: Exploitation of the vulnerable storefront.
  • T1505.003 Server Software Component: Web Shell — High Confidence: Installation of a PHP web shell in the separately reported payload activity. PHP execution alone does not establish a web shell.
  • T1053.003 Scheduled Task/Job: Cron — High Confidence: Cron-based persistence in examples where a malicious entry was observed.
  • T1071 Application Layer Protocol — High Confidence: Use of application-layer communications for backdoor command and control.

14. Unknowns and Further Investigation

  • The total number of compromised stores and attribution of each observed payload.
  • The commands executed by operators after backdoor deployment.
  • Whether customer, order, or payment-related data was accessed or transmitted in each environment.
  • Which encryption keys and credentials were exposed.
  • The precise relaunch mechanism in examples without an identified persistence entry.

15. Impact on SOCs and Organizations

E-commerce operators should verify the specific hotfix rather than rely on a general version label or an earlier clean patch-status check.

Patching and incident recovery are separate tasks. A patched store may still contain a backdoor or exposed credentials from an earlier compromise. Review historical application activity, files, processes, persistence, and network connections.

Encryption-key rotation alone does not invalidate credentials an attacker has already obtained. Follow Adobe's procedure and replace affected credentials at their issuing services, then update the Commerce configuration accordingly.

16. Summary by Target Audience

  • For SOCs: Correlate suspicious requests, failed payment email rendering, PHP execution, and backdoor activity. Distinguish attempted exploitation, confirmed execution, host-information transmission, and theft of business data.
  • For Administrators: Apply and verify the applicable hotfix, investigate existing compromise, and follow Adobe's credential-rotation guidance. Avoid indiscriminate removal of legitimate files, scheduled tasks, or time-synchronization traffic.
  • For Store Operators: Escalate unexplained bursts of failed payment notifications to the technical team. The attack occurs on the server and does not require a customer or administrator to open an email.

Top comments (0)