Quick Summary: CVE-2025-54236 (“SessionReaper”) is a critical unauthenticated session-takeover flaw in Adobe Commerce and Magento Open Source 2.4.4–2.4.9-alpha2. Attackers can create a normal account and, using a crafted REST API payload, hijack any customer or admin session instantly. Public exploits appeared in October 2025, enabling RCE via upload modules. CISA later listed it with a federal patch deadline of November 14, 2025.
If you’re running a Magento or Adobe Commerce online store, you’ve likely heard the buzz or the alarm bells about CVE-2025-54236. Dubbed “SessionReaper” by security researchers, this critical vulnerability has been making waves in the e-commerce world. During a regular security audit at a client site, our team personally experienced this only a few months ago. What started as a nagging performance glitch turned into a full-blown incident response nightmare. Customer accounts were at risk, and the potential for session hijacking loomed large.
In this post, we’ll break it down step by step: what the issue is, Adobe’s official take, how attackers exploit it (so you can spot the signs), and most importantly, how to fix it for good. Our goal? Get equipped with the know-how to keep your store safe from such troubles, which turned out to be very inconvenient for us. Dive in!
The Issue: What is CVE-2025-54236?
At its core, CVE-2025-54236 is an Improper Input Validation vulnerability lurking in Adobe Commerce and Magento Open Source platforms. It allows attackers to manipulate object deserialization processes, leading to full session takeover. Just picture an unauthorized user silently sneaking into any customer account without the need for their password, no phishing emails, no brute-force attempts, simply taking advantage of a security loophole in the way the system deals with API inputs.
Key Details from the National Vulnerability Database (NVD)
According to the NVD, this flaw affects a wide swath of versions:
| Product | Affected Versions |
| 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, 2.4.4-p15 and earlier |
| Adobe Commerce B2B | 1.5.3-alpha2 and earlier, 1.5.2-p2 and earlier, 1.4.2-p7 and earlier, 1.3.4-p14 and earlier, 1.3.3-p15 and earlier |
| Magento Open Source | 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 |
| Custom Attributes Serializable Module | Versions 0.1.0 to 0.4.0 |
- Impact: These risks are of the highest confidentiality and integrity nature. Malicious hackers may pretend to be legitimate users, steal sensitive data (for example, the record of purchases or personal information), and, to an extent, change the account details as well.
- Exploitation Requirements: No user interaction needed; it’s unauthenticated and remote.
- Severity: While the NVD hasn’t finalized a CVSS score yet, Adobe rates it as Priority 1 (Critical).
- Timeline: Published on September 9, 2025, with updates as recent as November 24, 2025. It’s already in the CISA Known Exploited Vulnerabilities Catalog, meaning federal agencies must patch by November 14, 2025.
In our case, we spotted anomalous login patterns on a 2.4.6-p10 instance. Traffic logs showed API calls spiking from unfamiliar IPs, and customer support tickets poured in about “mystery logins.” If your store handles payments or PII, this isn’t just a theoretical risk; it’s a ticking time bomb.
Adobe’s Official Explanation: Straight from the Source
In its warning, Adobe was very straightforward. This vulnerability stems from a flaw in the Commerce REST API’s handling of serialized objects, specifically in the ServiceInputProcessor.php file’s getConstructorData method. A previous patch aimed to whitelist “safe” parameter types (simple scalars or API data objects), but clever attackers can chain objects to bypass it, injecting malicious data into session storage.
From Adobe’s Knowledge Base article (KA-27397) and Security Bulletin APSB25-88:
- Root Cause: The system deserializes untrusted input without proper validation, allowing nested object construction that reaches sensitive classes like Magento\Customer\Model\Session\Proxy. This proxy handles customer sessions but exposes setters (e.g., setCustomerId) that can be abused to overwrite session data.
- Attack Vector: Primarily via REST API endpoints marked as “anonymous” or “self” in webapi.xml. No admin privileges required, just a valid JWT token from a low-privilege account.
- Real-World Ramifications: Account takeovers could lead to data theft, fraudulent orders, or compliance nightmares (think GDPR or PCI-DSS violations).
Adobe emphasizes that this isn’t a zero-day anymore, exploits are public, and they’ve seen active attempts. For cloud-hosted setups (like Adobe Commerce on Cloud), they’ve rolled out WAF rules as a stopgap, but on-premises or self-managed stores? You’re on your own until you patch.
Essentially, it was a similar scenario in our case: The customer’s account at a very low level was hacked, and from there the attacker was able to elevate the rights up to the admin level, and he started copying the order data.
Exploitation Steps: How SessionReaper Works in Theory and Practice
Knowledge is your best defense, especially against something as insidious as SessionReaper. Security firm Pentest-Tools.com reverse-engineered this as “SessionReaper” and shared a comprehensive proof-of-concept (PoC), complete with local setup guides and chain analysis scripts. It’s not overly complex for a skilled attacker to think like a pentester with Burp Suite, some PHP debugging chops, and a weekend to map dependencies.
But the real terror? Since the PoC dropped on October 22, 2025, Akamai has logged over 300 exploitation attempts across 130+ hosts from just 11 IPs in 48 hours, including web shell payloads for persistent RCE. Sansec blocked dozens more, as attackers probed for phpinfo() leaks and uploaded shells.
It is kind of a chain, each step leading to the next, the attacker exploiting the mechanics of the chain, falling into the traps that lead from one real-world instance of escalation to another. So we can understand the story better, I have presented it in sections with the details of the chain, the traps, and the real-world escalations.
The Theory Behind the Exploit
The vulnerability (CWE-20: Improper Input Validation) hides in ServiceInputProcessor.php’s getConstructorData method, which deserializes JSON payloads for API requests. Adobe’s initial patch whitelisted “safe” types, simple scalars (ints, strings), or classes matching ~\\\\?\w+\\\\\w+\\\\Api\\\\Data\\\\~ to block arbitrary object instantiation. However, the attackers continue to operate in a very hidden manner by going through the nested constructors and setters one after another.
Object Chaining: The Core Mechanic
Magento’s Dependency Injection (DI) system, defined in di.xml, maps interfaces to proxies or concrete classes. The exploit automates chain discovery:
- Parse webapi.xml for “self” (customer-auth) or “anonymous” endpoints.
- Recurse through method signatures: Start at top-level params (e.g., quote in cart updates), resolve types via namespace imports and DI prefs, traverse constructors (depth limit: 5 to avoid loops), and flag exposed setters.
- Goal: Reach a class with writable session data.
This builds recursively in ServiceInputProcessor::_createFromArray, instantiating proxies despite protected constructors (e.g., needing objectManager). The proxy’s customer_base namespace auto-serializes to /var/session/ files, poisoning the pool.
Bypassing Whitelists and Proxies
The patch skips non-whitelisted constructor params, but:
- Chains use whitelisted API Data Objects as stepping stones.
- Setters like setCustomerId accept simple types (int), evading checks proxies expose them for “convenience,” but without validation.
- Session bridge: APIs run on JWT (stateless), but web frontends trust PHPSESSID cookies. The exploit generates a tainted session file that can be transferred via Set-Cookie.
- Debug logs (added to ServiceInputProcessor) reveal: [DBG] creating: Magento\Customer\Model\Session\Proxy followed by setter calls.
Escalation Potential: From Session Takeover to Full Remote Code Execution
While the core SessionReaper exploit “only” gives account takeover, real-world attackers rarely stop there. After the attackers manage to take over a customer session, they do not waste any time and directly move to the post-exploitation paths that can lead to turning the takeover into a complete server compromise (RCE).
Most common chain observed by Akamai, Sansec, and GreyNoise since October 2025:
- Hijack a low-privilege customer → use the stolen session on the web frontend.
- Abuse still-unpatched or misconfigured modules (e.g., Page Builder, Custom Layouts, or third-party attribute editors) that allow file uploads or template injection while logged in.
- Upload a PHP webshell disguised as an image, CSS file, or layout XML update. Typical one-liner seen in the wild: <?php @system($_GET[‘cmd’]); @die(); ?>
- Trigger the shell via direct request, achieving persistent RCE.
Other means of attack could be a diffing malicious cron expression injection, manipulation of system configuration backups, or stored XSS in admin menus to steal admin cookies.
MITRE ATT&CK mapping:
- TA0001 – Initial Access (Exploit Public-Facing Application)
- TA0002 – Execution → T1505.003 (Web Shell)
- TA0003 – Persistence & Privilege Escalation
In short: SessionReaper is the perfect entry ticket. Within 10–30 minutes of the first hijack, skilled attackers routinely achieve persistent code execution on unhardened stores. Patching CVE-2025-54236 is mandatory. However, the only real way to disrupt the kill chain is by taking away upload capabilities from the customer scope.
How to Fix It: Patching and Prevention
The good news? Adobe’s fix is straightforward and effective. Bulletin APSB25-88 provides a hotfix that hardens input validation, blocking those sneaky chains.
Official Patch Steps
- Download and apply the Hotfix Grab VULN-32437-2-4-X-patch.zip from Magento’s repo. Unzip and run:
composer apply-patches.php –patch https://repo.magento.com/patch/VULN-32437-2-4-X-patch.zip
Compatible with 2.4.4–2.4.7; for alphas/newer, upgrade fully. - Handle the Custom Attributes Module. If using magento/out-of-process-custom-attributes extension versions 0.1.0–0.3.0: upgrade it to the latest version
composer require magento/out-of-process-custom-attributes=0.4.0 –with-dependencies
Then: bin/magento setup:upgrade && bin/magento cache:flush. - Cloud/Managed Services
- On Cloud: WAF blocks are still live. Apply the hotfix via support.
- Managed: Ping your Customer Success Engineer.
- Verify and Monitor
- Re-run vulnerability scanners (e.g., Pentest-Tools Sniper).
- Enable API logging and watch for chaining patterns.
- Update to the latest stable (2.4.8-p3 recommended).
We applied this in under an hour during our incident downtime, minimal, relief immediate.
Pro tip: Test in staging first.
Key Takeaways
- Suppose you are on any 2.4.x version before the September 2025 security patches → you are vulnerable right now.
- Customer registration enabled = instant low-privilege foothold for attackers.
- Session hijacking is only step one; in the real world, attacks quickly escalate to persistent webshells and RCE.
- Adobe Commerce Cloud has partial WAF mitigation, but the official hotfix is still mandatory.
- Patch immediately (APSB25-88 hotfix), flush sessions, restrict self-registration if possible, and monitor for nested JSON on cart/quote endpoints. Delaying is not an option; hundreds of stores are being compromised daily. Patch today or become tomorrow’s breach headline.
Wrapping Up: Don’t Let SessionReaper Reap Your Store
CVE-2025-54236 is not just another Magento bug; it’s one of the most dangerous session takeover flaws ever disclosed for Adobe Commerce. With public exploits circulating since October 2025, active attacks spiking (Akamai and Sansec report hundreds of attempts daily), and CISA adding it to the Known Exploited Vulnerabilities catalog, the window for safe procrastination has closed.
Any 2.4.x version of your store that is prior to the September 2025 patches is simply a target. In other words, just one unpatched instance to be found with the registration of customers enabled is sufficient for a malicious intruder to take over the accounts of any users, administrators included, within a few minutes.
Install the official hotfix without delay, turn off or limit self-registration as much as possible, enable detailed API logging, and think about temporary WAF rules during the testing period. It is no longer a matter of risk when “we’ll patch next quarter” in 2025; it is actually a certainty that the system will be compromised.
Stay vigilant, patch today, and keep SessionReaper buried.
FAQs
Is my Magento store vulnerable to SessionReaper?
Yes, if you run Adobe Commerce or Magento Open Source 2.4.4 through 2.4.9-alpha2 (or earlier patch levels) without the official hotfix.
Do I need admin access for attackers to exploit this?
No. Just by registering a customer account, attackers can do whatever they want. In addition, certain anonymous endpoints can also be used for session hijacking.
Can this vulnerability lead to full server compromise (RCE)?
Yes. There are cases where the attackers in the wild have used this vulnerability in combination with other ones to upload webshells and get remote code execution.
I’m on Adobe Commerce Cloud. Am I safe?
Although Cloud instances are WAF-protected, the security is only complete after the hotfix is applied by Adobe.
How fast should I patch CVE-2025-54236?
As soon as possible. CISA has issued a federal mandate for patching, which should be done by November 14, 2025, and there are hundreds of stores that are being attacked every day.
CEO | SetuBridge Technolabs
Sagar Panchal, Founder of SetuBridge Technolabs, is a Magento-certified expert with 15+ years in eCommerce development. He has successfully led global projects, blending technical expertise and strategic vision to deliver scalable, high-performing online stores for businesses worldwide.
