Magento StyleSmuggler and SessionReaper: The 2026 Attacks and How to Protect Your Store

StyleSmuggler: an unauthenticated RCE that ships in a stylesheet query

StyleSmuggler is the nastier of the two because it was a live zero-day. Sansec published it on September 5, 2026 after seeing it exploited in the wild, and there was no Adobe fix available on the day of disclosure. It affects the whole supported line, so being current on 2.4.9 does not save you here.

The clever part is the delivery. The attacker smuggles a raw PHP open tag, something along the lines of <?=eval(base64_decode('...')), into a request through the GraphQL styles[ query vector. Magento does not execute it there. Instead the tainted value gets written into a file that Magento later renders as PHP: specifically a failure report under var/report that is rendered through the "Payment Transaction Failed Reminder" email path. When that path processes the report, your own server executes the attacker's code. The input validation gap and the render step are in two different components, which is exactly why it slipped through.

Once code runs, the dropper is careful and quiet:

• It is time-boxed to roughly 180 seconds. Miss the window and the entry point is gone, which frustrates slow scanners and after-the-fact forensics.
• It is gated on a secret header, an X-TRACE-<hex> value, so a generic request to the same endpoint does nothing. Only the attacker who knows the token gets the payload.
• It self-deletes after running and then pulls a second-stage binary, a fake kworker process, from a malware host so the crypto-miner or backdoor keeps running after the dropper is gone.

Because it self-deletes, the absence of an obvious webshell is not evidence that you are clean. You have to hunt for the trail it leaves behind.

SessionReaper (CVE-2025-54236): a year old and still hunting

SessionReaper is the September 2025 critical vulnerability that Adobe patched in an out-of-band bulletin, tracked as CVE-2025-54236 with a CVSS around 9.1. It is an improper-input-validation flaw in the Commerce REST API that leads to nested PHP object deserialization. The public exploitation path runs through the /customer/address_file/upload endpoint, and the result is customer account takeover that can be chained all the way to unauthenticated remote code execution when file-based session storage is in play.

It sits in the same family as CosmicSting (CVE-2024-34102), the 2024 XXE-to-RCE chain that gutted thousands of stores. The lesson repeats: a critical Magento bug does not expire when the news cycle moves on. Sansec and others have tracked SessionReaper being mass-exploited well into 2026, because a large tail of stores never applied the emergency patch or the isolated hotfix. Attackers automate the scan, and an unpatched endpoint is an unpatched endpoint whether the CVE is one week or twelve months old.

If you patched promptly in September 2025 you are covered on this one, but "we think we patched it" is not the same as knowing. The verification steps below apply to both attacks precisely because you cannot assume.

StyleSmuggler vs SessionReaper at a glance

Same outcome, unauthenticated code running on your server, reached two different ways. Here is the shape of each:

The remediation playbook, in priority order

This is the point of the post. Work top to bottom. The early steps buy you time, the later steps confirm you are actually clean.

1. Apply Adobe's official patch as soon as it ships

For SessionReaper the fix already exists: apply the September 2025 patch or the isolated hotfix for your release line, today, if you have not confirmed it is on. For StyleSmuggler, watch for the Adobe security bulletin (an APSB release) and apply it the instant it lands. Adobe now ships most security fixes as isolated patch files rather than full -p Composer releases, so the delivery mechanics matter. I wrote a full walkthrough of applying an isolated patch in my guide to how to apply Adobe's isolated security patch, and a companion piece on what a security patch changes and what it leaves alone. Everything below is what you do until the patch is applied, and what you do to confirm you were not already hit.

2. Block the attack at the web server (WAF or nginx)

You can neutralize the StyleSmuggler delivery today with two rules. First, reject any request whose URI carries a raw or percent-encoded PHP open tag. Second, block the GraphQL styles[ query vector. Drop this into the relevant server or location block in nginx:

if ($request_uri ~* "(<\?|%3c%3f)") { return 403; }
if ($args ~* "styles(\[|%5b)") { return 403; }

The first rule catches <? and its URL-encoded form %3c%3f anywhere in the request line. The second catches styles[ and styles%5b in the query string, which is the specific GraphQL argument shape the exploit abuses. If you run a managed WAF (Cloudflare, AWS WAF, a modsecurity ruleset), express the same two conditions as custom rules there. Test on staging first: a rule this blunt can catch a legitimate request if some integration genuinely sends those patterns, though in practice almost nothing benign puts a PHP open tag in a URL.

3. Restrict or disable GraphQL if you do not use it

StyleSmuggler enters through GraphQL. If your storefront is classic Luma or a server-rendered Hyva build that never touches the GraphQL endpoint, there is no reason to leave /graphql open to the world. Restrict it by IP, put it behind auth, or block it outright at the web server until you have patched. If you do use GraphQL, for a headless or PWA storefront, you cannot close it, so rule 2 and prompt patching carry the load instead. Either way, keep GraphQL patched and current; it has been the entry point for more than one of these chains.

4. Rotate the encryption key, sessions, and credentials if compromise is suspected

If you have any reason to believe an attacker reached code execution, assume secrets are exposed. The Magento encryption key protects stored payment tokens, integration credentials and more, and it lives in app/etc/env.php, which a webshell can read. Rotate it, invalidate every admin session, and change the surrounding credentials:

bin/magento encryption:key:change
bin/magento cache:flush
# then, outside Magento, rotate:
#  - admin passwords and any 2FA seeds
#  - database credentials in env.php
#  - API keys / integration tokens
#  - SSH keys and control-panel logins

Changing the encryption key re-encrypts stored values with the new key and makes any copy of the old key useless. Pair it with a forced admin re-login so a stolen session cookie dies.

5. Hunt for compromise: the IoC checklist

A patch stops the next attacker. It does not remove a backdoor the last one left. Because StyleSmuggler self-deletes its dropper, you are looking for residue, not the weapon. Work this list:

# 1. The smoking gun: PHP eval / x-trace inside failure reports
grep -rIl "eval(base64_decode" var/report/ 2>/dev/null
grep -rIil "x-trace" var/report/ 2>/dev/null

# 2. Dropper residue in /tmp
ls -la /tmp/.kw_* /tmp/.cache_* /tmp/.fc_* 2>/dev/null

# 3. Fake worker processes eating CPU
ps aux | grep -E "kworker|fc-cache" | grep -v grep

# 4. Cron entries nobody added
crontab -l; ls -la /etc/cron.d/

# 5. Outbound connections to unknown hosts
ss -tunp | grep ESTAB

# 6. Stray PHP dropped into web-writable dirs
find pub/media pub/static -name "*.php" -type f 2>/dev/null

Then confirm the human layer: list your admin users and integrations and make sure every one is expected. An attacker's favorite persistence trick is a quiet extra admin account or a new integration token.

-- list every admin account, then confirm each one is yours
SELECT username, email, created, logdate FROM admin_user;
-- then review System > Integrations in the admin for tokens you did not issue

For anything beyond a quick manual pass, run a dedicated malware scanner. Sansec's eComscan is the tool most Magento incident responders reach for; it knows the current droppers, the fake kworker signatures and the common webshell patterns, and it will find things a manual grep misses.

6. Harden so the next one lands softer

Once you are patched and clean, close the doors that turn a single bug into a full compromise:

• Deny PHP execution under pub/media. No legitimate media file is a script. Blocking execution there defangs a whole class of upload-to-RCE attacks, StyleSmuggler and SessionReaper included.
• Keep the address_file upload endpoint patched. That endpoint is the SessionReaper doorway; the May 2026 hardening also removed customer_address media from allowed resources. Do not roll those changes back.
• Run least-privilege. The web-server user should not own files it does not need to write. Web-writable directories should be a short, known list.
• Backups plus a staging gate. Tested, offline backups make step 5's "restore from clean" a real option instead of a wish, and a staging environment lets you dry-run every patch before it touches production.

The nginx rule to block PHP in the media directory is short:

location ~* ^/media/.*\.(php|php5|phtml|phar)$ { deny all; return 403; }

What I would do this week, honestly

My ordering, as a store owner reading this today:

• In the next hour: put the two web-server rules from step 2 in place. They are the cheapest insurance you will buy all year, and StyleSmuggler had no patch at disclosure.
• Today: confirm SessionReaper (CVE-2025-54236) is actually patched, not "probably patched". Verify the code level, do not trust memory.
• This week: run the IoC hunt in step 5, or an eComscan pass. Do it even if nothing looks wrong, because a quiet miner is the whole point of StyleSmuggler's self-deleting design.
• The moment the APSB bulletin lands: apply the StyleSmuggler patch, on staging first, then production, and verify with a smoke test rather than a version string.
• If anything at all looks off: rotate every secret and restore code from clean. When in doubt, assume breach; it is far cheaper than assuming innocence and being wrong.

Sources: Sansec threat research, Adobe security bulletins for Magento, and NVD entry for CVE-2025-54236. If you run Mage-OS, watch its release feed too; it tends to port Adobe's security fixes into source quickly, as it did with the 3.2.0 security release.