Adobe Commerce is affected by an Incorrect Authorization vulnerability that could result in privilege…

CVE-2026-71362 is an Incorrect Authorization (CWE-863) vulnerability in Adobe Commerce and Magento Open Source. The flaw allows an unauthenticated, remote attacker to bypass authorization checks — likely through REST or GraphQL API endpoints — and escalate privileges. The CVSS:3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N) confirms this requires zero authentication, zero user interaction, and low attack complexity to achieve high confidentiality and integrity impact. Affected versions span the entire supported Adobe Commerce line: 2.4.4 through 2.4.9 and earlier. Adobe released isolated security patches under bulletin APSB26-92 on 2026-08-11.

Adobe rates this CRITICAL at 9.1, and that rating is fair. An unauthenticated authorization bypass on a platform that processes payment card data, customer PII, and merchant credentials is as dangerous as it sounds. The only reason it doesn't hit 10.0 is the lack of availability impact (A:N) and no scope change (S:U). Adobe assigned a Priority 2 deployment rating (patch within 30 days), which is surprisingly relaxed for a 9.1 unauth bug — noisgate disagrees with that timeline. With ~50,000 Magento/Commerce instances exposed to the internet per Shodan/FOFA data and historically slow patch adoption (~25% uptake after prior critical patches), this is a target-rich environment waiting for a PoC to drop.

Why this verdict

• Unauthenticated network access (PR:N): The attacker needs nothing — no credentials, no prior foothold, no user interaction. This is the lowest-friction initial access profile possible.
• Role multiplier: Adobe Commerce is canonically an e-commerce platform processing payment card data (PCI-DSS scope), customer PII, and merchant credentials. The blast radius of admin-level access is mass data egress of regulated data plus potential Magecart-style supply-chain injection into checkout flows affecting downstream customers. ≥90% of Adobe Commerce installs occupy this high-value data-tier role by definition. The verdict floor is CRITICAL.
• Large exposed population: ~50,000 internet-facing instances per Shodan/FOFA, with historically poor patch velocity (~25% within 30 days). The reachable attack surface is substantial.
• No active exploitation — minor downward pressure only: EPSS is 0.00478 and no PoC is public, which prevents an upgrade beyond 9.1 but does not justify a downgrade given the trivial prerequisites. CWE-863 bugs in Magento's open-source codebase are straightforward to reverse-engineer from patch diffs.

Why not higher?

The CVSS ceiling of 9.1 is already near-maximum for a vulnerability with no availability impact (A:N) and unchanged scope (S:U). There is no evidence of active exploitation or weaponized tooling, and no scope change means the blast radius is contained to the Commerce application itself rather than chaining into underlying OS or infrastructure. A 10.0 would require scope change or active mass exploitation.

Why not lower?

Downgrading below CRITICAL would require evidence that the unauthenticated attack path has meaningful friction — it does not. PR:N + AC:L + AV:N is the most permissive prerequisite set possible. Adobe Commerce is by definition a PCI-data-tier application; the role-multiplier floor for mass data egress of regulated data on a canonical data-tier component is CRITICAL. The absence of a PoC delays exploitation but does not reduce the inherent severity of the flaw.

1. Deploy WAF rules blocking anomalous REST/GraphQL API patterns — Configure your WAF (Cloudflare, Akamai, AWS WAF, or ModSecurity) to rate-limit and inspect /rest/V1/ and /graphql endpoints for unusual parameter patterns, privilege escalation payloads, and unauthenticated access to admin-scoped endpoints. Deploy within 3 days per noisgate mitigation SLA for CRITICAL.
2. Restrict admin panel and API access by IP allowlist — Use .htaccess, nginx allow/deny, or WAF geo/IP rules to limit access to /admin and sensitive REST endpoints to known management IPs only. This reduces the unauthenticated attack surface even before the patch is applied. Deploy within 3 days.
3. Enable Adobe Commerce 2FA for admin accounts — Ensure the built-in Two-Factor Authentication module is enforced for all admin accounts. While this CVE bypasses initial authorization, 2FA adds a layer if the attacker attempts to use escalated credentials interactively. Deploy immediately if not already active.
4. Enable file integrity monitoring on webroot — Deploy FIM (OSSEC, Wazuh, Tripwire, or cloud-native equivalent) on pub/, app/design/, app/code/, and generated/ directories to detect webshell implantation or Magecart skimmer injection post-exploitation. This is a detection control, not prevention.
5. Audit admin session and API access logs — Enable and forward Adobe Commerce admin audit logs and REST/GraphQL access logs to your SIEM. Alert on admin sessions created from unexpected IPs, user agents, or at unusual times. Look for bulk data export operations.

Run this script on each Adobe Commerce host as a user with read access to the Composer composer.lock file and the patches directory (typically the web server user or a deployment user). Example: bash check_cve_2026_71362.sh /var/www/magento2

#!/usr/bin/env bash
# check_cve_2026_71362.sh — Check Adobe Commerce for CVE-2026-71362 (APSB26-92)
# Usage: bash check_cve_2026_71362.sh /path/to/magento/root
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

MAGENTO_ROOT="${1:-/var/www/magento2}"
COMPOSER_LOCK="${MAGENTO_ROOT}/composer.lock"
PATCH_DIR="${MAGENTO_ROOT}/m2-hotfixes"

if [ ! -f "$COMPOSER_LOCK" ]; then
  echo "UNKNOWN — composer.lock not found at ${COMPOSER_LOCK}. Is this a Magento root?"
  exit 2
fi

# Extract Adobe Commerce / Magento version
VERSION=$(python3 -c "
import json, sys
with open('${COMPOSER_LOCK}') as f:
    data = json.load(f)
for pkg in data.get('packages', []):
    if pkg['name'] in ('magento/product-community-edition', 'magento/product-enterprise-edition', 'magento/magento2-base'):
        print(pkg['version'])
        sys.exit(0)
print('NOTFOUND')
" 2>/dev/null || echo 'NOTFOUND')

if [ "$VERSION" = "NOTFOUND" ]; then
  echo "UNKNOWN — Could not determine Adobe Commerce/Magento version from composer.lock."
  exit 2
fi

echo "Detected version: ${VERSION}"

# Check for APSB26-92 isolated patch files
PATCHED=false
if [ -d "$PATCH_DIR" ]; then
  # Look for APSB26-92 or August 2026 security patch indicators
  if grep -rl 'APSB26-92\|CVE-2026-71362' "$PATCH_DIR" 2>/dev/null | head -1 > /dev/null 2>&1; then
    PATCHED=true
  fi
fi

# Also check applied patches log
APPLIED_PATCHES="${MAGENTO_ROOT}/app/etc/applied.patches.list"
if [ -f "$APPLIED_PATCHES" ]; then
  if grep -q 'APSB26-92\|CVE-2026-71362\|MDVA.*92' "$APPLIED_PATCHES" 2>/dev/null; then
    PATCHED=true
  fi
fi

# Check patch status via composer packages if hotfix not found
if [ "$PATCHED" = false ]; then
  # Check for August 2026 security patch versions
  # Patched versions expected: 2.4.9-p1+, 2.4.8-p5+, 2.4.7-p10+, 2.4.6-p15+, 2.4.5-p17+, 2.4.4-p18+
  DOMINATED=$(python3 -c "
import sys
from packaging.version import Version
v = '${VERSION}'.lstrip('v')
try:
    ver = Version(v)
except Exception:
    print('UNKNOWN')
    sys.exit(0)

# Known patched versions (APSB26-92, post August 2026 patches)
patched_floors = {
    '2.4.9': 'p1',
    '2.4.8': 'p5',
    '2.4.7': 'p10',
    '2.4.6': 'p15',
    '2.4.5': 'p17',
    '2.4.4': 'p18',
}

base = '.'.join(v.split('.')[:3]).split('-')[0]
patch_level = v.split('-')[1] if '-' in v else 'p0'
patch_num = int(patch_level.replace('p','') or '0') if patch_level.startswith('p') else 0

if base in patched_floors:
    needed = int(patched_floors[base].replace('p',''))
    if patch_num >= needed:
        print('PATCHED')
    else:
        print('VULNERABLE')
else:
    print('UNKNOWN')
" 2>/dev/null || echo 'UNKNOWN')

  if [ "$DOMINATED" = "PATCHED" ]; then
    PATCHED=true
  elif [ "$DOMINATED" = "VULNERABLE" ]; then
    echo "VULNERABLE — Adobe Commerce ${VERSION} is affected by CVE-2026-71362. Apply APSB26-92 isolated patch immediately."
    exit 1
  else
    echo "UNKNOWN — Could not determine patch status for version ${VERSION}. Manually verify APSB26-92 patch application."
    exit 2
  fi
fi

if [ "$PATCHED" = true ]; then
  echo "PATCHED — APSB26-92 patch detected for Adobe Commerce ${VERSION}."
  exit 0
fi

echo "UNKNOWN — Could not definitively determine patch status. Check APSB26-92 application manually."
exit 2

Sources

1. Adobe Security Bulletin APSB26-92
2. Adobe Experience League – APSB26-92 KB Article
3. Zero Day Initiative – August 2026 Security Update Review
4. runZero – Adobe Commerce & Magento Vulnerability Asset Discovery
5. CWE-863: Incorrect Authorization
6. CIS Advisory – Multiple Vulnerabilities in Adobe Products
7. Adobe Commerce Security Bulletins Index