Adobe Commerce versions 2

CVE-2025-54236 is an improper input validation flaw in Adobe Commerce, Adobe Commerce B2B, and Magento Open Source that lets an unauthenticated attacker abuse the Commerce REST API for customer session takeover, and in some chains for remote code execution. Adobe lists 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; 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; and the magento/out-of-process-custom-attributes module 0.1.0 to 0.3.0 requiring upgrade to 0.4.0+.

The vendor's CRITICAL 9.1 label is basically right. The only serious downward friction is that the nastiest RCE path appears to depend on file-based session storage and adjacent upload behavior, but that does not rescue this issue: the reachable attack surface is still a public web API on internet-facing commerce sites, exploitation is in the wild, CISA added it to KEV on 2025-10-24, and account takeover on a live storefront already carries direct fraud and brand damage even before you get to shell access.

Why this verdict

• No-auth remote starting point: the chain begins from unauthenticated remote access over the network, which means no phishing stage, no local code execution, and no stolen credential prerequisite.
• Public-facing population within the affected product set: Adobe Commerce stores are meant to be reachable from the internet; the vulnerable surface is not some buried admin-only RPC port.
• Active exploitation and KEV are real amplifiers: KEV listing on 2025-10-24 plus Adobe's in-the-wild acknowledgement move this from theoretical critical to operationally urgent critical.
• Downward adjustment audited and rejected as insufficient: the strongest RCE chain appears to depend on file-based sessions and adjacent upload behavior, which would normally shave the score down a bit, but the remaining session takeover path is still severe enough to keep the bucket at CRITICAL.
• Modern controls are imperfect here: WAF can help, and Adobe Cloud/Fastly got protections, but third-party research says coverage was partial and public weaponization arrived quickly.

Why not higher?

There is real friction on the absolute worst-case outcome. Full unauthenticated RCE appears to rely on deployment-specific conditions such as file-based session storage and workable upload/execution paths, so this is not the cleanest universal one-packet-to-shell bug across every Magento estate.

Why not lower?

Lowering this would ignore the two facts that matter most to defenders: the attack starts unauthenticated from the internet, and it is already exploited in the wild. Even if some environments blunt the RCE chain, customer session takeover on a public revenue platform is still a business-critical incident class.

1. Block hostile REST patterns now — Deploy or tune WAF/CDN rules for suspicious nested object payloads and abusive /rest/ requests immediately, within hours because this is KEV-listed and actively exploited. This is the fastest way to cut exposure while patch validation catches up.
2. Disable or restrict risky upload paths — Constrain unauthenticated customer upload controllers and ensure upload directories are non-executable immediately, within hours. This specifically attacks the higher-severity chains that turn session abuse into file drop or webshell placement.
3. Hunt for webshells and rogue session artifacts — Search pub/, customer upload locations, and session storage for newly created PHP files, phpinfo() probes, or Sansec-style backdoor patterns immediately, within hours. On already-exposed storefronts, compromise assessment is part of mitigation, not a nice-to-have.
4. Prefer non-file session backends where feasible — If your deployment still uses file-based sessions, prioritize moving to Redis or database-backed sessions as a hardening measure within the CRITICAL window. It does not solve the base bug, but it raises friction on the most dangerous public exploit chains.
5. Verify patch state host-by-host — Do not trust version strings alone; Adobe explicitly notes patch state can be hard to determine. Use package and patch-status checks immediately, within hours so you can separate truly remediated nodes from cosmetics.

Run this on each Magento/Adobe Commerce application host with read access to the install root, for example: sudo bash check_cve_2025_54236.sh /var/www/html. It needs permission to read composer.lock, composer.json, and—if present—run vendor/bin/magento-patches -n status; it does not require internet access.

#!/usr/bin/env bash
# check_cve_2025_54236.sh
# Detect likely exposure to CVE-2025-54236 (SessionReaper) on Adobe Commerce / Magento.
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN / usage / not a Magento root

set -u

ROOT="${1:-}"
if [ -z "$ROOT" ]; then
  echo "UNKNOWN - usage: $0 /path/to/magento-root"
  exit 2
fi

if [ ! -d "$ROOT" ]; then
  echo "UNKNOWN - path does not exist: $ROOT"
  exit 2
fi

LOCK="$ROOT/composer.lock"
JSON="$ROOT/composer.json"
PATCH_TOOL="$ROOT/vendor/bin/magento-patches"
SIP="$ROOT/vendor/magento/framework/Webapi/ServiceInputProcessor.php"

if [ ! -f "$LOCK" ] && [ ! -f "$JSON" ]; then
  echo "UNKNOWN - composer files not found; not a recognizable Magento root"
  exit 2
fi

# Parse product version from composer.lock first, then composer.json as fallback.
get_version() {
  local file="$1"
  awk '
    BEGIN{pkg=""; ver=""}
    /"name": "magento\/product-community-edition"/ {pkg="community"}
    /"name": "magento\/product-enterprise-edition"/ {pkg="enterprise"}
    pkg != "" && /"version":/ {
      gsub(/[",]/, "", $2);
      print $2;
      exit
    }
  ' "$file" 2>/dev/null
}

PRODUCT_VERSION=""
if [ -f "$LOCK" ]; then
  PRODUCT_VERSION="$(get_version "$LOCK")"
fi
if [ -z "$PRODUCT_VERSION" ] && [ -f "$JSON" ]; then
  PRODUCT_VERSION="$(get_version "$JSON")"
fi

# Parse custom attributes module version if present.
get_module_version() {
  local file="$1"
  awk '
    BEGIN{pkg=""}
    /"name": "magento\/out-of-process-custom-attributes"/ {pkg="yes"}
    pkg == "yes" && /"version":/ {
      gsub(/[",]/, "", $2);
      print $2;
      exit
    }
  ' "$file" 2>/dev/null
}

MODULE_VERSION=""
if [ -f "$LOCK" ]; then
  MODULE_VERSION="$(get_module_version "$LOCK")"
fi

# Check if Adobe hotfix appears applied via QPT / magento-patches.
PATCH_EVIDENCE="no"
PATCH_STATUS_OUTPUT=""
if [ -x "$PATCH_TOOL" ]; then
  PATCH_STATUS_OUTPUT="$($PATCH_TOOL -n status 2>/dev/null || true)"
  if echo "$PATCH_STATUS_OUTPUT" | grep -Eiq '32437|54236|Applied'; then
    if echo "$PATCH_STATUS_OUTPUT" | grep -Eiq '32437|54236'; then
      PATCH_EVIDENCE="yes"
    fi
  fi
fi

# Fallback: inspect ServiceInputProcessor for strings commonly introduced by the fix.
FILE_EVIDENCE="no"
if [ -f "$SIP" ]; then
  if grep -Eq 'is not supported\. Correct the field name and try again|Unsupported parameter type for|does not have accessor method' "$SIP"; then
    FILE_EVIDENCE="possible"
  fi
fi

is_vulnerable_version() {
  local v="$1"
  # Explicitly vulnerable ranges from Adobe guidance.
  case "$v" in
    2.4.9-alpha1|2.4.9-alpha2) return 0 ;;
    2.4.8|2.4.8-p1|2.4.8-p2) return 0 ;;
    2.4.7|2.4.7-p1|2.4.7-p2|2.4.7-p3|2.4.7-p4|2.4.7-p5|2.4.7-p6|2.4.7-p7) return 0 ;;
    2.4.6|2.4.6-p1|2.4.6-p2|2.4.6-p3|2.4.6-p4|2.4.6-p5|2.4.6-p6|2.4.6-p7|2.4.6-p8|2.4.6-p9|2.4.6-p10|2.4.6-p11|2.4.6-p12) return 0 ;;
    2.4.5|2.4.5-p1|2.4.5-p2|2.4.5-p3|2.4.5-p4|2.4.5-p5|2.4.5-p6|2.4.5-p7|2.4.5-p8|2.4.5-p9|2.4.5-p10|2.4.5-p11|2.4.5-p12|2.4.5-p13|2.4.5-p14) return 0 ;;
    2.4.4|2.4.4-p1|2.4.4-p2|2.4.4-p3|2.4.4-p4|2.4.4-p5|2.4.4-p6|2.4.4-p7|2.4.4-p8|2.4.4-p9|2.4.4-p10|2.4.4-p11|2.4.4-p12|2.4.4-p13|2.4.4-p14|2.4.4-p15) return 0 ;;
    *) return 1 ;;
  esac
}

module_needs_upgrade() {
  local v="$1"
  case "$v" in
    0.1.0|0.2.0|0.3.0) return 0 ;;
    *) return 1 ;;
  esac
}

DETAILS="product_version=${PRODUCT_VERSION:-unknown}; module_version=${MODULE_VERSION:-not-installed}; patch_tool=$([ -x "$PATCH_TOOL" ] && echo present || echo absent); patch_evidence=$PATCH_EVIDENCE; file_evidence=$FILE_EVIDENCE"

if [ "$PATCH_EVIDENCE" = "yes" ]; then
  echo "PATCHED - Adobe hotfix evidence found; $DETAILS"
  exit 0
fi

if [ -n "$PRODUCT_VERSION" ] && is_vulnerable_version "$PRODUCT_VERSION"; then
  if [ -n "$MODULE_VERSION" ] && module_needs_upgrade "$MODULE_VERSION"; then
    echo "VULNERABLE - affected Commerce/Magento version and custom attributes module needs upgrade; $DETAILS"
    exit 1
  fi
  echo "VULNERABLE - affected Commerce/Magento version with no confirmed hotfix evidence; $DETAILS"
  exit 1
fi

if [ "$FILE_EVIDENCE" = "possible" ]; then
  echo "UNKNOWN - code may contain fix-like strings but no authoritative hotfix evidence; $DETAILS"
  exit 2
fi

echo "UNKNOWN - not in explicitly vulnerable version list or patch state cannot be proven from local artifacts; $DETAILS"
exit 2

Sources

1. Adobe APSB25-88 bulletin
2. Adobe action-required advisory
3. NVD CVE-2025-54236
4. CISA Known Exploited Vulnerabilities Catalog
5. Sansec SessionReaper research
6. NullSecurityX technical analysis
7. Rapid7 Metasploit module
8. Adobe APSB25-94 regular security update line