Magento StyleSmuggler is an actively exploited Adobe Commerce and Magento Open Source zero-day. Adobe identifies it as CVE-2026-75650, a critical unauthenticated code-execution flaw with a CVSS 10.0 score. If you run an affected store, apply Adobe’s VULN-39341 hotfix now, rotate encryption keys and credentials, then hunt for persistence. Patching alone may close the hole, but it won’t remove a backdoor already planted.
Magento StyleSmuggler: the emergency version
The search intent here is operational, not academic. You’re probably trying to answer three questions fast: am I affected, what do I do first, and how do I know the store is clean?
Adobe published bulletin APSB26-146 on September 7, 2026, naming Magento StyleSmuggler as CVE-2026-75650. The flaw is classified as CWE-1336, improper neutralization in a template engine, and Adobe assigned it Priority 1 because exploitation is happening in the wild against Commerce merchants.
Sansec reported the first attacks on September 4, 2026, and publicly described the campaign on September 5. BleepingComputer, SecurityWeek, and The Hacker News also reported active exploitation, with BleepingComputer and SecurityWeek saying attackers deployed persistent Linux/Rust backdoors after compromise.
Don’t treat this as a normal “patch during the next window” advisory. A no-authentication, server-side code execution bug in a payment-facing ecommerce stack is about as bad as it gets. If your checkout is live, your risk window is open.
Who is affected, and which versions are listed?
Adobe says the issue affects Adobe Commerce, Adobe Commerce B2B, and Magento Open Source on all platforms. Its September 9, 2026 knowledge-base guidance lists Adobe Commerce 2.4.9-2026-aug through 2.4.4-2026-aug and earlier, plus corresponding Magento Open Source and B2B versions.
For Magento Open Source, Adobe’s affected-version list includes 2.4.9, 2.4.8, 2.4.7, and 2.4.6-2026-aug and earlier. For Adobe Commerce B2B, it includes 1.5.3, 1.5.2, 1.4.2, 1.3.4, and 1.3.3-2026-aug and earlier.
A nasty edge case: Sansec reported that the first known victim ran 2.4.6-p15 with July and August 2026 patches applied and a clean security:patch-status. In plain English, being “fully patched” before APSB26-146 didn’t protect that store.
| Item | 2026 status | Why it matters |
|---|---|---|
| CVE | CVE-2026-75650 | Adobe’s identifier for StyleSmuggler |
| Severity | CVSS 3.1 score 10.0 | Maximum critical rating |
| Authentication | None required | Attackers don’t need an admin account |
| Adobe priority | Priority 1 | Adobe expects urgent patching |
| Observed exploitation | From September 4, 2026 | Real attacks preceded Adobe’s hotfix |
| Fix named by Adobe | VULN-39341 hotfix | Version-appropriate hotfix required |
Sansec also says it reproduced the full unauthenticated exploit chain on clean Magento Open Source 2.4.7, 2.4.8, and 2.4.9 installations. That claim comes from Sansec’s research, not Adobe’s bulletin, but it’s operationally relevant because those are common branches in the field.
How the exploit works, in operator language
Sansec says Magento StyleSmuggler abuses Magento’s template system by injecting PHP code through styles properties. The poisoned code is then executed through a failed payment email path, which explains one of the stranger signs defenders have reported: unexpected surges in Magento “Payment Transaction Failed Reminder” emails.
That detail matters for triage. A store can look normal from the frontend while the template and email path are being used as the execution route. If your only health check is “can customers browse and pay,” you’re missing the part attackers care about.
Before Adobe released the hotfix, Sansec, BleepingComputer, and The Hacker News cited temporary containment by disabling GraphQL where possible. After September 7, 2026, Adobe and Sansec shifted the guidance: apply VULN-39341 rather than relying on blocking or feature shutdowns alone.
One pitfall deserves more attention. Sansec says moving sessions to Redis or database storage does not stop the attack, and it reported one operator switched to a file uploaded through Magento custom options after a session-storage attempt failed. In other words, the attacker’s route can adapt around a narrow mitigation.
If you’re reviewing broader exposure, compare this with other emergency patch events such as the PaperCut zero-day response pattern: the common failure isn’t lack of a patch, it’s assuming the patch also erases the intruder.
Apply Adobe’s fix, then freeze the moving parts
Adobe’s September 9, 2026 remediation sequence is specific. Apply the version-appropriate VULN-39341 hotfix, enable maintenance mode, disable cron execution, rotate encryption keys, rotate all Admin passwords, deactivate or regenerate REST, SOAP, and GraphQL integration tokens, and rotate OAuth client secrets.
Follow the sequence carefully. Cron is not a side detail here because Sansec observed persistence through cron entries, including an fc-cache variant running twice hourly at 13,43 * * * *. If cron keeps running while you’re cleaning, you may be racing the implant on your own server.
- Identify the exact Adobe Commerce, Commerce B2B, or Magento Open Source version and select the matching VULN-39341 hotfix from Adobe’s guidance.
- Put the store into maintenance mode during the response window, especially if payment or admin credentials may be exposed.
- Disable cron execution before rotating secrets or removing suspicious jobs.
- Apply the hotfix and verify the patch state with the tools your deployment normally uses.
- Rotate the Commerce encryption key, all Admin passwords, API tokens, OAuth client secrets, and upstream payment or third-party credentials.
- Scan the host, application tree, reports, and crontabs for indicators before bringing scheduled jobs back.
Here’s the calculation many merchants avoid: even a two-hour emergency checkout pause can be cheaper than a week of tainted orders. If a store does $120,000 a day, two hours of downtime is roughly $10,000 in gross sales exposure; a credentialed payment-gateway compromise, forensic retainer, chargeback handling, and customer notices can exceed that quickly. Your numbers will differ, but the math argues for a controlled outage over a blind cleanup.
For payment-specific cleanup thinking, the practical advice in secure online payments controls applies here: rotate at the source, not only inside the ecommerce application that stored the secret.
Backdoor hunting after Magento StyleSmuggler
Sansec’s September 9 update is blunt: patching closes the vulnerability but does not clean already compromised stores. Restoring from backup alone can also miss persistence if the attacker planted cron jobs, hidden binaries, modified templates, or credentials that still work elsewhere.
Start with the indicators Sansec published. Look for suspicious processes or files named [kworker/u:8:0], fc-cache, and chronyd when they don’t match the operating system’s expected paths and behavior. Check for files or processes under ~/.local/share/.gvfsd/, ~/.cache/fontconfig/fc-cache, /tmp/.kw_*, /tmp/.cache_*, /tmp/.gvfsd-*, /tmp/.fc-*/fc-cache, /tmp/fc-cache, and /tmp/.chrony-*/chronyd.
Magento reports deserve attention too. Sansec recommends checking for x_trace_ entries in var/report/. Unexpected failed-payment reminder email spikes are another clue, especially if they began around September 4 to September 7, 2026.
Network telemetry can help, but don’t depend on a single IP. Sansec reported one command-and-control IP as 99.84.67.186, and said a later fc-cache variant used NTP-like UDP/123 traffic to domains including ntp.timesync.to, ntp.timesysnc.net, ntp.synctime.to, and ntp.syncstime.to, resolving as of September 7 to 185.157.160.251.
BleepingComputer reported that the malware checks Linux TracerPid for tracing and still installs but does not beacon if tracing is active. That’s a useful warning for defenders: a quiet sandbox run is not proof the binary is harmless.
If you have SIEM coverage, now is when it earns its keep. Correlate web requests, Magento email events, cron changes, process creation, outbound UDP/123 traffic, and admin logins; a primer on SIEM threat detection is relevant because single-log review is weak against this kind of multi-stage compromise.
Credential rotation is bigger than the Magento admin
Adobe warns that the Commerce encryption key may protect integration tokens, payment gateway credentials, and privileged automation tokens. Rotating only the encryption key does not invalidate credentials already exposed, so you need to rotate them at the payment gateway or third-party source too.
Honestly, this is where many cleanups fail. Teams change Magento Admin passwords, feel productive, and leave a still-valid PSP API key, ERP token, shipping integration secret, or automation credential in circulation.
Regenerate REST, SOAP, and GraphQL integration tokens. Rotate OAuth client secrets. Change all Admin passwords, not only the obvious super-admin account. Then check whether any integration user has more permissions than it needs; trust verification and least-privilege thinking are useful here because ecommerce integrations often accumulate dangerous access over years.
What about old branches? Sansec says Adobe publishes no Magento StyleSmuggler fix for Magento/Commerce 2.2, 2.3, or 2.4.0 through 2.4.3 because those branches are out of support. It also says Scandiweb backported fixes to 41 older releases from 2.2.0 through 2.4.3-p3, but Sansec had not reviewed those patches as of September 9, 2026.
My view: running an unsupported Commerce branch during an exploited CVSS 10.0 event is not a maintenance problem, it’s a business-risk decision. A backport may buy time, depending on who produced it and how it was tested, but it shouldn’t become the long-term plan.
What to tell customers, finance, and the business
Security teams often want certainty before speaking. Ecommerce doesn’t always give you that luxury. If indicators suggest compromise, preserve logs, involve incident response, and brief finance and customer support early so they know what payment, refund, and account questions may arrive.
Don’t overstate what you know. A patched server means the known entry point is closed; it does not prove order data, tokens, admin sessions, or payment integrations were untouched. The careful phrase is “we have applied Adobe’s hotfix and are completing compromise assessment and credential rotation.”
Keep a dated decision log. Record when you applied VULN-39341, when maintenance mode began and ended, which keys were rotated, which cron entries were removed, what indicators were checked, and who approved bringing checkout back. During a messy Magento StyleSmuggler response, that log becomes your memory.
Attackers like software supply and update paths too, so if you’re auditing deployment trust after the incident, the analysis of how BGP hijacking can poison updates is a useful adjacent read. Different technique, same lesson: don’t assume the path that delivers code is automatically trustworthy.
FAQ
What is Magento StyleSmuggler?
Magento StyleSmuggler is the name used for CVE-2026-75650, a critical Adobe Commerce and Magento Open Source vulnerability disclosed by Adobe on September 7, 2026. It allows unauthenticated arbitrary code execution and is being exploited in the wild.
Does Adobe have a patch for Magento StyleSmuggler?
Yes. Adobe released the VULN-39341 hotfix on September 7, 2026, and updated its Commerce knowledge-base guidance on September 9 with version mapping and post-patch rotation steps.
Is disabling GraphQL enough to stop the attack?
No. Before Adobe’s hotfix, disabling GraphQL was cited as temporary containment where operationally possible. After VULN-39341 became available, Adobe and Sansec recommend applying the hotfix and completing cleanup rather than relying on blocking alone.
Can I just restore my Magento store from backup?
No, not safely by itself. Sansec warns that patching or restoring does not remove existing implants, cron persistence, stolen credentials, or secondary backdoors, so you still need forensic checks and credential rotation.
Are Magento 2.2 and 2.3 stores covered by Adobe’s fix?
Sansec says Adobe does not publish a StyleSmuggler fix for Magento/Commerce 2.2, 2.3, or 2.4.0–2.4.3 because those branches are out of support. If you run one, treat migration or independently reviewed backporting as urgent risk work.
EN 
FR 
ES