CVE-2026-71362

What is Adobe Commerce and Magento Open Source?

Adobe Commerce is the commercial edition of the Magento e-commerce platform; Magento Open Source is the free edition that shares most of the same codebase. Together they run a large share of mid-market and enterprise online stores, handling product catalogues, checkout, and the customer account area where addresses, order history and stored payment tokens live.

Magento stores are a perennial target for exactly that reason. They are internet-facing by definition, they hold personal and payment data, and the platform's history of skimmer campaigns (the Magecart family) means there is a mature criminal ecosystem that already knows how to monetise access. A flaw that lets an attacker walk into arbitrary customer accounts on an unpatched store is immediately useful to that ecosystem, with no additional tooling required.

Overview

CVE-2026-71362 is an incorrect authorization flaw that lets an attacker take over a customer account on an affected store. The platform fails to bind a customer identity correctly to an account session, so an attacker can cause their own session to be re-pointed at a different customer's account. From there they see the victim's account area: saved addresses, order history, stored contact details, and whatever else the storefront exposes to a logged-in customer. Adobe rates it CVSS 3.1 9.1 (network, low complexity, no privileges, no user interaction, high confidentiality and integrity impact) and classifies it as CWE-863.

Adobe shipped the fix in bulletin APSB26-92 on 2026-08-11, a regularly scheduled update that closed seven vulnerabilities in Adobe Commerce and Magento Open Source. Adobe stated it had no evidence of exploitation at publication time. That window closed almost immediately: Sansec, which runs a Magento-focused WAF and forensics practice, reported blocking exploitation attempts within days of the bulletin, the pattern that has followed most recent Magento authentication bugs. CISA added the CVE to the KEV catalog on 2026-09-24.

Sources disagree on one prerequisite. Adobe's rating and CyCognito's analysis both describe the attack as requiring no authentication at all, only network access to the public storefront. At least one technical write-up argues the practical path needs the attacker to register a customer account first, which is trivial on any store that allows self-registration but is not strictly "unauthenticated". The distinction does not change the remediation or the urgency; treat any store with open customer registration as exploitable.

Affected Versions

Adobe did not cut new Composer packages for this bulletin. The fix is distributed as isolated patch files that merchants apply on top of the current point release for their line.

Technical Details

CWE-863 means the software performs an authorization check but gets it wrong, rather than omitting it. Here the defect is in how the customer account controller rehydrates form state. Published analysis points at Magento\Customer\Controller\Account\Edit::execute(), which takes the customer_form_data array left in the session by a failed editPost submission and feeds it into DataObjectHelper::populateWithArray(). That helper copies every matching key onto the customer data object, including id, which was never meant to be settable from user input. The object is then written back with Session::setCustomerData(), and once the session's customer_id has been overwritten the store's own isLoggedIn() check happily reports the attacker as the victim.

Practically this is a single-request attack against a public storefront endpoint, with no admin access, no user interaction and no chaining required. It is a mass-assignment bug in the classic sense: attacker-controlled input reaching a field that determines identity.

Discovery

Adobe credited the issue through its normal coordinated-disclosure process in APSB26-92; the reporting researcher is not named in the public material reviewed here. The in-the-wild exploitation was first surfaced by the Sansec Forensics Team, which published its analysis alongside the bulletin and reported blocking live attempts shortly afterwards. CyCognito later published an independent write-up of the session-identity mechanics.

Exploitation Context

Exploitation is confirmed but not well quantified in public reporting. Sansec observed attempts against live stores beginning within days of the 2026-08-11 bulletin, which is consistent with attackers diffing the released patch. No threat-actor attribution has been published, no ransomware association is recorded in the KEV entry, and no chaining with other CVEs has been described. Reliable counts of unpatched internet-facing stores have not been published, though the affected range covers every supported Magento 2.4 line, so the exposed population is large by default.

The likely post-exploitation path is data theft and fraud rather than server compromise: order history, personal details and any stored tokens in the customer account area. Account takeover at scale also supports refund and loyalty-point fraud, and gives an attacker a foothold to phish the real customer convincingly.

Remediation

1. Apply the APSB26-92 isolated patch for your release line, after first updating to the current -p point release for that line. Both steps are required; the patch is written against the latest point release.
2. Confirm the resulting patch level reports as the 2026-aug build for your line. Do not assume a Composer update alone fixed this, since Adobe published no new packages for this bulletin.
3. Invalidate all active customer sessions after patching. Any session established while the store was vulnerable may already be pointed at someone else's account.
4. Review storefront logs for unexpected account or session switching, for requests to the customer account edit endpoint that carry an id field, and for account-area access that does not follow a matching login event. Stores exposed for an extended period should also be scanned for injected skimmer code and backdoors.
5. Inventory every Commerce or Magento host you run, including staging, development and campaign sites; these are routinely missed and are patched on the same schedule as production by attackers, not by merchants.
6. Federal civilian agencies must remediate by 2026-09-27 under the applicable CISA directive. Given that exploitation began in August, everyone else should treat that as overdue rather than upcoming.