Adobe Commerce at Risk: SessionReaper Exploits Demand Immediate Patching

📅 October 22, 2025 | ⏱ 6 min read | 🔐 Category: E-commerce Security

A critical flaw in Adobe Commerce and Magento Open Source is now being actively abused to hijack customer accounts and, in common configurations, potentially escalate to full compromise of a storefront. The vulnerability, tracked as CVE-2025-54236 and nicknamed SessionReaper, carries a critical severity (CVSS 9.1) and stems from improper input handling in the Commerce REST API. Six weeks after Adobe’s emergency fix, attack traffic has ramped up, with e-commerce security telemetry recording hundreds of real-world attempts across multiple retailers in a single day.

Adobe’s advisory (APSB25-88) covers branches 2.4.9-alpha2, 2.4.8-p2, 2.4.7-p7, 2.4.6-p12, 2.4.5-p14, and 2.4.4-p15, along with earlier patch levels in each line. The practical impact is stark: an attacker can seize active sessions without any user action, impersonate customers, and abuse checkout flows. Under widely deployed defaults, particularly file-based session storage the path to code execution becomes more plausible, which is why researchers have called this one of the most severe issues in the platform’s history.

What’s happening in the wild

E-commerce defenders have begun blocking coordinated probes and exploitation attempts that target vulnerable REST endpoints, often starting with low-friction reconnaissance (for example, phpinfo-style requests) followed by efforts to plant lightweight webshells. In one 24-hour window, more than 250 SessionReaper attempts were stopped across different stores, with notable sources including 34.227.25.4, 44.212.43.34, 54.205.171.35, 155.117.84.134, and 159.89.12.166. At the same time, a deep-dive technical write-up of the bug’s root cause and data flows hit the public domain, which typically accelerates copycat exploitation.

Patch adoption has been too slow for the pace of threats. Early scans showed only about one in three sites patched within the first 10 days. Weeks later, a majority of Magento installations still appear unprotected. Sansec estimates roughly 62% remain at risk. Given that automated tools sweep the web for vulnerable endpoints, lagging patch rates translate directly into more compromises.

Why this bug is so dangerous

SessionReaper strikes at the trust boundary of modern commerce stacks: the API layer mediating sessions, identity, and transactions. Because exploitation does not require credentials or user clicks, attackers can move directly from scanning to action. The common practice of storing sessions on the filesystem amplifies risk by making certain attack chains easier to assemble. Separate research also highlights risky patterns around complex deserialization and type handling in the platform’s API ecosystem, areas where strict validation, consistent schemas, and hardened serializers matter a great deal. The bottom line is that a single missed validation can cascade into account takeover and, in poorly constrained environments, remote code execution.

What merchants should do right now

Prioritize patching above other work. Identify your branch and apply Adobe’s hotfix or the latest cumulative security release for your 2.4.x line as soon as testing allows. If you’re multiple cycles behind, carve out an emergency maintenance window rather than deferring; leaving a public-facing commerce site unpatched during active exploitation carries outsized business risk.

Reduce exposure while you patch. If you still rely on file-based session storage, plan a move to Redis or a database-backed store and harden permissions on any writable directories. Limit the API surface by disabling unused modules, enforcing allowlists for sensitive endpoints, and adding rate limits and anomaly detection around login, checkout, and session workflows. Ensure that PHP execution is blocked in writable paths such as media, var, and pub where feasible. Require MFA for all admin accounts, restrict back-office access by IP, and rotate any integration tokens that have broad privileges.

Turn on visibility and look for evidence of tampering. Review web and API logs for malformed or unusually large request bodies, spikes in session creation or resumption, and anomalous traffic to customer or checkout endpoints. Hunt for unexpected files in pub/media, var, or theme directories, and scan for obfuscated PHP artifacts or recently modified templates and CMS blocks. If you see phpinfo requests or unexplained 5xx errors around REST routes, treat them as potential precursors to exploitation. Consider short-term blocks on active probing sources, but don’t rely on allow/deny lists alone; resilient detection and response is more effective than whack-a-mole.

If compromise is suspected, act decisively. Invalidate all customer and admin sessions, rotate API keys and secrets, and review recent configuration changes—particularly payment settings, shipping rules, and access control lists. Run integrity checks on code and assets, inspect outbound connections for command-and-control patterns, and preserve logs for investigation. Engage your incident response playbook and prepare regulatory notifications if customer data could be affected.

Guidance for developers and agencies

After applying the fix, regression-test custom modules that interact with the Web API and session state. Tighten input validation on complex parameters, avoid dynamic class instantiation, and reduce reliance on deserializing untrusted structures. Review third-party extensions for known issues and update or replace where necessary. This is also a good time to codify secure defaults in your deployment pipeline: enforce non-executable writable directories, secure session backends, and explicit API policies by configuration rather than convention.

The path forward

SessionReaper is a reminder that in e-commerce, the API edge is the business edge. With attackers already taking shots at unpatched sites, the window for comfortable planning has closed. Patch today, trim your attack surface, and give your monitoring the attention it deserves. If a full upgrade cannot happen immediately, put compensating controls in place and schedule the earliest possible maintenance.

Written by: Logan Elliott
Cyberix
https://cyberixsafe.com