StyleSmuggler Magento vulnerability: what to do now
Apply Adobe's StyleSmuggler hotfix for CVE-2026-75650, verify installation and check your Magento or Adobe Commerce store for compromise.
Last reviewed:
The short answer
StyleSmuggler is the name given by Sansec to an unauthenticated remote-code-execution vulnerability affecting Magento Open Source and Adobe Commerce. Sansec says attacks began on 4 September 2026 and that stores are being compromised in the wild.
A patch is available. Adobe released the VULN-39341 hotfix for CVE-2026-75650 on 7 September 2026 in bulletin APSB26-146. Adobe rates the vulnerability critical, with a CVSS score of 10.0 and priority 1, and confirms exploitation in the wild. Apply the appropriate hotfix urgently; do not wait for the next routine upgrade.
How StyleSmuggler reaches code execution
Sansec describes an attack that places malicious code in files Magento can read and abuses template rendering through styles parameters. Failed-payment emails are one execution path, but its updated research also describes execution without an email.
Nobody needs to open an email for the attack to work. A quiet inbox, failed email delivery or a change in session storage is not proof that a store is protected.
Which Magento versions are affected?
Adobe's bulletin lists affected Adobe Commerce branches from 2.4.4 to 2.4.9, Magento Open Source branches from 2.4.6 to 2.4.9, and listed Adobe Commerce B2B releases. The listed 2026-aug builds and earlier versions are affected. An August security update alone does not address this vulnerability.
Adobe's hotfix instructions, updated on 21 September, also provide version-specific packages for earlier builds, including 2.4.4 and 2.4.5. Match your exact product and version to Adobe's current download table; do not assume one patch fits every release. If your version is absent, seek supported remediation advice rather than assuming it is safe.
Apply Adobe's VULN-39341 hotfix
Use the Adobe hotfix instructions linked below to select the correct archive. The original VULN-39341-composer-patches.zip is not the only package now available.
Take a recoverable backup and test on representative staging first. Adobe's installation guide distinguishes Cloud deployments, which use m2-hotfixes, from on-premises and Magento Open Source patch application. Follow the instructions for your environment and refresh caches as directed.
- Record the exact Magento edition, version, patch filename and deployment revision before starting.
- Check patch output for failures or rejected changes; do not force a mismatched patch onto production.
- Test checkout, payment integrations, transactional emails, admin access and any GraphQL-dependent storefront before an expedited production deployment.
- Keep the fix in the deployment process so a later build cannot silently overwrite it.
Verify the hotfix on the deployed store
For Adobe Commerce on Cloud, Adobe documents the following check with the Quality Patches Tool installed. Run it on the deployed environment and confirm the VULN-39341 entry reports Applied. A missing entry or just a table heading is not confirmation.
For on-premises and Magento Open Source, retain the successful patch output and compare the deployed files with the changes in the selected Adobe patch. Do not present the Cloud-only status command as universal verification. Ask your maintainer to record this check against the production deployment.
Repeat the functional checks after deployment and review application errors. Neither a successful checkout nor an Applied status proves that the host is free of an earlier compromise; investigate that separately.
vendor/bin/magento-patches -n status | grep "39341\|Status"What store operators should do immediately
Treat this as an incident-response task, not a normal patch window. Preserve evidence before cleaning, review the current Sansec indicators, and use a Magento-aware compromise scanner or incident-response provider to look for the implant and secondary access.
Patching prevents further exploitation of this vulnerability but does not remove an existing implant or secondary backdoor. Keep appropriate WAF protection in place as defence in depth, not as a substitute for the hotfix. Do not disable GraphQL blindly: it may support storefronts and integrations, and containment needs to fit the incident.
- Snapshot application code, the database and relevant server state before remediation.
- Preserve web, PHP, Magento, WAF, proxy, cron and authentication logs.
- Review GraphQL requests containing unusual styles parameters and other indicators in the current Sansec advisory.
- Inspect processes, cron persistence, temporary paths and unexpected PHP files under media directories against Sansec's current indicators; process names alone are not a diagnosis.
- Escalate quickly if checkout, payment emails, unknown processes or outbound network traffic look abnormal.
Warning signs worth investigating
A burst of Magento Payment Transaction Failed Reminder emails can be a useful lead, but legitimate payment failures can produce the same message. Correlate email timing with application logs, GraphQL requests, new processes, cron changes and outbound connections.
Sansec has observed implants disguised as kernel-worker or font-cache processes, including names such as [kworker/u:8:0] and fc-cache. It has also published gvfsd and fontconfig persistence paths, suspicious cron entries, malware hashes and command-and-control destinations. Use the live advisory rather than copying a static IOC list into a long-lived playbook, because the campaign has already changed variants.
If you find evidence of compromise
Isolate the affected host or workload without destroying volatile evidence. Capture the process, network and filesystem state; remove attacker persistence; establish the earliest known intrusion time; and rebuild from trusted code and infrastructure where confidence in the host has been lost.
Follow Adobe's post-patch credential-rotation checklist even if you have not confirmed compromise. Replace the encryption key and potentially exposed admin, integration, payment, database and deployment credentials at their source. Changing only Magento's encryption key does not revoke stolen secrets. Follow Adobe's maintenance, cron and Cloud redeployment precautions.
If payment or personal data may have been exposed, involve the payment provider, acquiring bank, insurer and appropriate legal or compliance contacts. Keep a written timeline of evidence, decisions, remediation and post-recovery monitoring.
What not to rely on
Do not wait for a failed-payment email, rely only on Magento patch status, or assume that an up-to-date 2.4.x release is unaffected. Do not restore yesterday's backup without checking whether the initial access predates it, and do not treat a single blocked request as proof that earlier attempts failed.
The official hotfix is available now. Verify that it remains present after subsequent deployments, and keep monitoring for evidence of earlier exploitation. Our public website scan is not a server-side forensic examination and cannot certify that the hotfix is installed or the store is clean.