critical exploited in the wild CVSS 10 EPSS 3.9%

StyleSmuggler

CVE-2026-75650 APSB26-146 Adobe Commerce / Magento 2.x CISA KEV 2026-09-08

If it is missing Adobe's APSB26-146 hotfix (VULN-39341), an unauthenticated attacker can inject PHP through the email template engine and run code on the server — CVSS 10.0, no login and no user interaction. Adobe Commerce 2.4.4 to 2.4.9, Adobe Commerce B2B 1.3.3 to 1.5.3 and Magento Open Source 2.4.6 to 2.4.9 are affected, including the August 2026 releases. It has been exploited in the wild since at least 4 September 2026 and is on CISA's Known Exploited Vulnerabilities catalogue — verify the exact patch level today.

Is my store affected?

A free passive scan tells you whether your store is on an affected line, along with everything else we can see from outside. It takes under a minute and needs no account.

How we detect this

We infer the platform and version line from signals the storefront serves publicly — the version endpoint when it is reachable, markup and cookie markers when it is not, and the fingerprints of static assets that changed between releases. If that line is one CVE-2026-75650 affects, we say so.

We do not attempt to exploit it, and we never claim a store is vulnerable from a version string alone. A patched store and an unpatched one on the same release look identical from outside, so the finding is marked inferred and phrased as something to verify. It does not affect your grade.

How to fix it

Apply Adobe's VULN-39341 hotfix, then treat the store as compromised until you have checked. Patching closes the door; it does not remove anyone already inside.

1
Apply the hotfix. Adobe ships it as a composer patches bundle (VULN-39341-composer-patches.zip) and has tested it against the August 2026 releases; it closes this without a version upgrade.
```
vendor/bin/magento-patches apply VULN-39341
```
2
Rebuild so the patched code is compiled and served. This publishes the change the previous step made — it does not apply it. Skip static-content:deploy in developer mode.
```
bin/magento setup:upgrade && bin/magento setup:di:compile && bin/magento setup:static-content:deploy -f && bin/magento cache:flush
```
3
Confirm the patch is actually applied before you move on. A hotfix that failed to apply looks exactly like one that did until you ask.
```
vendor/bin/magento-patches -n status | grep -i 39341
```
4
Now find out whether you were hit first. Exploitation predates the patch, so a clean patch status says nothing about the days before it. Attackers have been dropping PHP web shells under pub/media and a Rust backdoor kept alive by cron.
```
find -L pub/media -type f -name '*.php'; crontab -l
```
5
Check the exception log for the injection's own trace. The gadget chain fails noisily before it succeeds, so these lines appear whether or not the attempt worked.
```
grep -R -i -e 'Laminas\\Loader\\Exception' -e 'MGPROOF::' -e 'MGKWSIM::' var/log/ var/report/ | head
```
6
If anything above turns something up, rotate the encryption key and every credential it protected — admin passwords, REST/SOAP/GraphQL integration tokens, OAuth secrets, payment gateway keys, database credentials, SSH and deploy keys, extension API keys. Rotate them at the source as well as inside Magento.
```
bin/magento encryption:key:change
```
7
Optional, and separate from the fix: move to a release that carries the patch on your line. Use your edition's metapackage and the fixed version from the advisory.
```
composer require magento/product-<your-edition>-edition:<fixed-version> --no-update && composer update --with-dependencies
```

Check it worked

vendor/bin/magento-patches -n status | grep -i -e 39341 -e Status

References

From intelligence vault 2026.09.6, released 2026-09-25. What changed