Like leaving every customer's house key on a table in the lobby of a hotel anyone can walk into
CVE-2026-71362 is an incorrect-authorization flaw (CWE-863) in the way Adobe Commerce and Magento Open Source bind a customer identity to an account session. An unauthenticated, remote attacker can switch an active session to *any other customer account* on the store — no credentials, no admin access, no user interaction required. The attacker then holds the victim's authenticated context, including personal data, order history, saved addresses, and potentially stored payment tokens. Affected versions are Adobe Commerce 2.4.4 – 2.4.9 (through -2026-jul builds), Adobe Commerce B2B 1.3.3 – 1.5.3, and Magento Open Source 2.4.6 – 2.4.9 (through -2026-jul builds). Fixed in APSB26-92 (-2026-aug isolated patches).
Adobe's CRITICAL/9.1 rating is accurate and, if anything, conservative in the current threat landscape. The CVSS vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N maps perfectly to the attack: network-accessible, trivially exploitable, no privileges needed, high confidentiality and integrity impact on PCI-scoped customer data. Every single Adobe Commerce and Magento storefront is internet-facing by design, eliminating the most common friction point (network exposure) that allows severity downgrades in other CVEs. Sansec confirmed exploitation attempts *before* Adobe even acknowledged in-the-wild activity, CISA added it to KEV on September 24, and the EPSS score sits at the 87th percentile. This is a textbook no-downgrade scenario.
4 steps from start to impact.
Identify a Magento/Adobe Commerce storefront
/customer/account/login, /checkout/cart), X-Magento-* response headers, and static asset paths (/static/version*/frontend/). Tools like Wappalyzer, BuiltWith, or simple Shodan/FOFA dorks (http.component:magento) surface targets at scale. There are roughly 100,000–250,000 live Magento/Adobe Commerce stores on the public internet.- Internet connectivity to the target storefront
- None — these stores are public-facing by definition
Exploit session identity binding flaw
dinosn/cve-2026-71362-magento-lab Docker lab on GitHub provides a full reproduction environment, and a Nuclei template (CVE-2026-71362.yaml) automates detection. The KSEC forum also hosts a working exploit write-up.- Target runs an unpatched version (Adobe Commerce 2.4.4–2.4.9 through
-2026-jul, Magento OS 2.4.6–2.4.9 through-2026-jul)
- Sansec Shield WAF blocks the exploitation pattern if deployed
- A generic WAF with custom rules targeting session-manipulation endpoints *may* partially mitigate
CVE-2026-71362.yaml for external scanning. Sansec eComscan and Shield detect exploitation attempts. No CVE-specific Qualys QID or Tenable plugin confirmed at time of writing — check your scanner vendor's latest feed.Assume victim customer identity
- Successful session switch from Step 2
- None — this is the direct consequence of exploitation
Mass data exfiltration or account manipulation
- Repeatable exploitation (the flaw is not one-shot — the attacker can target multiple accounts)
- Rate limiting on customer endpoints may slow enumeration but not prevent it
- Payment tokenization with gateway-side verification limits direct financial fraud
/customer/account/* and /customer/section/load endpoints. This buys time while you prepare the patch. Deploy within the noisgate mitigation SLA of ≤3 days (CRITICAL) — but given KEV status and active exploitation, treat this as hours, not days.-p point release, then apply the corresponding -2026-aug isolated patch ZIP per Adobe Experience League KA-40380. Verify with php vendor/bin/patch-status. Given KEV listing and active exploitation, this should be treated as an emergency patch — deploy within hours to days, well within the noisgate remediation SLA of ≤90 days for CRITICAL. The CISA BOD 26-04 deadline of September 27 has already passed.- IP-based blocking — no actionable IOCs (IPs, hashes) have been published. The single Previdian honeypot IP was not disclosed. Attackers will rotate IPs trivially.
- Enabling MFA/2FA for customer accounts — Magento's native customer authentication does not support MFA out of the box, and even if a third-party module adds it, this vulnerability *bypasses authentication entirely* by switching an already-authenticated session. MFA would not fire.
- Disabling customer account registration — the attacker does not need to create an account. The flaw exploits session binding, not account creation. Disabling registration has no effect.
- Network segmentation / VPN restriction — the storefront must be publicly accessible to serve customers. You cannot restrict it to an internal network without taking the store offline.
The supporting signals.
| In-the-Wild Status | Actively exploited. Sansec reported blocking exploitation attempts shortly after disclosure (~August 2026). Previdian honeypot recorded an attempt from an Australian IP on September 10, 2026. CISA added to KEV catalog on September 24, 2026 with a BOD 26-04 remediation deadline of September 27, 2026. |
|---|---|
| EPSS | 0.87507 (87th percentile) — places this CVE in the top ~13% for exploitation probability within the next 30 days. Extremely high signal. |
| Proof-of-Concept Availability | Multiple public PoCs. dinosn/cve-2026-71362-magento-lab on GitHub provides a one-command Docker lab with end-to-end reproduction and official-patch verification. ProjectDiscovery Nuclei template (CVE-2026-71362.yaml) automates detection. KSEC Community Forum hosts an exploit write-up. SecureWithUmer/CVE-2026-PoCs includes this CVE. |
| CVSS Vector | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N — network-accessible, low complexity, no privileges, no interaction. The missing A:H reflects that this is data theft/manipulation, not denial-of-service. Every metric except Availability is at its worst-case value. |
| Affected Versions | Adobe Commerce 2.4.4 – 2.4.9 (through -2026-jul patch level) · Adobe Commerce B2B 1.3.3 – 1.5.3 · Magento Open Source 2.4.6 – 2.4.9 (through -2026-jul patch level) |
| Fixed Versions | APSB26-92 -2026-aug isolated security patches for all supported release lines. Stores must first be on the latest -p point release before applying the isolated patch. Verify with php vendor/bin/patch-status. See Adobe Experience League KA-40380. |
| Exposure Surface | ~100,000–250,000 live Magento/Adobe Commerce storefronts worldwide (StoreLeads Q2 2026, BuiltWith). All are internet-facing by design. No Shodan/GreyNoise-specific scanning tags confirmed for this CVE at time of writing, but the target surface is trivially enumerable via http.component:magento dorks. |
| Disclosure & Credits | Disclosed August 11, 2026 via Adobe bulletin APSB26-92. Sansec (eCommerce security firm) performed independent patch analysis, confirmed the session-identity root cause, and was first to report in-the-wild exploitation. Adobe initially stated no known exploits at advisory time. |
| Related Campaigns | No named APT or e-crime group attributed yet. Historical pattern: Magento vulnerabilities are rapidly adopted by Magecart skimming groups and automated commodity attackers. Previous critical Magento bugs (e.g., CVE-2022-24086, CVE-2024-34102 "CosmicSting") saw mass exploitation within days of disclosure. |
Sources.
- Adobe Security Bulletin APSB26-92
- Sansec — Adobe Commerce Account Takeover APSB26-92
- BleepingComputer — Hackers exploit critical Adobe Commerce flaw
- CISA KEV Addition Alert (September 24, 2026)
- CyCognito — Emerging Threat CVE-2026-71362
- SecurityAffairs — Adobe Commerce CVE-2026-71362 Under Attack
- dinosn/cve-2026-71362-magento-lab (PoC Docker Lab)
- Nuclei Template — CVE-2026-71362.yaml
Why this verdict
- Zero authentication friction: The attack requires no credentials, no existing account, and no user interaction. The CVSS PR:N/UI:N/AC:L triple means there is literally no barrier between an attacker and exploitation beyond network reachability — and every Magento store is reachable by design.
- 100% internet exposure by architecture: Unlike server-side CVEs where exposure depends on misconfiguration or internal-only deployment, Adobe Commerce storefronts *must* be internet-facing to serve their purpose. There is no 'restrict to internal network' mitigating factor. The ~100K–250K store footprint is entirely exposed.
- Active exploitation + public PoCs eliminate theoretical risk: Sansec confirmed blocked attacks within days of disclosure, a honeypot recorded exploitation on September 10, CISA added to KEV on September 24, and EPSS is at the 87th percentile. The
dinosn/cve-2026-71362-magento-labDocker lab and Nuclei template lower the bar to script-kiddie level. - Role multiplier: Adobe Commerce/Magento is *canonically* a high-value-role component. Virtually 100% of installs ARE the production data tier for ecommerce businesses, holding PCI-scoped customer PII, payment tokens, order histories, and (on B2B instances) procurement data. The blast radius of successful exploitation is mass data egress across all customer accounts on the store — this is not workstation-grade impact. Under the deployment-role rule, the affected component's blast radius is data-tier / mass-data-egress scale, and ≥90% of installs occupy this high-value role by definition. Verdict floor: CRITICAL.
- Magecart-class threat multiplication: Historical precedent (CVE-2022-24086, CVE-2024-34102) shows Magento critical vulnerabilities are adopted by card-skimming groups within days. Account takeover provides a launchpad for injecting payment skimmers, modifying checkout flows, and pivoting to admin-panel compromise on stores where customer and admin sessions share infrastructure.
Why not higher?
The CVSS vector already maxes out every metric except Availability (A:N). A 10.0 would require Scope change (S:C) or full CIA impact. This is account takeover and data exfiltration, not arbitrary code execution on the server itself — the attacker does not gain OS-level access or the ability to pivot to backend infrastructure directly from this flaw alone. The 9.1 accurately captures the impact ceiling.
Why not lower?
Downgrading would require identifying meaningful friction in the attack path, and there is none. The target is internet-facing by design, the attack is unauthenticated with low complexity, exploitation is confirmed in the wild with public PoCs, and the data at risk is PCI-regulated customer PII. The deployment-role analysis confirms that ≥90% of installs are production ecommerce systems where the blast radius is mass customer data breach — setting a CRITICAL floor that friction cannot pull below. Any downgrade here would be indefensible.
Crowdsourced verification payload.
Run this script on each Adobe Commerce / Magento host (or from a CI runner with SSH access) as a user that can read the Magento installation directory. Usage: bash check_cve_2026_71362.sh /var/www/magento (pass the Magento root path as the first argument). Requires php on PATH and read access to vendor/.
#!/usr/bin/env bash
# check_cve_2026_71362.sh — Detect CVE-2026-71362 patch status
# Usage: bash check_cve_2026_71362.sh /path/to/magento/root
# Exit codes: 1=VULNERABLE, 0=PATCHED, 2=UNKNOWN
set -euo pipefail
MAGE_ROOT="${1:-}"
if [[ -z "$MAGE_ROOT" ]]; then
echo "[!] Usage: $0 /path/to/magento/root"
exit 2
fi
if [[ ! -d "$MAGE_ROOT/vendor" ]]; then
echo "UNKNOWN — $MAGE_ROOT does not appear to be a Magento installation (no vendor/ directory)."
exit 2
fi
# Method 1: Check via patch-status tool if available
if [[ -x "$MAGE_ROOT/vendor/bin/patch-status" ]] || [[ -f "$MAGE_ROOT/vendor/bin/patch-status" ]]; then
echo "[*] Checking patch status via vendor/bin/patch-status..."
PATCH_OUTPUT=$(cd "$MAGE_ROOT" && php vendor/bin/patch-status 2>&1 || true)
if echo "$PATCH_OUTPUT" | grep -qi '2026-aug\|APSB26-92'; then
echo "PATCHED — patch-status reports August 2026 security patch applied."
exit 0
fi
fi
# Method 2: Check composer.json for version
if [[ -f "$MAGE_ROOT/composer.lock" ]]; then
echo "[*] Checking installed Commerce/Magento version from composer.lock..."
# Extract magento/product-community-edition or magento/product-enterprise-edition version
VERSION=$(php -r '
$lock = json_decode(file_get_contents("'"$MAGE_ROOT"'/composer.lock"), true);
foreach ($lock["packages"] ?? [] as $pkg) {
if (in_array($pkg["name"], ["magento/product-community-edition","magento/product-enterprise-edition","magento/magento2-base"])) {
echo $pkg["version"] ?? "unknown";
exit;
}
}
echo "unknown";
' 2>/dev/null || echo "unknown")
echo "[*] Detected version: $VERSION"
if [[ "$VERSION" == "unknown" ]]; then
echo "UNKNOWN — could not determine Magento version from composer.lock."
exit 2
fi
# Check if version string contains -2026-aug or later patch indicator
if echo "$VERSION" | grep -qiE '2026[-.]aug|2026[-.]sep|2026[-.]oct|2026[-.]nov|2026[-.]dec'; then
echo "PATCHED — version $VERSION includes August 2026 or later security patches."
exit 0
fi
# Check if version is 2.4.9-p* or similar with a patch level at or after aug-2026
if echo "$VERSION" | grep -qiE '^2\.4\.(4|5|6|7|8|9)'; then
# Version is in the affected range — check for -2026-jul or earlier
if echo "$VERSION" | grep -qiE '2026[-.]jul|2026[-.]jun|2026[-.]may|2026[-.]apr|2026[-.]mar|2026[-.]feb|2026[-.]jan|2025'; then
echo "VULNERABLE — version $VERSION is in the affected range (pre-August 2026 patch)."
echo "CVE-2026-71362: Adobe Commerce Incorrect Authorization — customer session identity switch account takeover."
echo "Apply APSB26-92 isolated security patch immediately."
exit 1
fi
# If no date indicator, flag as potentially vulnerable
echo "VULNERABLE — version $VERSION is in the affected range (2.4.4–2.4.9). No August 2026 patch indicator found."
echo "Verify manually: cd $MAGE_ROOT && php vendor/bin/patch-status"
exit 1
fi
fi
echo "UNKNOWN — could not conclusively determine patch status. Verify manually."
exit 2