Magento security in 2026: SessionReaper, active attacks, and how to clean a hacked store

If you run a Magento or Adobe Commerce store and haven't patched since mid-2025, assume you are a target. Here's what's been happening, how to check your store, and how to recover if you've already been hit.

SessionReaper: the vulnerability that defined the last year

CVE-2025-54236, nicknamed SessionReaper, is a critical (CVSS 9.1) flaw affecting Adobe Commerce and Magento Open Source. It allows unauthenticated remote code execution and customer account takeover through the REST API, by combining session manipulation with a nested deserialization bug — especially dangerous when session data is stored on the filesystem.

The timeline says everything about why patching speed matters:

Attackers upload PHP webshells disguised as session files via /customer/address_file/upload, then use them for card skimming, admin creation and data theft. This follows the same pattern as 2024's CosmicSting (CVE-2024-34102), which hit thousands of stores including household-name brands.

Check your store right now

1. Are you patched? You need the APSB25-88 hotfix or a version released after it (Adobe Commerce / Magento Open Source 2.4.9-alpha2, 2.4.8-p2, 2.4.7-p7, 2.4.6-p12, 2.4.5-p14, 2.4.4-p15 or later). Check with:

bin/magento --version
composer show magento/product-community-edition | grep versions

2. Look for webshells and fake session files:

# PHP files where they should never be
find pub/media var/session -name "*.php" -mtime -90
# recently modified core files
find app/code vendor -name "*.php" -mtime -30 | head -50
# suspicious uploads via the exploited endpoint
grep -r "address_file/upload" var/log/ | tail -20

3. Audit admin users and integrations. In the admin: System → Permissions → All Users — remove anyone you don't recognize. Also check System → Integrations for unknown API tokens, and re-check your crontab for jobs you didn't create.

4. Scan your checkout for skimmers. Compare the JavaScript served on your payment step against your repository. Card-skimming code is usually injected into core_config_data (design head scripts), CMS blocks, or theme JS files.

Signs you're already compromised

How I clean a hacked Magento store

Restoring a backup is not enough — if you don't close the entry point, they're back in a week. My process:

  1. Contain. Put the site in maintenance mode behind an IP allowlist, rotate all credentials (admin, database, SSH, API tokens, payment gateway).
  2. Snapshot. Full forensic copy of files, database and logs before touching anything — you may need it for your payment processor or insurer.
  3. Find the entry point. Correlate file modification times with access logs. Patch the CVE that let them in — SessionReaper is the first suspect on unpatched 2.4.x stores today.
  4. Remove the malware. Diff every file against clean vendor sources, clean injected database rows (design scripts, CMS blocks), remove rogue admins, integrations and cron jobs.
  5. Harden. Apply all pending security patches, move sessions to Redis, restrict admin by IP + 2FA, add a WAF, enable CSP for checkout, set up file-integrity monitoring.
  6. Verify & monitor. External malware scan, re-scan after 48 hours, then weekly monitoring — reinfection attempts are guaranteed once you've been on a target list.

Don't wait for the next CVE

SessionReaper won't be the last. The stores that survive these waves are the ones with patches applied within days, sessions off the filesystem, and monitoring that catches an intrusion in hours instead of months.

Not sure if your store is patched or clean? Send me your store URL — the initial check is free, and if you've been hacked I offer emergency cleanup with a fixed quote.

Vikram · MagentoWorks

Magento & Adobe Commerce specialist since 2011. I do Hyvä migrations, speed optimization, security patching and hacked-store cleanup.

Get a free store checkup

Related reading

← All 99 posts