StyleSmuggler (CVE-2026-75650) was exploited before anyone knew it existed. Attacks began on 4 September 2026, and stores were compromised for three days before Adobe shipped a fix. It affected every Magento and Adobe Commerce version from 2.4.4 to 2.4.9, including fully patched stores. Here is how to think about the response, because patching was only one part of it.
Key takeaways
- CVE-2026-75650, CVSS 10.0, unauthenticated code execution in Magento 2.4.4–2.4.9; exploited from 4 September 2026.
- Apply hotfix
VULN-39341(APSB26-146) and keep it in place. - Patching does not clean a compromised store: check for compromise on every store that was exposed.
- Rotate the encryption key first, then every secret the Magento user could read.
- Harden PHP and the filesystem so the next bug does less damage.
Timeline
| When (UTC) | What happened |
|---|---|
| 4 Sep, 22:20 | First confirmed exploitation. |
| 5 Sep | Sansec discloses the campaign; WAF detection rules go live. Disrex publishes an emergency source patch and hardening advice. |
| 7 Sep, 20:20 | Adobe publishes APSB26-146, Priority 1, with hotfix VULN-39341. |
| 8 Sep | Adobe’s regular September release APSB26-138 ships separately. |
How it works, in principle
The attack has two stages. First, the attacker gets Magento to write attacker-controlled PHP into a file the application can reach, such as a log or error report. Second, a crafted request abuses Magento’s template processing (the styles handling that gave it its name) and dependency-injection code so that the poisoned file is included and executed. Researchers observed it delivered through failed-payment emails, but also showed it working without them. No authentication is needed, and the payloads seen in the wild installed a native Linux implant disguised as a kernel process.
The response, in layers
1. Block it at the edge first
During a zero-day there is no patch to apply, so the fastest protection is virtual patching. Sansec Shield, Cloudflare and Imperva all shipped rules. Edge rules buy time; they are not a fix, because request parameters can be moved to evade them.
2. Reduce what a successful exploit can do
- Disable process-spawning functions in PHP where the application allows it:
exec,shell_exec,system,passthru,popenand, importantly,proc_open. - Mount temporary directories with
noexec(/tmp,/var/tmp,/dev/shm), after checking nothing legitimate executes from them. - Temporarily disable GraphQL if the store genuinely doesn’t use it. Confirm first: headless and PWA storefronts depend on it.
These are good hardening practices anyway. A web process that cannot start a shell or run a binary from /tmp turns many remote code execution bugs from a full compromise into a failed attempt.
3. Apply the official hotfix properly
Apply VULN-39341 through your normal Composer patch process, test on staging, and make the deployment fail if a patch doesn’t apply. Remove any emergency third-party patch once the official one is in place, so you’re not carrying two fixes for the same code.
4. Assume compromise until you’ve checked
A patch stops new attacks. It does nothing for a store that was already compromised during those three days. For every store that was exposed, check for:
- non-root processes with kernel-thread-style names in brackets, or unfamiliar processes named like system services;
- new cron entries, and hidden binaries or lock files in the web user’s home directory and
/tmp; - PHP code inside log and report files under
var/, and any.phpfile underpub/media; - unusual bursts of “payment transaction failed” emails, and new errors in
var/log/exception.log.
Use the published indicator lists and a malware scanner, but remember that a clean result is not proof. If you do find something, preserve evidence before cleaning: don’t reboot, delete the binary or redeploy until it has been captured.
5. Rotate secrets, starting with the encryption key
If code ran as the Magento user, everything that user could read is exposed. Rotate the Magento encryption key first, then every credential it protected and every secret on the filesystem: admin passwords, API and integration tokens, database credentials, SSH and deploy keys, and third-party service keys, each at its source.
What it reinforces
“Fully patched” is a point in time, not a security posture. The stores that came through best had layers that didn’t depend on the patch: a WAF, a locked-down PHP configuration, monitoring that would notice a strange process, and a practised process for rotating secrets. And it was followed a month later by a bypass of the fix, which is the subject of the next post.
