SessionReaper CVE-2025-54236: Magento Hardening Guide

Key Takeaways

• SessionReaper (CVE-2025-54236) is a CVSS 9.1 vulnerability in Magento and Adobe Commerce that allows account takeover and unauthenticated remote code execution.
• The bug has two exploit paths through the same nested deserialization flaw: a file-upload vector at /customer/address_file/upload and a session-takeover vector at PUT /rest/V1/carts/mine. A WAF that blocks one and not the other leaves you half exposed.
• Adobe shipped APSB25-88 on September 9, 2025, with hotfix VULN-32437-2-4-X-patch. Seven months on, 62% of stores remain unpatched.
• Active exploitation began on October 22, 2025. By November 1, 81% of all Magento stores had been probed for the vulnerability.
• Hosting-layer defenses (WAF rules, Valkey or Redis sessions, file-integrity monitoring) close the gap when the patch is delayed and contain damage when an attack lands.

What SessionReaper Is and Why It Is Worse Than You Think

Most Magento vulnerabilities are theoretical until somebody publishes a proof of concept. SessionReaper skipped that step seven months ago, and 62% of Magento stores still run unpatched builds. Adobe shipped APSB25-88 on September 9, 2025; active exploitation began six weeks later; by November, attackers had probed 81% of all Magento and Adobe Commerce installs. SessionReaper is past news cycle. It is now a known, weaponized weak spot in the majority of stores running today.

The vulnerability sits in the REST API. An improper input validation flaw lets an attacker pass a nested object payload that triggers PHP deserialization. From there, the attacker either uploads a webshell or hijacks a customer session. No login required. No admin access needed.

Adobe rated it CVSS 9.1 critical. The original Adobe bulletin said there was no evidence of exploitation in the wild, which was true on September 9. By October 24, Adobe had escalated SessionReaper to Priority Level 1. Reality moved faster than the bulletin.

The story Sansec, Akamai, and BleepingComputer told was the forensic story: how the bug works, who is being hit, what the IOCs look like. The story missing from coverage is the one that matters most to merchants who run a store: how does my hosting layer defend against this in practice, before the patch is applied, while it is being deployed, and after IOCs are found?

Both Exploit Paths Explained: File Upload and Session Takeover

SessionReaper has two distinct attack surfaces. They share the same root cause, a nested deserialization bug in the Magento\Framework\Webapi\ServiceInputProcessor class (in the getConstructorData() method), but they hit different endpoints with different goals. Defending against one does not defend against the other.

Vector A: PHP Webshell via File Upload

This is the path Sansec described in their original advisory. The attacker sends a crafted POST to:

POST /customer/address_file/upload

The malicious payload is a fake session object. The server deserializes it, writes it to disk under pub/media/customer_address/, and the attacker has a PHP file the web server will execute on demand. The result: a persistent webshell. Sansec observed payloads dropping files named static.php, bootstrap.php, sysapi.php, and replacements at pub/errors/404.php.

Vector B: Session Hijack via REST API

This is the path Pentest-Tools documented in their exploit walkthrough. The attacker sends:

PUT /rest/default/V1/carts/mine
Authorization: Bearer [JWT]
Content-Type: application/json

{
"quote": {
"customerRepository": {
"delegatedStorage": {
"session": {
"CustomerId": [victim_id]
}
}
}
}
}

The payload chains five Magento classes through a deserialization gadget: CartInterface, CustomerRepositoryInterface, Storage, Session\Proxy, and the setCustomerId() setter. The server stores the malicious session and returns a PHPSESSID cookie tied to the victim account. The attacker then loads /customer/account/ with that cookie. No password. Full account control.

A WAF rule that watches file uploads and ignores REST API payloads catches Vector A and misses Vector B. A rule that watches REST API requests and ignores form posts catches Vector B and misses Vector A. Both vectors exploit the same patch-fixed flaw, so applying APSB25-88 closes both. But until the patch lands, both endpoints need rules.

Affected Versions and the Adobe APSB25-88 Patch

The vulnerability affects every supported branch of Adobe Commerce, Adobe Commerce B2B, and Magento Open Source from 2.4.4 forward, plus the 2.4.9-alpha2 pre-release. The 2.4.9 release was patched before GA. Older branches received the hotfix at the same release window.

Vulnerable Versions

Applying the Hotfix

Adobe ships the fix as a composer patch. The patch file is hosted at repo.magento.com/patch/VULN-32437-2-4-X-patch.zip. Download it, unzip into your project root, and apply with composer. Our step-by-step patch installation guide covers the composer commands and rollback procedure for non-test environments.

If you run the Custom Attributes module, also pin it forward:

composer require magento/out-of-process-custom-attributes=0.4.0 --with-dependencies

An emergency hotfix like APSB25-88 ships outside the scheduled quarterly patch cycle, which is why it requires manual application on most stack configurations. For Adobe Commerce on Cloud Infrastructure, Adobe pushed WAF rules to the platform. Self-hosted and third-party-managed stores need to apply the patch by hand.

How to Check If Your Store Is Already Compromised

The hotfix stops new exploitation. It does not remove webshells already on disk. Any store that ran an unpatched 2.4.x build between September 9 and the date of patch application should treat itself as potentially compromised until proven otherwise.

Indicators of Compromise

Sansec published a list of payload artifacts. Search your filesystem for these names first:

• pub/static.php
• pub/bootstrap.php (if not part of your release)
• pub/sysapi.php
• pub/errors/404.php (compare hash against repo version)
• Any new .php file under pub/media/customer_address/

A quick disk scan covers the obvious cases:

find pub/media/customer_address -name "*.php" -mtime -180 2>/dev/null
find pub/ -maxdepth 2 -name "*.php" -newer composer.json 2>/dev/null

Network and Process Signals

Block outbound connections to known C2 hosts. Sansec attributed the post-exploitation traffic to worcksbot.com/w.php, which replaced an earlier sagecrafft.com domain. Attacker source IPs Sansec published include 34.227.25.4, 44.212.43.34, 54.205.171.35, 155.117.84.134, and 159.89.12.166. The full IOC list spans 23 IPv4 and 2 IPv6 addresses.

For deeper detection, run a malware scanner against your media directory and recent file changes. Sansec eComscan is the established tool. Our guide on how Magento malware persists and how hosting blocks it covers complementary scan workflows and host-side baselining.

Hosting-Layer Mitigations: Why Patch-Only Is Not Enough

Patching SessionReaper closes the deserialization flaw. It does not address four hardening gaps that exist in any Magento install regardless of patch state. These gaps are where managed hosting earns its money.

1. WAF Rules That Block Both Vectors

Two WAF rules are needed, one for each vector. Vector A is blocked by a request rule on the upload endpoint that rejects PHP MIME types and PHP magic bytes in the request body. Vector B is blocked by a content inspection rule on REST API requests that rejects nested JSON keys matching the gadget chain. The Pentest-Tools team published this regex pattern as a starting point:

"(customerRepository|delegatedStorage|session)".*"CustomerId"\s*:\s*\d+

On MGT WAF, both rules ship pre-configured for SessionReaper-class request signatures. For self-managed AWS WAF deployments, our AWS WAF Magento configuration walkthrough covers the rule-builder syntax for nested-JSON inspection and request-body filtering.

2. Move Sessions Off the Filesystem

This single change neutralizes Vector A by design. The default PHP file-based session store writes session data into a directory the web server can read. The exploit abuses that directory to plant PHP files. Move sessions into Valkey or Redis, and the file-based session store is no longer present, so there is no disk path for the payload to land on.

Adobe Commerce has supported Redis-based sessions for years and added Valkey 8.x as the recommended replacement in 2.4.8. The migration is a configuration change in app/etc/env.php. On managed hosting, this is the default. On self-managed hosting, the migration takes 30 minutes and removes one entire class of attack.

3. File-Integrity Monitoring

FIM watches your codebase and media directories for unauthorized changes. When a webshell appears, FIM raises an alert before the file is executed by a real customer request. The two paths to monitor first are pub/ and any directory the web server can write to but the source repository does not own.

The minimum policy: any new .php file outside app/code, vendor, and generated is suspicious. Tripwire, OSSEC, and Wazuh all support this rule with a few lines of configuration.

4. Anomaly Detection on REST API Patterns

Vector B looks like a normal REST API request until you inspect the JSON depth. A request body with object nesting deeper than three levels and a key named CustomerId at the bottom is an exploitation attempt or a developer mistake. Both deserve a log entry. Production traffic should not contain that pattern. If you see it, alert.

Incident Response Playbook If You Find IOCs

You found sysapi.php in your pub/ directory. Now what?

Step 1: Stop the Bleed

Block the known attacker IPs at the network edge. Rotate every PHP session cookie by changing the session salt or flushing your Valkey or Redis store. Disable any customer accounts created or modified during the suspected compromise window. Take a forensic snapshot of the affected disk before any cleanup, since you will need it for the timeline.

Step 2: Eradicate

Remove the planted files. Run a malware scanner across the entire codebase, not just pub/, since a compromised admin account can drop modules under app/code. Reset all admin passwords. Rotate the encryption key in env.php and re-encrypt sensitive config (third-party API keys, payment gateway credentials).

Step 3: Restore from Clean

If you have a clean backup from before the compromise window, restoring the codebase from that backup is faster and safer than playing whack-a-mole with planted files. Verify the backup pre-dates exploitation. Restore to a fresh server or wipe and re-deploy. Keep the compromised server image for forensics.

Step 4: Notify and Document

Account takeover means PII exposure. GDPR requires customer notification within 72 hours of confirmed unauthorized access to personal data. California's SB-446, in effect since October 2025, sets a 30-day window for notifying affected residents and 15 days for notifying the Attorney General on breaches above 500 California residents. Other state breach laws set their own timelines. Confirm your obligation before the clock starts. Document the timeline, the IOCs found, the mitigation actions taken. If your Adobe Commerce contract includes Customer Success Engineer support, notify Adobe.

How Managed Magento Hosting Closes This Gap by Default

Self-managed Magento on a generic VPS leaves you with four open tasks: apply the patch, configure two WAF rules, migrate sessions off the filesystem, and stand up file-integrity monitoring. That is a weekend, on a good week.

On managed Magento hosting, the patch lands during the next maintenance window without your intervention. The WAF rules ship pre-configured for SessionReaper-class signatures and update automatically when new payload patterns appear. Sessions live in Valkey or Redis from day one. File-integrity monitoring runs across the stack with alerts wired to a 24/7 IR team. When IOCs surface, the host owns the cleanup.

Specialized hosting is not a luxury for Magento stores. It is the difference between a CVE notification email and an open ticket on someone else's pager.

FAQ

What is SessionReaper?

SessionReaper is the public name for CVE-2025-54236, a CVSS 9.1 nested deserialization vulnerability in the Magento and Adobe Commerce REST API. It allows account takeover and unauthenticated remote code execution.

Which Magento and Adobe Commerce versions are affected?

Adobe Commerce 2.4.9-alpha2 and earlier, 2.4.8-p2 and earlier, 2.4.7-p7 and earlier, 2.4.6-p12 and earlier, 2.4.5-p14 and earlier, and 2.4.4-p15 and earlier. The same branches in Adobe Commerce B2B and Magento Open Source are affected. Custom Attributes Module 0.1.0 to 0.3.0 must be updated to 0.4.0 or higher.

How do I apply the SessionReaper patch?

Download VULN-32437-2-4-X-patch.zip from repo.magento.com, unzip it into your project root, and apply with composer. Run on staging first, verify the cart and customer flows still work, then deploy to production. The full process for emergency hotfixes follows the same pattern as quarterly security patches.

Is the patch alone enough?

The patch closes the deserialization flaw and stops new exploitation. It does not remove webshells already planted by attacks that landed before the patch. Any store that ran an unpatched build between September 9, 2025, and the date you applied the patch should be scanned for IOCs.

What happens if I do not patch?

You join the 62% of stores Sansec tracked as still vulnerable as of late 2025. Active exploitation continues. Webshells get planted. Customer accounts get taken over. PII gets exfiltrated. The forensic and notification cost of a confirmed breach exceeds the cost of an emergency patch by orders of magnitude.

Can a WAF stop SessionReaper without the patch?

A WAF buys time. It does not replace the patch. A WAF that inspects request bodies and matches the SessionReaper signatures blocks both the file-upload vector and the session-takeover vector. The patch is still required, since attackers iterate on payloads and signature-based detection lags new variants.

How do I know if my store was attacked?

Search your filesystem for the IOC file names: static.php, bootstrap.php, sysapi.php, and any new .php file under pub/media/customer_address/. Compare your pub/errors/404.php against the source repository version. Run Sansec eComscan or an equivalent malware scanner. Check outbound traffic logs for connections to worcksbot.com or sagecrafft.com.

Does Adobe Commerce Cloud get this patch automatically?

Adobe deployed WAF rules to the Cloud Infrastructure platform that block known SessionReaper signatures. The application patch still needs to be merged into your Cloud project. Adobe issued the patch through the standard Cloud release pipeline. Customers on the Customer Success Engineer track received direct guidance.

Conclusion

SessionReaper is the latest in a sequence of critical Magento RCE chains, following CosmicSting (CVE-2024-34102) in 2024. The pattern is consistent: an emergency patch ships, a fraction of merchants apply it on time, and the rest learn about the bug from their incident response invoice. Two attack vectors, one nested deserialization flaw, seven months of active exploitation, and 62% of stores still exposed.

The fix is straightforward. Apply APSB25-88. Deploy WAF rules for both vectors. Move sessions off the filesystem. Run file-integrity monitoring. If any of those four tasks have been on your backlog since October, the right next step is a hosting layer that does them by default. See how managed Magento hosting handles emergency patches like this one.