critical exploited in the wild CVSS 9.1 EPSS 94.5%

SessionReaper

CVE-2025-54236 APSB25-88 Adobe Commerce / Magento 2.x CISA KEV 2025-10-24

If it is 2.4.8-p2 or earlier without the APSB25-88 emergency hotfix (VULN-32437), an unauthenticated improper-input-validation flaw in the Commerce REST API allows customer-session takeover and, under certain configurations, remote code execution. This is actively exploited in the wild — verify the exact patch level urgently.

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-2025-54236 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 APSB25-88 isolated hotfix (VULN-32437) for your exact release, then rebuild. Actively exploited, so this is urgent rather than routine.

1
See which patches the Quality Patches Tool offers for your exact version. If the tool is not installed: composer require magento/quality-patches
```
vendor/bin/magento-patches status
```
2
Apply the APSB25-88 hotfix. If it is listed by the tool, apply it by ID. If Adobe supplied it as a standalone .patch file for your release line, apply that file instead — the two routes are equivalent, and either one closes this WITHOUT a version upgrade.
```
vendor/bin/magento-patches apply VULN-32437   # or: patch -p1 < VULN-32437_2.4.x.patch
```
3
Now rebuild, so the patched code is compiled and served. This step does NOT apply the patch — it publishes the change the previous step made. 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
```
4
If there is any sign of exploitation, treat sessions and credentials as compromised. Flush the session store so every existing session dies: Redis — flush the session database only (check session.redis.db in app/etc/env.php before running this, and never FLUSHALL); files — clear var/session.
```
redis-cli -h <host> -n <session-db> FLUSHDB   # or: rm -rf var/session/*
```
5

Force a password reset for every admin user, and revoke and reissue every integration access token (Admin > System > Extensions > Integrations). An attacker who took a session before you patched still holds any token they found.
6
If compromise is suspected rather than merely possible, rotate the encryption key as well — a patch does not undo a key that leaked before it. Re-encryption of stored data runs as part of this, so take a backup and expect it to take time on a large catalogue.
```
bin/magento encryption:key:change
```
7
Optional, and separate from the fix: move to a patched release on your line. Use your edition's metapackage and the exact fixed version from the advisory.
```
composer require magento/product-<your-edition>-edition:<fixed-version> --no-update && composer update
```

Check it worked

vendor/bin/magento-patches status | grep -i -e VULN-32437 -e 54236

References

We have a longer write-up on this one: SessionReaper (CVE-2025-54236): the unauthenticated Adobe Commerce RCE, explained.

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