CVE-2025-54236

Adobe Commerce / Magento Improper Input Validation (CVE-2025-54236)

Detects exploitation of CVE-2025-54236, an improper input validation vulnerability in Adobe Commerce and Magento. This KEV-listed vulnerability allows attackers to submit maliciously crafted input to Commerce/Magento endpoints, potentially leading to remote code execution, unauthorized data access, or store compromise. Detection focuses on anomalous HTTP request patterns to Magento/Commerce endpoints, unexpected PHP execution, and indicators of post-exploitation activity.

Vulnerability Intelligence

KEV — Known Exploited

Affected Software

Vendor
Adobe
Product
Commerce and Magento

Weakness (CWE)

Timeline

Disclosed
October 24, 2025

CVSS

9.1
Critical (9.0–10)

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Write-up coming soon

What is CVE-2025-54236 Adobe Commerce / Magento Improper Input Validation (CVE-2025-54236)?

Adobe Commerce / Magento Improper Input Validation (CVE-2025-54236) (CVE-2025-54236) maps to the Initial Access and Execution and Persistence and Impact tactics — the adversary is trying to get into your network in MITRE ATT&CK.

This page provides production-ready detection logic for Adobe Commerce / Magento Improper Input Validation (CVE-2025-54236), covering the data sources and telemetry it touches: IIS Logs, Azure Application Gateway, WAF/Proxy Logs, CommonSecurityLog. The queries below are rated critical severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Initial Access Execution Persistence Impact
Microsoft Sentinel / Defender
kusto
let MagentoEndpoints = dynamic(['/rest/', '/api/', '/index.php/rest/', '/pub/index.php', '/graphql', '/downloader/', '/admin/']);
let SuspiciousPatterns = dynamic(['eval(', 'base64_decode', 'system(', 'exec(', 'passthru(', 'shell_exec', 'phpinfo', '<?php', 'assert(', 'preg_replace']);
union
(
    W3CIISLog
    | where csUriStem has_any (MagentoEndpoints)
    | where csMethod in ('POST', 'PUT', 'PATCH')
    | where scStatus in (200, 201, 500)
    | where csUriQuery has_any (SuspiciousPatterns) or csBytes > 50000
    | extend RequestPath = strcat(csUriStem, '?', csUriQuery)
),
(
    AzureDiagnostics
    | where Category == 'ApplicationGatewayAccessLog'
    | where requestUri_s has_any (MagentoEndpoints)
    | where httpMethod_s in ('POST', 'PUT', 'PATCH')
    | where httpStatus_d in (200, 500)
    | extend RequestPath = requestUri_s
),
(
    CommonSecurityLog
    | where DeviceVendor in ('Apache', 'nginx', 'F5', 'Imperva')
    | where RequestURL has_any (MagentoEndpoints)
    | where RequestMethod in ('POST', 'PUT', 'PATCH')
    | extend RequestPath = RequestURL
)
| summarize RequestCount=count(), UniqueIPs=dcount(cIP), Paths=make_set(RequestPath, 20) by bin(TimeGenerated, 5m), cIP
| where RequestCount > 10 or UniqueIPs > 5
| extend AlertSeverity = iff(RequestCount > 50 or UniqueIPs > 20, 'Critical', 'High')
| project TimeGenerated, SourceIP=cIP, RequestCount, UniqueIPs, SuspiciousPaths=Paths, AlertSeverity

Detects suspicious POST/PUT/PATCH requests to Adobe Commerce/Magento REST API, GraphQL, and admin endpoints that may indicate CVE-2025-54236 exploitation. Flags high-volume requests, oversized payloads, and requests with embedded code patterns.

critical severity medium confidence

Data Sources

IIS Logs Azure Application Gateway WAF/Proxy Logs CommonSecurityLog

Required Tables

W3CIISLog AzureDiagnostics CommonSecurityLog

False Positives

  • Legitimate bulk API operations from integration partners or ERP systems sending large POST payloads
  • Automated e-commerce workflows (order sync, inventory updates) triggering high request volumes
  • Security scanners or penetration testing tools targeting the Magento application
  • Load balancer health checks hitting REST endpoints repeatedly

Sigma rule & cross-platform mapping

The detection logic for Adobe Commerce / Magento Improper Input Validation (CVE-2025-54236) (CVE-2025-54236) above is provided in a vendor-neutral form so you can deploy it on any SIEM. The same logic is shipped here as native KQL (Microsoft Sentinel / Defender), SPL (Splunk), Elastic (Elastic Security (EQL)), QRadar (IBM QRadar (AQL)), Sumo (Sumo Logic CSE), YARA-L (Google Chronicle / SecOps), LogScale (CrowdStrike LogScale (CQL)) queries. In Sigma terms, this detection targets the following logsource:

logsource:
  category: network_connection
  product: windows

Browse the community-maintained Sigma rules for this technique:


Testing Methodology

Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.

  1. Test 1Magento REST API Malformed Input Fuzzing

    Expected signal: Web server access logs should show POST requests to /rest/V1/products and /rest/V1/customers with large Content-Length values and HTTP 400/500 response codes

  2. Test 2PHP Web Shell Upload via Compromised Magento Admin

    Expected signal: IIS/Apache logs showing POST to admin CMS endpoint; filesystem monitoring alerts on new .php file creation in pub/media/; process execution logs if PHP is evaluated

  3. Test 3Rapid Sequential API Endpoint Reconnaissance

    Expected signal: Web server access logs showing rapid sequential POST requests to multiple /rest/V1/ endpoints from a single source IP within a short timeframe


Response Playbook

Triage

  1. Identify source IPs making repeated POST/PUT/PATCH requests to /rest/, /graphql, or /admin/ endpoints and cross-reference against threat intelligence feeds for known malicious actors.
  2. Review HTTP response codes for the flagged requests — a pattern of HTTP 200 responses to unusual payloads or HTTP 500 errors from malformed input strongly indicates active exploitation attempts.
  3. Check server-side PHP error logs (/var/log/php*, /var/log/apache2/error.log, Windows Event Log Application) for eval() errors, unexpected function calls, or PHP fatal errors correlating with the suspicious request timestamps.
  4. Determine Adobe Commerce and Magento version to confirm whether it falls within the affected range and whether the relevant security patches have been applied.

Containment

  1. Immediately block source IPs identified in triage at the WAF or network perimeter if exploitation is confirmed; consider geo-blocking if the attack originates from unexpected regions.
  2. Place the Adobe Commerce/Magento application in maintenance mode (`php bin/magento maintenance:enable`) to prevent further exploitation while patches are applied and forensic analysis is completed.

Evidence Collection

  1. Capture and preserve web server access logs (IIS/Apache/Nginx) covering the exploitation window, including full URI paths, request bodies where logged, response codes, and timing data.
  2. Collect PHP error logs, Magento exception logs (var/log/exception.log, var/log/system.log), and any WAF alert logs. Archive the Magento codebase snapshot to detect any webshells or modified files using `find /var/www/html -name '*.php' -newer /var/www/html/pub/index.php -ls`.

Escalation Criteria

  • ! Escalate immediately if evidence of successful code execution is found — e.g., new PHP files in pub/, media/, or var/ directories, or unexpected child processes from the web server user.
  • ! Escalate to incident response if customer PII, payment card data (PCI scope), or admin credentials may have been accessed or exfiltrated, triggering breach notification obligations.

Investigation Guide

Forensic Artifacts

  • > Web server access logs showing anomalous POST/PUT requests to /rest/, /graphql, /index.php/rest/ with unusual payloads or response patterns
  • > PHP error logs containing eval(), preg_replace() with /e modifier, assert(), or similar dangerous function call traces
  • > Filesystem artifacts: newly created or modified .php files in pub/media/, pub/static/, var/, or app/ directories that were not part of a legitimate deployment
  • > Process execution history showing web server worker processes (php-fpm, apache, w3wp) spawning shells, curl, wget, or other unexpected child processes

Tuning Guidance

Start by baselining legitimate API integration IPs (ERP systems, PIM tools, payment gateways) and adding them to allowlists to reduce false positives. Adjust the request count threshold (default: >10 per 5 minutes) based on your environment's API usage patterns — high-volume B2B Commerce instances may require a higher threshold (50+) or time-of-day restrictions. If your WAF logs request bodies, add payload-based rules to detect PHP function signatures (eval, base64_decode, system) directly, which will dramatically improve confidence. For environments without web server log forwarding, prioritize deploying Falcon or an equivalent EDR agent to catch process spawn anomalies as a compensating control.


Hunting Queries

Threat hunt for successful (HTTP 200) POST requests to Magento REST and GraphQL endpoints over the past 7 days. Helps identify exploitation that may have occurred before detection rules were deployed.

Hunting — KQL
kql
W3CIISLog
| where TimeGenerated > ago(7d)
| where csUriStem has_any ('/rest/', '/graphql', '/index.php/rest/')
| where csMethod in ('POST', 'PUT', 'PATCH')
| where scStatus == 200
| summarize count() by csUriStem, cIP, bin(TimeGenerated, 1h)
| where count_ > 3
| order by count_ desc
Hunting — SPL
spl
index=web (uri_path="*/rest/*" OR uri_path="*/graphql*") method=POST status=200 earliest=-7d
| stats count by src_ip, uri_path, _time span=1h
| where count > 3
| sort - count

Atomic Red Team Tests

Test 1 Magento REST API Malformed Input Fuzzing
linux

Simulates an attacker probing the Magento REST API with oversized and malformed input payloads to trigger improper input validation behavior consistent with CVE-2025-54236.

Command

bash
#!/bin/bash
# Lab/authorized testing only — target your own Magento test instance
TARGET_HOST="http://magento-lab.internal"

# Test 1: Large payload to REST endpoint
curl -s -X POST "${TARGET_HOST}/rest/V1/products" \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer REPLACE_WITH_TEST_TOKEN' \
  -d '{"product":{"sku":"'$(python3 -c "print('A'*65536)'","name":"Test"}}' \
  -w "\nHTTP_STATUS:%{http_code}" -o /tmp/test1_response.txt

# Test 2: Special characters in input fields
curl -s -X POST "${TARGET_HOST}/rest/V1/customers" \
  -H 'Content-Type: application/json' \
  -d '{"customer":{"email":"test+<script>alert(1)</script>@test.com","firstname":"\"\';DROP TABLE--","lastname":"Test"}}' \
  -w "\nHTTP_STATUS:%{http_code}" -o /tmp/test2_response.txt

echo "Test results saved to /tmp/test1_response.txt and /tmp/test2_response.txt"
cat /tmp/test1_response.txt
cat /tmp/test2_response.txt

Cleanup

bash
rm -f /tmp/test1_response.txt /tmp/test2_response.txt

Expected Telemetry

Web server access logs should show POST requests to /rest/V1/products and /rest/V1/customers with large Content-Length values and HTTP 400/500 response codes

Expected Detection

SPL and KQL queries should trigger on the large payload size (>50000 bytes) and high request rate thresholds

Test 2 PHP Web Shell Upload via Compromised Magento Admin
linux

Simulates post-exploitation activity where an attacker uploads a PHP web shell through Magento's file upload functionality after gaining admin access via CVE-2025-54236.

Command

bash
#!/bin/bash
# Lab/authorized testing only
TARGET_HOST="http://magento-lab.internal"
ADMIN_PATH="/admin_lab123"

# Simulate web shell upload to pub/media (commonly writable)
# The 'shell' content here is a benign echo command for lab detection testing
MINIMAL_TEST_PAYLOAD='<?php echo "CVE-2025-54236-test-" . phpversion(); ?>'

curl -s -X POST "${TARGET_HOST}${ADMIN_PATH}/cms_block/save/" \
  -b 'PHPSESSID=lab_test_session' \
  -F "content=${MINIMAL_TEST_PAYLOAD}" \
  -F "title=test" \
  -F "identifier=test-block" \
  -w "\nHTTP_STATUS:%{http_code}" \
  -o /tmp/webshell_test_response.txt

echo "Response:"; cat /tmp/webshell_test_response.txt

Cleanup

bash
rm -f /tmp/webshell_test_response.txt; # Remove any test files created in pub/media/ on the test server

Expected Telemetry

IIS/Apache logs showing POST to admin CMS endpoint; filesystem monitoring alerts on new .php file creation in pub/media/; process execution logs if PHP is evaluated

Expected Detection

CrowdStrike CQL process spawn detection if the payload executes; filesystem integrity monitoring alerts on new PHP files in web-accessible directories

Test 3 Rapid Sequential API Endpoint Reconnaissance
linux

Simulates an attacker rapidly probing multiple Magento REST API endpoints to identify vulnerable input vectors, matching the scanning behavior that precedes CVE-2025-54236 exploitation.

Command

bash
#!/bin/bash
# Lab/authorized testing only — run against your own Magento test instance
TARGET_HOST="http://magento-lab.internal"

ENDPOINTS=(
  "/rest/V1/products"
  "/rest/V1/customers"
  "/rest/V1/orders"
  "/rest/V1/carts"
  "/graphql"
  "/rest/V1/store/storeConfigs"
  "/rest/V1/directory/countries"
)

for endpoint in "${ENDPOINTS[@]}"; do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" -X POST \
    "${TARGET_HOST}${endpoint}" \
    -H 'Content-Type: application/json' \
    -d '{"test":"CVE-2025-54236-probe"}')
  echo "[$(date +%T)] POST ${endpoint} -> HTTP ${STATUS}"
  sleep 0.5
done

Cleanup

bash
No cleanup required — read-only probe test

Expected Telemetry

Web server access logs showing rapid sequential POST requests to multiple /rest/V1/ endpoints from a single source IP within a short timeframe

Expected Detection

KQL and SPL detection rules should fire on the high request rate (7+ requests in under 5 minutes) to Magento API endpoints from a single IP

Related Detections