StyleSmuggler runs its PHP inside Magento's failed-payment email renderer

The sink is what makes this chain awkward to defend. In Sansec's description the request that plants the payload is not the event that runs it: template processing, including `styles` properties, places PHP into content such as a template or a failure report ^[5], and execution comes later, when the server renders a failed payment email in the application's own security context ^{[4] [6]}. The two steps land in two separate log lines, with the payload written in one and the code executed in the other.

The first operational symptom looks legitimate. Sansec says operators may see unexpected bursts of failed payment notifications, and calls that an investigation lead rather than proof, because real payment failures produce the same bursts ^[16]. What separates the two sits on disk: altered templates or failure reports, unauthorized PHP under `pub/media`, unexpected processes, and new or modified cron entries ^[17].

The backdoor is built to survive a shallow cleanup. Variants talk WebSocket over TLS or NTP-like traffic on UDP port 123 ^[9], and run under names including `[kworker/u:8:0]`, `fc-cache` and `chronyd` ^[12]. A process called `chronyd` sending UDP 123 is also what a working clock looks like, which is presumably why Sansec's guidance warns against classifying all NTP traffic as malicious ^[22] and tells responders to weigh executable paths, file integrity, process behaviour and network activity before calling any of these names ^[12]. Persistence varies between installations: some use cron, and some have relaunched without a cron entry at all ^[10]. A parent PID of 1 does not identify what restarted a process ^[11]. Removing the cron job addresses only one persistence path, and installations that relaunch without a cron entry will keep running regardless.

Applying the `VULN-39341` hotfix and verifying the install ^[14] closes the entry point and does nothing else, because the fix neither removes malware nor invalidates credentials already exposed during a compromise ^[13]. Patching accounts for only two of the five documented response steps: the hotfix, plus Adobe's version-specific guidance. The other three are incident response: preserve evidence before treating the store as clean ^[20], remove confirmed malicious files, persistence entries and backdoors and block identified destinations ^[21], then run Adobe's credential-rotation procedure, which includes encryption-key rotation and replacing potentially exposed credentials at the systems that issue or validate them ^{[19] [1]}.

The material does not support several claims worth naming. Initial execution is in the web application or web-service process, and Sansec says explicitly that it should not be described as root access without supporting evidence ^[6]. PHP web shells were also observed, and should not be attributed automatically to the same actor as the Rust backdoor ^[8]. Blocking outbound traffic may disrupt a backdoor without preventing the server-side execution that installed it ^[18]. And the hotfix's tested compatibility range is not identical to every version described as vulnerable ^[15], which is how a Critical ^[3] advisory turns into an argument about which build you are actually allowed to deploy tonight.