CVE-2026-71362

Adobe Commerce/Magento Incorrect Authorization Exploitation (CVE-2026-71362)

Initial Access Privilege Escalation Last updated:

Detects exploitation attempts against CVE-2026-71362, an Incorrect Authorization (CWE-863) vulnerability in Adobe Commerce and Magento that is listed in CISA's KEV catalog. The flaw allows an attacker to bypass authorization checks and access or manipulate resources without proper privilege. This detection surfaces anomalous access to privileged admin/REST/GraphQL endpoints, authorization-bypass patterns, and post-exploitation activity such as unexpected admin account creation, config changes, and webshell drops on Magento web servers.

Vulnerability Intelligence

KEV — Known Exploited

What is CVE-2026-71362 Adobe Commerce/Magento Incorrect Authorization Exploitation (CVE-2026-71362)?

Adobe Commerce/Magento Incorrect Authorization Exploitation (CVE-2026-71362) (CVE-2026-71362) maps to the Initial Access and Privilege Escalation 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 Incorrect Authorization Exploitation (CVE-2026-71362), covering the data sources and telemetry it touches: IIS Logs, Web Server Logs. The queries below are rated high severity at medium confidence, and ship for 7 SIEM platforms — KQL, SPL, Elastic, QRadar, Sumo, YARA-L, LogScale.

MITRE ATT&CK

Tactic
Initial Access Privilege Escalation
Microsoft Sentinel / Defender
kusto
let magentoHosts = dynamic(["magento", "commerce"]);
let suspiciousPaths = dynamic(["/rest/", "/graphql", "/admin/", "/index.php/admin", "/rest/V1/customers", "/rest/all/V1", "/rest/default/V1"]);
W3CIISLog
| where csUriStem has_any (suspiciousPaths) or cIP != ""
| where csMethod in ("POST", "PUT", "DELETE", "PATCH")
| extend AuthHeader = tostring(csUserAgent)
| where (scStatus in (200, 201) and csUriStem has_any ("/rest/", "/graphql", "/admin"))
| summarize RequestCount = count(), Paths = make_set(csUriStem, 25), Statuses = make_set(scStatus, 10) by cIP, sSiteName, bin(TimeGenerated, 10m)
| where RequestCount > 20
| project TimeGenerated, cIP, sSiteName, RequestCount, Paths, Statuses

Identifies bursts of authenticated-looking POST/PUT/DELETE requests to Magento REST/GraphQL/admin endpoints returning success codes, indicative of authorization-bypass exploitation of CVE-2026-71362.

high severity medium confidence

Data Sources

IIS Logs Web Server Logs

Required Tables

W3CIISLog

False Positives

  • Legitimate integration middleware (ERP/PIM connectors) making high-volume REST API calls
  • Load testing or synthetic monitoring against the storefront and admin API
  • Bulk product import/export jobs run by store administrators

Sigma rule & cross-platform mapping

The detection logic for Adobe Commerce/Magento Incorrect Authorization Exploitation (CVE-2026-71362) (CVE-2026-71362) 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:
  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 1Simulated Magento REST authorization-bypass burst

    Expected signal: 30 POST requests to /rest/V1/customers logged in the web server access log from a single source IP within a short window.

  2. Test 2Simulated privileged admin account creation via API

    Expected signal: A successful (200/201) POST to an admin user-management endpoint recorded in web logs and a new row in the admin_user table.

  3. Test 3Simulated webshell drop into Magento web root

    Expected signal: Creation of a new PHP file under the Magento web root captured by file-integrity monitoring / EDR file-write telemetry.


Response Playbook

Triage

  1. Confirm the target host runs an affected Adobe Commerce/Magento version and cross-reference against APSB26-92; verify whether the APSB26-92 patch has been applied.
  2. Review the flagged source IP's full request timeline: identify which REST/GraphQL/admin endpoints returned 200/201 without a preceding valid authentication/authorization event.
  3. Check Magento admin_user and admin session tables for accounts or sessions created during the suspicious activity window.
  4. Determine whether the source IP is a known/allowlisted integration partner or an unrecognized external address (enrich with geo/ASN/threat intel).

Containment

  1. Block the offending source IP(s) at the WAF/edge and enable emergency virtual-patching rules for the CVE-2026-71362 authorization-bypass pattern.
  2. Apply the Adobe APSB26-92 security update immediately, or take the storefront admin/API surface offline if patching cannot be completed promptly.
  3. Invalidate all active admin sessions and rotate integration/API tokens and admin credentials that may have been exposed.

Evidence Collection

  1. Preserve web server access/error logs (IIS/Apache/Nginx) and PHP-FPM logs covering the exploitation window.
  2. Capture the Magento database admin_user, integration, and oauth tables plus any modified core_config_data rows for forensic review.
  3. Snapshot the web root to preserve any dropped webshells or modified template/layout files (e.g., under pub/, app/, media/) before remediation.

Escalation Criteria

  • ! Escalate to incident response if a new admin account, integration token, or persistent webshell is confirmed to have been created.
  • ! Escalate to fraud/PCI teams if evidence indicates access to customer PII or payment/order data was possible.
  • ! Escalate to legal/compliance and notify per breach-reporting obligations if unauthorized access to cardholder or personal data is confirmed.

Investigation Guide

Forensic Artifacts

  • > Web server access logs showing successful (200/201) POST/PUT/DELETE to /rest, /graphql, or /admin endpoints from unauthorized sources
  • > New or modified rows in Magento admin_user, integration, oauth_token, and core_config_data tables
  • > Newly created or modified PHP files in the Magento web root (pub/, app/design/, var/, media/)

Tuning Guidance

Baseline known integration source IPs and their normal REST/GraphQL call volumes, then allowlist them to reduce noise. Adjust the per-10-minute request threshold (default 20) to match legitimate API traffic for your store. Focus alerting on state-changing methods to privileged endpoints (integration, user, oauth, customers) rather than read-only catalog browsing, and correlate with the presence/absence of the APSB26-92 patch to prioritize unpatched hosts.


Hunting Queries

Hunts for successful requests to sensitive Magento integration/user-management endpoints that indicate privileged actions performed via the authorization bypass.

Hunting — KQL
kql
W3CIISLog | where csUriStem has_any ("/rest/V1/integration", "/admin/admin/user/save", "/rest/V1/customers") | where scStatus in (200,201) | summarize count() by cIP, csUriStem, bin(TimeGenerated, 1h) | order by count_ desc
Hunting — SPL
spl
index=web (uri_path="*/rest/V1/integration*" OR uri_path="*admin/user/save*" OR uri_path="*/rest/V1/customers*") status IN (200,201) | stats count values(uri_path) by src_ip | sort - count

Atomic Red Team Tests

Test 1 Simulated Magento REST authorization-bypass burst
linux

Sends a burst of unauthenticated POST requests to Magento REST admin endpoints to generate the request pattern the detection keys on (lab only).

Command

bash
for i in $(seq 1 30); do curl -s -o /dev/null -X POST "https://magento.lab.local/rest/V1/customers" -H "Content-Type: application/json" -d '{"customer":{}}'; done

Cleanup

bash
echo 'No persistent artifacts created by request generation; clear test web logs if desired: truncate -s 0 /var/log/nginx/access.log'

Expected Telemetry

30 POST requests to /rest/V1/customers logged in the web server access log from a single source IP within a short window.

Expected Detection

The KQL/SPL threshold rule fires on >20 state-changing requests to REST endpoints from one source IP.

Test 2 Simulated privileged admin account creation via API
linux

Attempts to create an admin user through the Magento admin API to mimic post-exploitation privilege abuse (lab only).

Command

bash
curl -s -X POST "https://magento.lab.local/rest/V1/integration/admin/user" -H "Content-Type: application/json" -d '{"username":"atttest","password":"Lab!2345","role":"Administrators"}'

Cleanup

bash
curl -s -X DELETE "https://magento.lab.local/rest/V1/integration/admin/user/atttest" || echo 'delete admin user atttest via Magento admin panel'

Expected Telemetry

A successful (200/201) POST to an admin user-management endpoint recorded in web logs and a new row in the admin_user table.

Expected Detection

The hunting query for /admin/user/save and integration endpoints surfaces the privileged action.

Test 3 Simulated webshell drop into Magento web root
linux

Writes a benign PHP file into the Magento pub/ directory to emulate post-exploitation webshell persistence (lab only).

Command

bash
echo '<?php echo "lab-test"; ?>' > /var/www/magento/pub/lab_test.php

Cleanup

bash
rm -f /var/www/magento/pub/lab_test.php

Expected Telemetry

Creation of a new PHP file under the Magento web root captured by file-integrity monitoring / EDR file-write telemetry.

Expected Detection

FIM/EDR alerts on an unexpected PHP file written to pub/, corroborating the web-exploitation activity.

Related Detections