Skip to content

Build1 publisher3 min readPublished

A crafted style attribute in Magento's payment-failure reminder executes as PHP

Adobe scored CVE-2026-75650 at 10.0 and shipped hotfix VULN-39341 three days after Sansec first saw it exploited. The first confirmed victim was running 2.4.6-p15, the newest release, and it had passed a security status check.

The Engineer · Build desk

Illustration accompanying A crafted style attribute in Magento's payment-failure reminder executes as PHP

What happened

  • Adobe published advisory APSB26-146 with hotfix VULN-39341 for CVE-2026-75650 and scored it at CVSS 10.0, a flaw the Dutch security firm Sansec named StyleSmuggler.
  • Rendering the standard Payment Transaction Failed Reminder template resolves a style attribute that can carry PHP, and nothing in the pipeline stops it executing.
  • The affected list runs from Adobe Commerce 2.4.4 through 2.4.9 and Magento Open Source 2.4.6 through 2.4.9, including builds that already carried the August 2026 monthly patches.
  • Sansec observed exploitation from 4 September 2026 and Adobe shipped the hotfix on 7 September, leaving a three-day window against unpatched stores.
  • The post-exploitation payload is a small Rust backdoor that hides under process names such as fc-cache and chronyd. Those names keep it inconspicuous in a process listing.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • decision Any storefront reachable in early September has to be handled as a possible incident, because the hotfix shuts the path and leaves an earlier intruder exactly where they were.
  • cost Adobe's required rotation reaches payment gateway credentials, database accounts and SSH keys, so the cleanup work lands on teams that do not own the storefront.
  • exposure Two unrelated actors were working the same flaw within days, so one implant found on a compromised store leaves the investigation open.
  • constraint Merchants on 2.4.0 through 2.4.3 have no vendor patch, and the available backport puts the validation burden on their own staging environment.

The order of operations is what makes this cheap to run. First the attacker writes PHP into data that Magento generates itself, such as a payment failure report [5]. Then the standard reminder email is triggered, and the renderer resolves the style attribute in that template with nothing in the pipeline preventing the attribute from carrying executable code [6]. The attack completes even if the email is never delivered [8], so the control point is the renderer. Adobe files the bug as CWE-1336, improper neutralization of special elements used in a template engine [4].

Adobe's affected list includes installations that had already applied the August 2026 monthly patches [13]. Sansec reported that the first confirmed victim was on 2.4.6-p15, the latest release at the time, and that it passed a security status check [14].

Adobe records the severity as 10.0 and NVD records 9.8 [2][3]. For an unauthenticated path to code execution as the web server user [7], the four-tenths matter less than the seven days between Sansec's first observed exploitation on 4 September and CISA's federal remediation deadline of 11 September [1]. CISA also required forensic investigation rather than just a patch [16].

On 7 September, the day the fix shipped, Sansec observed a second and unrelated attacker using the same flaw to write a 485-byte PHP web shell. Sansec's conclusion is that one compromised store can host intruders who are unaware of each other [17].

That implant hides under process names including [kworker/u:8:0], fc-cache and chronyd [9], and shapes its command and control traffic to resemble NTP over UDP port 123 [10]. Some variants copy themselves into the fontconfig cache directory and register a scheduled task that restarts them twice an hour, so a reboot does not remove them [11]. A smaller PHP web shell also turned up in the product image cache directory [12]. The published detection advice is to review pub/media for PHP files that should not be there, look for unexpected processes and scheduled tasks, and check for outbound traffic to UDP 123, with scanners including eComscan looking for the backdoor and secondary shells [21]. I'd expect that last indicator to be noisy on a host whose web tier syncs time directly to the internet.

Patching closes the path and leaves anyone who arrived earlier in place [20]. Adobe requires rotating the encryption key and all credentials, and the sequence is specified: encryption key first because it protects the downstream secrets, then administrator passwords, REST, SOAP and GraphQL tokens, payment gateway API credentials, database accounts and SSH keys [20]. Adobe-hosted stores received the update through the managed pipeline [18]. Stores on 2.4.0 through 2.4.3 are end of life, and Scandiweb published a backport that Adobe has not validated, so staging verification comes before production [19].

The account collecting this material says its descriptions come from vendor advisories and Sansec reporting without independent re-verification, that researchers have reproduced the exploitation chain, and that a public proof of concept exists [22].

What to watch

  • Whether Adobe validates Scandiweb's backport for 2.4.0 through 2.4.3, or leaves end-of-life merchants verifying it in their own staging.
  • New backdoor variants that drop the fontconfig cache path or the twice-hourly restart would age every published indicator list.
  • Reports of a third actor, or of implants dated before 4 September, would widen the investigation window Sansec's timeline sets.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories