Just in time for Halloween, a chilling exploit has emerged from the shadows of the internet.
Dubbed SessionReaper, the critical vulnerability in Magento — now known as Adobe Commerce — has moved from theory to active exploitation.
Security researchers from Akamai have confirmed attacks in the wild, with hundreds of attempts detected within just a few days of a proof-of-concept (PoC) release.
“The most damaging payloads are web shells designed to allow a threat actor to gain persistent access to the web server,” said Akamai researchers.
Exploited within days of disclosure
According to Adobe’s September 2025 security bulletin, the flaw (CVE-2025-54236) was rated as critical and warranted an emergency patch.
When security researchers publicly released a proof-of-concept exploit, attackers rapidly weaponized the code.
Starting on October 22, 2025, Akamai recorded more than 300 exploitation attempts across more than 130 distinct hosts originating from 11 unique IP addresses within two days.
The surge coincides with the busy holiday shopping season, heightening the risk to unpatched e-commerce sites.
How SessionReaper takes over
SessionReaper stems from improper input validation in Magento’s authentication mechanisms.
At its core, this weakness allows an attacker to manipulate session data and impersonate legitimate users — resulting in unauthorized access to administrative dashboards or customer accounts.
While the vulnerability was initially described as a session hijack issue, the public proof-of-concept has demonstrated that it can be exploited for unauthenticated remote code execution.
In other words, attackers can execute arbitrary commands or upload malicious scripts directly to a vulnerable web server without any credentials.
Once exploited, attackers deploy PHP web shells to maintain persistence and control over compromised environments.
Akamai researchers also detected reconnaissance probes such as phpinfo and echo commands — tactics used to map out system configurations before launching more targeted payloads.
Defending against the Reaper
To defend against active SessionReaper exploits and similar threats, organizations should adopt a layered security strategy that combines prompt patching, strict access controls, and continuous monitoring.
- Apply Adobe’s patches across all Magento and Adobe Commerce systems, and maintain a patch management process for future critical flaws.
- Harden servers by limiting PHP execution, disabling risky functions, and enforcing least-privilege permissions.
- Continuously monitor for compromise through WAF alerts, access logs, and file integrity tools to detect web shells or unauthorized changes.
- Restrict admin access to trusted IPs or VPNs, require multi-factor authentication, and audit admin accounts regularly.
- Secure third-party components by removing unused plugins, validating custom code, and segmenting web and database servers.
- Use layered defenses such as WAFs, content security policies, and regular vulnerability scans.
Implementing these measures not only protects against SessionReaper but also strengthens overall cyber resilience.
Attackers move faster than ever
The SessionReaper exploit highlights how even mature platforms like Magento remain vulnerable in today’s threat landscape.
The quick weaponization of the PoC highlights the narrowing window between disclosure and exploitation, a trend fueled by AI tools that automate exploit discovery and adaptation.
Once exploit code is released, threat actors can quickly weaponize it, emphasizing the need for better patch management, threat intelligence, and layered defenses.
E-commerce platforms are especially at risk, as they process sensitive financial data, rely on continuous uptime, and often depend on legacy extensions that conceal hidden flaws.
With the holiday season approaching, organizations that postpone patching may soon find the Grim SessionReaper knocking at their digital doors.
This growing speed and sophistication of exploitation reinforces why organizations must adopt a zero-trust security model, where every user, device, and connection is continuously verified rather than implicitly trusted.





