← Back to Feed CACHED · 2026-10-09 07:43:37 · CACHE_KEY CVE-2026-71362
CVE-2026-71362 · CWE-863 · Disclosed 2026-08-11

Adobe Commerce / Magento Open Source Incorrect Authorization Customer Account Takeover

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

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.

"Unauthenticated account takeover on internet-facing stores with active exploitation. Patch now."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Identify a Magento/Adobe Commerce storefront

The attacker fingerprints the target using standard ecommerce reconnaissance. Magento storefronts leak platform identity through default URL patterns (/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.
Conditions required:
  • Internet connectivity to the target storefront
Where this breaks in practice:
  • None — these stores are public-facing by definition
Detection/coverage: Wappalyzer/BuiltWith fingerprinting is passive. Shodan and FOFA queries leave no trace on the target. No reliable detection at this stage.
STEP 02

Exploit session identity binding flaw

The attacker sends crafted HTTP requests to the storefront's customer session endpoints, exploiting the incorrect authorization in how Magento binds customer identity to an active session. The flaw lets the attacker *switch* the session to a different customer account. No valid credentials, existing account, or user interaction is required. The attack complexity is low — the 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.
Conditions required:
  • 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)
Where this breaks in practice:
  • Sansec Shield WAF blocks the exploitation pattern if deployed
  • A generic WAF with custom rules targeting session-manipulation endpoints *may* partially mitigate
Detection/coverage: Nuclei template 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.
STEP 03

Assume victim customer identity

Once the session switch succeeds, the attacker's browser session is now authenticated as the victim customer. They have full read/write access to the victim's account dashboard — personal information, saved addresses, order history, stored payment methods (tokens, last-four digits), wishlists, and any B2B-specific data (quotes, purchase orders, company account structures) if Commerce B2B is enabled.
Conditions required:
  • Successful session switch from Step 2
Where this breaks in practice:
  • None — this is the direct consequence of exploitation
Detection/coverage: Application-layer logging of session-to-customer-ID binding changes. Look for a single session ID being associated with multiple customer IDs in rapid succession.
STEP 04

Mass data exfiltration or account manipulation

The attacker can iterate across customer accounts, harvesting PII, order data, and payment tokens at scale. With I:H (Integrity: High) in the CVSS vector, they can also *modify* account details — change shipping addresses to redirect pending orders, update email addresses to lock out legitimate customers, or leverage stored payment methods for fraudulent transactions. On B2B instances, the attacker may escalate within company account hierarchies to access procurement workflows and bulk pricing.
Conditions required:
  • Repeatable exploitation (the flaw is not one-shot — the attacker can target multiple accounts)
Where this breaks in practice:
  • Rate limiting on customer endpoints may slow enumeration but not prevent it
  • Payment tokenization with gateway-side verification limits direct financial fraud
Detection/coverage: Anomalous login/session patterns: many accounts accessed from a single IP, rapid account-detail changes, unusual geographic shifts in session origin. SIEM correlation on access logs.
03 · Compensating Control

1
CRITICAL 9.1→HIGH 7.5
SEVERITY REDUCED
Deploy WAF rules blocking session-manipulation patterns on customer endpoints — Sansec Shield already blocks CVE-2026-71362 exploitation patterns. If you run a different WAF (Cloudflare, Akamai, AWS WAF, Fastly), deploy custom rules targeting abnormal session-identity switching on /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.
2
CRITICAL 9.1→IGNORE 0.0
SEVERITY REDUCED
Apply APSB26-92 isolated security patch immediately — This is the definitive fix. Ensure each store is on its latest -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.
3
CRITICAL 9.1→CRITICAL 9.1
Audit customer accounts and sessions post-patch — After patching, review application logs for signs of prior exploitation: look for single session IDs associated with multiple customer IDs, unusual account-detail changes (email, shipping address), and access patterns from unexpected geolocations. Invalidate all active customer sessions by flushing the session store. Notify affected customers if evidence of account takeover is found. This is a post-incident hygiene step, not a mitigating control.
4
CRITICAL 9.1→HIGH 8.0
SEVERITY REDUCED
Enable rate limiting and anomaly detection on customer session endpoints — Configure your CDN/WAF/reverse proxy to rate-limit requests to customer account and session endpoints. This slows mass exploitation (iterating across accounts) but does not prevent targeted single-account takeover. Pair with SIEM alerting on session anomalies. Useful as defense-in-depth but insufficient alone.
What doesn't work
  • 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.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild StatusActively 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.
EPSS0.87507 (87th percentile) — places this CVE in the top ~13% for exploitation probability within the next 30 days. Extremely high signal.
Proof-of-Concept AvailabilityMultiple 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 VectorCVSS: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 VersionsAdobe 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 VersionsAPSB26-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 & CreditsDisclosed 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 CampaignsNo 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.

  1. Adobe Security Bulletin APSB26-92
  2. Sansec — Adobe Commerce Account Takeover APSB26-92
  3. BleepingComputer — Hackers exploit critical Adobe Commerce flaw
  4. CISA KEV Addition Alert (September 24, 2026)
  5. CyCognito — Emerging Threat CVE-2026-71362
  6. SecurityAffairs — Adobe Commerce CVE-2026-71362 Under Attack
  7. dinosn/cve-2026-71362-magento-lab (PoC Docker Lab)
  8. Nuclei Template — CVE-2026-71362.yaml
05 · The Call

Final Verdict
= UNCHANGED to CRITICAL (9.1/10)

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-lab Docker 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.

06 · Verification

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/.

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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