CISA added CVE-2026-71362 to its Known Exploited Vulnerabilities catalog on September 24, giving federal civilian agencies until September 25 — today — to remediate. The flaw is a CVSS 9.1 incorrect-authorization bug in Adobe Commerce and Magento Open Source that lets an attacker hijack any other customer’s account without knowing their password. Adobe patched it over a month ago; attackers didn’t wait long to start using it.

What happened

Adobe published the fix as part of security bulletin APSB26-92 on August 11, 2026, alongside six other Commerce/Magento vulnerabilities. Sansec, the e-commerce threat-intel firm that spends most of its time tracking Magecart skimmer campaigns, reported that its Shield WAF began blocking exploitation attempts against CVE-2026-71362 almost immediately after the advisory went public — attackers were reverse-engineering the patch diff and weaponizing it within days. Honeypot telemetry from Previdian recorded probes as early as September 10. CISA’s KEV addition on September 24 followed confirmation of sustained in-the-wild attacks.

The bug: your session, someone else’s identity

The root cause is in how Magento’s customer session binds to a customer identity. When a customer submits account-related form data, populateWithArray() copies an attacker-supplied id field out of customer_form_data directly into the Customer data object. Session::setCustomerData() then trusts that object and overwrites the session’s customer_id with whatever value came in on the request. The only check performed — checkCustomerId() — merely confirms that a customer with that ID exists somewhere in the store; it never verifies the ID belongs to the session’s actual authenticated owner.

The practical effect: an attacker submits a crafted id value in a form POST, and their own live session silently becomes bound to a different, arbitrary customer’s identity. From that point they’re looking at someone else’s order history, saved shipping and billing addresses, stored payment method tokens, and any other PII the account page exposes.

The catch that keeps this from requiring zero authentication end-to-end is that the vulnerable sink needs a logged-in session — but Adobe’s own severity vector marks privileges required as none, because Magento stores overwhelmingly ship with open self-registration. An attacker creates a disposable throwaway account in seconds, logs in as that nobody, then fires the crafted request to become anybody. No victim credentials, no phishing, no click required on the victim’s end at all.

Adobe’s fix in APSB26-92 is a two-layer patch: form data is now clamped to only the attributes the customer is actually allowed to edit via array_intersect_key() against getAllowedAttributes(), and the session customer ID is force-restored with setCustomerId($customerId) immediately after the populate call, so a smuggled id field can no longer survive into the session object.

Impact

Affected: Adobe Commerce and Adobe Commerce B2B release lines 2.4.4 through 2.4.9, and Magento Open Source 2.4.6 through 2.4.9, at the -2026-jul build and earlier in each line. That’s effectively every actively supported Commerce/Magento deployment that hadn’t applied the August patch set.

Given how thin the exploitation bar is — one throwaway account, one crafted POST, zero interaction from the target — this is a realistic mass-harvesting primitive for any storefront left unpatched. Full account takeover on an e-commerce platform means exposed order history, addresses, and stored payment tokens at scale, plus a foothold an attacker can pivot from (password reset flows, saved payment reuse, loyalty/gift-card balances) into direct fraud. Retailers have also seen this class of bug used as a stepping stone into the storefront-wide backdoor and skimmer deployments Sansec tracks under Magecart.

Mitigation

  • Patch now. Apply APSB26-92 (or later cumulative updates) to bring Adobe Commerce/Commerce B2B and Magento Open Source current. This is the only real fix — there’s no viable WAF rule that distinguishes a legitimate form submission from a malicious id override without understanding Magento’s internal object-population logic.
  • If you can’t patch immediately, restrict or disable open self-registration where feasible to raise the bar for the throwaway-account prerequisite, and watch for anomalous session-to-customer-ID transitions in application logs.
  • Assume compromise if you were running an unpatched, internet-facing store between the August 11 disclosure and today. Review customer accounts for unexpected data changes, unauthorized order activity, and unfamiliar saved payment methods; rotate any credentials or tokens that may have been exposed through account access.
  • Verify patch status with bin/magento setup:db:status and Adobe’s official security:patch-status tooling rather than trusting a version number alone — the same lesson from prior Magento incidents this year still applies.

Sources