John Cuthbert 
Update, 8 September 2026: Adobe has released an official patch. Adobe Security Bulletin APSB26-146 assigns this vulnerability CVE-2026-75650 (CVSS 10.0, Priority 1 — the highest rating Adobe issues) and ships hotfix VULN-39341. The original post below is left in place for the timeline; see the updated guidance in “Has Adobe Released a Patch?” and “What Should You Do Right Now?” below.
What Is StyleSmuggler?
StyleSmuggler is an unauthenticated remote code execution vulnerability affecting Magento, discovered and named by Sansec’s forensics team. It works as a two-stage attack: first, a crafted payload is submitted to a Magento endpoint (Sansec and independent researcher Sam James both cite
/graphql, with /paypal/transparent/response/ and /customer/section/load/ also named as possible vectors) and gets written into a Magento report or log file. Second, that payload executes when Magento renders its standard “Payment Transaction Failed Reminder” email
template — turning a routine store notification into a code execution trigger.
No authentication is required. This isn’t a theoretical proof-of-concept — Sansec’s forensics team confirmed the first real exploitation between 22:20 and 22:40 UTC on 4 September, and independently reproduced the full exploit chain on a clean install the following day.
Is Your Store Affected?
- Confirmed affected: Magento Open Source 2.4.7, 2.4.8, and 2.4.9
- At least one confirmed victim was running fully patched Magento Open Source 2.4.6-p15 — current security patches as of this writing do not prevent exploitation
- Adobe Commerce and Adobe Commerce Cloud are presumed affected pending official confirmation from Adobe
Has Adobe Released a Patch?
Yes, as of Adobe Security Bulletin APSB26-146. The fix ships as a hotfix rather than a full version release — download VULN-39341-composer-patches.zip from repo.magento.com and apply it as a composer patch. You can confirm it’s applied with vendor/bin/magento-patches -n
status | grep "39341\|Status".
Reported affected versions vary slightly by source — Adobe Commerce and Magento Open Source 2.4.4 through 2.4.9 and their patch trains, plus Adobe Commerce B2B, are all named as affected somewhere in the reporting. If you’re on an older 2.4.x train, don’t assume you’re out of scope — check the bulletin directly rather than relying on a version cutoff from a summary, this one included.
What Should You Do Right Now?
Apply the VULN-39341 hotfix immediately. But patching closes the door — it doesn’t evict anyone who already got in. Sansec confirmed attackers deployed a Linux backdoor and a PHP web shell on compromised stores during the exploitation window before this patch existed. If your store was running an affected version between 4 September and today, treat this as a suspected-compromise investigation, not just a patch task.
- Apply the VULN-39341 hotfix and confirm it’s active via the status check above
- Check for unfamiliar processes and unexpected files in your media/cache directories — Sansec’s follow-up research publishes specific indicators of compromise worth checking against
- If you find any sign of compromise, rotate everything: admin passwords, API keys, OAuth secrets, payment credentials, database credentials, and SSH keys — a patch does not undo an already-planted backdoor
- If you’re not confident checking this yourself, treat it as urgent — the cost of missing an active backdoor is much higher than the cost of a false alarm
Sam James’s independent write-up goes further, publishing a seven-part manual hardening patch (covering report serialization, file-inclusion path validation, and disabling failed-payment email rendering as a stopgap) along with indicators of compromise for teams hunting across a fleet of stores. If you’re managing Magento infrastructure directly, both the original Sansec research and Sam James’s response guide are worth reading in full — this post is a summary, not a substitute for the technical detail in either.
Need Help Right Now?
If you’re running an affected Magento or Adobe Commerce store and need someone to disable GraphQL, apply the manual hardening steps, or check your logs for signs of compromise today rather than after Adobe’s bulletin lands, that’s exactly what our technical support service is for. For stores that want this kind of thing caught and handled proactively going forward rather than reactively during an active exploit window, that’s the ongoing coverage a development retainer provides.
