---
schema: 1
kind: vulnerability
title: "CVE-2026-71362 — Adobe Commerce and Magento Open Source: an unauthenticated attacker switches a customer session to another customer's account (CVSS 9.1), and a WAF vendor reports it is already blocking attempts"
headline: "Adobe Commerce carries an unauthenticated customer account takeover, and Sansec says its WAF is already blocking attempts"
summary: >
  Adobe published APSB26-92 on 2026-08-11 for seven flaws in Adobe Commerce, Adobe Commerce B2B and
  Magento Open Source, headed by CVE-2026-71362, an incorrect-authorization flaw rated CVSS 9.1 that
  Adobe's own table records as needing no authentication, no administrator privileges and no user
  interaction. Sansec reviewed the patch and states the flaw lets an attacker switch a customer session
  to another customer's account, and that its Shield WAF is already blocking exploitation attempts;
  Adobe states in the same bulletin that it is not aware of any exploits in the wild. The fix ships as
  isolated patch files rather than a release, so a merchant must be on the latest -p release of their
  line before it can be applied.
discovered_at: "2026-08-16T05:15:00Z"
event_date: "2026-08-11"
run_id: 2026-08-16T0411Z-intel
priority: high
immediate_action: null
tags: [vulnerabilities, auth-bypass, pre-auth, priv-esc, patch-available, data-breach]
regions: [global, europe]
sectors: [retail, technology, public-sector]
entities: []
techniques: [T1190, T1539]
affected_products: ["Adobe Commerce", "Adobe Commerce B2B", "Magento Open Source"]
cves:
  - id: CVE-2026-71362
    cvss: "9.1"
    epss: null
    type: auth-bypass
    vector: zero-click
    auth: pre-auth
    status: [exploited, patch-available]
    affected: "Adobe Commerce 2.4.9-2026-jul, 2.4.8-2026-jul, 2.4.7-2026-jul, 2.4.6-2026-jul, 2.4.5-2026-jul and 2.4.4-2026-jul, each and earlier; Adobe Commerce B2B 1.5.3-2026-jul, 1.5.2-2026-jul, 1.4.2-2026-jul, 1.3.4-2026-jul and 1.3.3-2026-jul, each and earlier; Magento Open Source 2.4.9-2026-jul, 2.4.8-2026-jul, 2.4.7-2026-jul and 2.4.6-2026-jul, each and earlier"
    fixed: "Adobe Commerce 2.4.9-2026-aug through 2.4.4-2026-aug; Adobe Commerce B2B 1.5.3-2026-aug through 1.3.3-2026-aug; Magento Open Source 2.4.9-2026-aug through 2.4.6-2026-aug — distributed as isolated patch files, applied on top of the latest -p release for the line"
sources:
  - url: "https://helpx.adobe.com/security/products/magento/apsb26-92.html"
    publisher: "Adobe PSIRT"
    date: "2026-08-11"
    role: primary
  - url: "https://sansec.io/research/adobe-commerce-account-takeover-apsb26-92"
    publisher: "Sansec Forensics Team"
    date: "2026-08-11"
    role: corroborating
  - url: "https://www.bleepingcomputer.com/news/security/hackers-exploit-critical-adobe-commerce-flaw-to-hijack-customer-accounts/"
    publisher: "BleepingComputer"
    date: "2026-08-12"
    role: corroborating
closed_sources: []
evidence:
  - quote: "Adobe is not aware of any exploits in the wild for any of the issues addressed in these updates."
    publisher: "Adobe PSIRT"
  - quote: "Sansec reviewed the patch and confirmed that the vulnerability lets attackers switch a customer session to another customer account. This gives them access to the victim's account and private customer data."
    publisher: "Sansec Forensics Team"
  - quote: "Sansec Shield already blocks exploitation attempts."
    publisher: "Sansec Forensics Team"
verification: multi-source
sourcing_note: >
  The vendor and the discloser describe the exploitation picture differently and both readings are
  carried here rather than reconciled. Adobe's bulletin states it is not aware of exploits in the wild
  for any flaw in this update; Sansec, which reviewed the patch, states its own WAF is already blocking
  exploitation attempts against this CVE, and BleepingComputer reports attempts as detected. These are
  not strictly contradictory — Adobe speaks to its own visibility at publication, Sansec to what its
  sensors saw. The CVE record carries `exploited` on the rule this store applies consistently: the flag
  marks observed exploitation activity in the wild reported by a named party, which attempts against a
  WAF are, and it is not a claim of confirmed compromise — no party reports a compromised store, and
  the body says so. This window's SAP Commerce Cloud entry carries it on the same basis. Scores, affected and fixed version lines and the
  authentication preconditions are transcribed from Adobe's own vulnerability table, not from the
  reporting. This flaw was disclosed on 2026-08-11 and is outside this run's window; it is published
  now because earlier fires whose windows covered it did not, and the gap was recovered by this run's
  completeness check.
confidence: high
update_of: null
references: []
deep_dive: false
deep_dive_category: null
org_triage: null
classification:
  reliability: A
  credibility: 2
watchlist_hit: false
actions:
  - "Apply the APSB26-92 isolated patch to every Adobe Commerce, Commerce B2B and Magento Open Source storefront — this needs the line's latest -p release in place first, so budget that step rather than assuming a one-file drop-in — and because the flaw hands over a customer session rather than a shell, invalidate existing customer sessions after patching instead of only upgrading."
migrated_from: null
---

Adobe's 2026-08-11 bulletin APSB26-92 fixes seven vulnerabilities in Adobe Commerce, Adobe Commerce B2B and Magento Open Source, five of them rated Critical ([Adobe PSIRT, 2026-08-11](https://helpx.adobe.com/security/products/magento/apsb26-92.html)). The one that matters operationally is CVE-2026-71362, an incorrect-authorization flaw (CWE-863) which Adobe's own vulnerability table scores at CVSS 9.1 and records as requiring no authentication, no administrator privileges and no user interaction ([Adobe PSIRT, 2026-08-11](https://helpx.adobe.com/security/products/magento/apsb26-92.html)). Sansec, which reviewed the patch, describes the effect concretely: the flaw lets an attacker switch a customer session to another customer account, giving access to that account and its private customer data, and Adobe's fix changes the way Magento handles customer identity in the account session ([Sansec, 2026-08-11](https://sansec.io/research/adobe-commerce-account-takeover-apsb26-92)).

The exploitation picture depends on who is speaking, and both readings belong in a triage decision. Adobe states in the bulletin that it is not aware of any exploits in the wild for any issue in the update ([Adobe PSIRT, 2026-08-11](https://helpx.adobe.com/security/products/magento/apsb26-92.html)). Sansec states that its Shield web application firewall already blocks exploitation attempts against this flaw ([Sansec, 2026-08-11](https://sansec.io/research/adobe-commerce-account-takeover-apsb26-92)), and BleepingComputer reports that attempts to exploit CVE-2026-71362 have been detected ([BleepingComputer, 2026-08-12](https://www.bleepingcomputer.com/news/security/hackers-exploit-critical-adobe-commerce-flaw-to-hijack-customer-accounts/)). Nobody reports a confirmed compromised store, so this sits between "patched, quiet" and "actively exploited" — which for a pre-authentication account takeover on an internet-facing storefront is close enough to the latter to act on.

The deployment detail is what will actually cost teams time. APSB26-92 ships as isolated patch files rather than a new security release or new Composer packages, and merchants must be running the latest -p release for their supported release line before the corresponding isolated patch can be applied ([Sansec, 2026-08-11](https://sansec.io/research/adobe-commerce-account-takeover-apsb26-92)). A store several -p releases behind therefore has a two-step upgrade in front of it, not a patch. The affected ranges differ by product and the difference matters for inventory: Adobe Commerce is listed from 2.4.9-2026-jul down to 2.4.4-2026-jul, Adobe Commerce B2B from 1.5.3-2026-jul down to 1.3.3-2026-jul, and Magento Open Source only from 2.4.9-2026-jul down to 2.4.6-2026-jul, each "and earlier", with the fixes in the corresponding -2026-aug builds of each line ([Adobe PSIRT, 2026-08-11](https://helpx.adobe.com/security/products/magento/apsb26-92.html)).

For this constituency the exposure is narrower than a general Magento advisory suggests but is real: public-sector bodies that run ticketing, publication or fee-payment storefronts on Commerce or Magento hold exactly the customer records this flaw hands over, and the payment-adjacent data in those accounts is what makes a session takeover worth automating.

Detection, in vendor-neutral terms: because the flaw operates on session identity rather than injecting code, the signal is in application and web-access logs rather than on the host. Look for requests where a session identifier is presented against a customer account other than the one it was issued to, for a single session identifier or source address touching multiple distinct customer account contexts in quick succession, and for account-area page views and order-history reads that arrive without the preceding authentication sequence that normally establishes them. There is no file to find and no process to spot — a successful attack looks like an ordinary logged-in customer, which is why the post-patch session invalidation matters as much as the patch.