Magento CVE-2026-75650: Unauthenticated RCE, CVSS 10

What is CVE-2026-75650?

It is an injection in Magento's template system (CWE-1336) that lets an unauthenticated attacker run PHP code on the server. Sansec, which discovered and named it StyleSmuggler, explains that it goes through the styles properties, treated as plain layout data, and bypasses existing safeguards. Adobe says it is aware of exploitation targeting Adobe Commerce merchants.

How does the exploitation unfold?

In two stages, according to Sansec.

1. Poison a file or log with PHP code, for example by triggering an error report. In one variant, PHP is sent in the query string of /paypal/transparent/response/, which Magento logs to var/report/<sha256>.
2. Make Magento run the poisoned content. The main trigger is the standard "Payment Transaction Failed Reminder" email: the code runs while the template is rendered, whether or not the email is actually sent. A variant goes through a request to /graphql with styles[first] pointing to the poisoned report. Later attempts targeted var/log/system.log, var/log/exception.log and session files.

Moving sessions to Redis or the database does not stop the attack. Payloads expire about three minutes after injection.

What is the timeline?

• August 23, 2026: unsuccessful probes by the attacker.
• September 4 around 22:20 UTC: first confirmed exploitation; a Magento server reported compromised about fifty minutes later, per The Hacker News.
• September 5: Sansec reproduces the chain on clean 2.4.7, 2.4.8 and 2.4.9 installs and publishes its analysis.
• September 7: Adobe publishes APSB26-146 and the VULN-39341 fix, priority 1, CVSS 10.0.
• September 8: added to CISA's KEV, federal deadline of September 11.
• September 10: Cloudflare and Imperva WAF rules.

Which versions are affected?

Sansec states that all versions from 2.4.4 to 2.4.9 are affected. According to The Hacker News, Adobe's list is: Adobe Commerce 2.4.4 to 2.4.9, Adobe Commerce B2B 1.3.3, 1.3.4, 1.4.2, 1.5.2 and 1.5.3, Magento Open Source 2.4.6 to 2.4.9, in each case "2026-aug and earlier". Sansec saw a store on 2.4.6-p15, up to date with the July and August patches, get hit: a current patch level brings no protection. Adobe provides no fix for out-of-support branches (2.2, 2.3, 2.4.0 to 2.4.3). Simply moving to version 2.4.9 is not enough: the VULN-39341 fix is needed.

Which malware was observed?

Sansec found several payloads: a Rust backdoor (fc-cache, then chronyd) that uses NTP-shaped UDP traffic for command and control, a gs-netcat relay, the WraithC2 RAT, a remote file include triggered by a cookie and a base64-encoded skimmer in core_config_data. A second, separate actor dropped a PHP dropper and a web shell in the product image cache. The Hacker News also mentions the Rust backdoor and the PHP web shell.

What should you do, in order?

1. Apply the VULN-39341 fix (APSB26-146) for your version, through the Composer patch, and verify it with the patch status command. Unofficial backports for older branches should be tested on staging first.
2. Rotate the encryption key and everything it protects: admin passwords, API and integration tokens, OAuth secrets, payment gateway keys, database credentials, SSH and deploy keys. Do it at the source, not only in Magento. Adobe states that both the fix and the rotation are required.
3. Look for a compromise: fixing does not clean an already infected store.
4. Block attacks with an up-to-date WAF, as a complement and not a replacement for the fix.
5. Limit the trigger email if possible (a community plugin can stop failed-payment reminder emails) and watch for bursts of these emails.

What should you look for to know whether a store is compromised?

Sansec publishes indicators and hunting commands. The main ones:

• PHP files under pub/media, notably pub/media/catalog/product/cache/ss_<10hex>/sync_<10hex>.php;
• var/report/<sha256> files containing the x_trace_ marker and Laminas InvalidArgumentException entries in var/log/exception.log;
• unexpected cron jobs, processes named kworker, fc-cache or chronyd whose location or parent does not match, hidden files under /tmp and in the home directory;
• modification of vendor/magento/framework/App/View.php to include remote code;
• skimmer value in core_config_data, path design/head/includes;
• cookie gl_google_advisor_824808 and connections to the command-and-control addresses published by Sansec.

If any of these clues is present, isolate the server, preserve the logs, treat all secrets as exposed and bring in an incident response provider.

Why does this case matter beyond Magento?

It shows how fast exploitation can outrun the fix: the first confirmed attack came three days before Adobe's bulletin, and a store with current patches was still hit. The practical response is a discipline rather than a single action: know what you run and where it is exposed, have a tested way to apply emergency patches within hours, keep a WAF as a stopgap, and be ready to rotate every secret that the platform could read.

For teams that connect AI agents or assistants to an e-commerce back office (order lookup, customer support, catalog updates), the same logic applies to the agent's credentials. An agent with an API token to the store inherits the blast radius of a compromised store, and a store's encryption key protects that token too. Include agent credentials in your rotation checklist and keep their scope to the minimum.

How do you test your store's exposure?

1. Version and fix: record the version and the VULN-39341 fix status on each environment.
2. Exposure: are the /graphql and /paypal/transparent/response/ routes reachable without authentication, and behind which WAF?
3. Monitoring: do you receive alerts on new PHP files under pub/media?
4. Secrets: can you rotate the encryption key and related credentials within hours?
5. Recovery: do you have a clean backup to rebuild a compromised server?

CleanIssue's Agent Red Team Express (EUR 1,900, 5 days) covers AI agents and their access, including those that query your store or its data: see the offer. A free 30-minute discovery call is enough to see whether an anonymous request can reach your store's tools through an agent. For the frame, see the AI agent security page.