Adobe Commerce CVE-2026-71362: Protect Account Recovery Secrets

Adobe has patched CVE-2026-71362, a critical authorization flaw in Adobe Commerce and Magento Open Source that can allow an unauthenticated attacker to take over a customer account. Adobe's August 11 bulletin assigns the vulnerability a CVSS score of 9.1 and says no existing account, administrator privileges or user interaction are required. Security company Sansec says it has already blocked exploitation attempts, while Adobe said it was not aware of in-the-wild exploits when the bulletin was published.

These statements are not interchangeable. The vulnerability and its fix are confirmed by Adobe. The observed exploitation is reported by Sansec and independently covered by BleepingComputer; Adobe has not yet updated its bulletin to confirm exploitation. It is therefore inaccurate to call the issue an Adobe-confirmed zero-day.

What Adobe confirms in APSB26-92

Adobe classifies CVE-2026-71362 as an Incorrect Authorization weakness, CWE-863, with network reachability, low attack complexity, no privileges and no user interaction in its CVSS vector. The listed impact is privilege escalation with high confidentiality and integrity impact. The issue is one of seven vulnerabilities addressed in APSB26-92.

Affected releases include the July 2026 update and earlier versions across the supported Adobe Commerce 2.4.4 through 2.4.9 lines, the corresponding Commerce B2B lines, and Magento Open Source 2.4.6 through 2.4.9. Adobe directs customers to the matching August 2026 update for their supported release line. Administrators should use the bulletin's exact version table rather than infer exposure from a product name alone.

What researchers report about the account takeover

Sansec says its analysis of Adobe's patch found that Magento handled customer identity incorrectly inside an account session. The company reports that an attacker can switch a session to another customer account and access that customer's private account data. It also says its web-application firewall has blocked attempts to exploit the flaw.

Sansec's telemetry is meaningful evidence of attempted exploitation, but it does not establish how many stores were targeted, how many attempts succeeded or how many customer accounts were accessed. BleepingComputer reports the same activity and attributes the technical finding to Sansec, so those two pages are not two independent detections.

Patch first, then investigate the trust boundary

Applying the correct August update closes the known authorization path; it does not erase evidence or invalidate every session that may already be compromised. Merchants should treat patching and incident review as connected but separate tasks.

Identify the exact release line. Confirm Commerce, Commerce B2B and Magento components before selecting the corresponding Adobe update.
Back up and preserve evidence. Retain application, web, CDN, WAF, identity, order-change and API logs before maintenance removes useful state.
Apply Adobe's official update. Follow the bulletin and release documentation, then verify the deployed code and clear caches as required by the platform.
Invalidate exposed sessions. Review whether customer sessions, reset links or persistent login tokens issued before patching should be revoked.
Hunt for account changes. Look for unexpected profile, email, address, stored-payment, password-reset and order-history access.
Review integrations. Check admin accounts, API tokens, webhooks and extensions for activity that cannot be explained by normal operations.

Do not rotate secrets through a channel you no longer trust

Account takeover can compromise more than the storefront session. If an attacker can read or change a customer's email address or recovery state, a normal password-reset message may go to the wrong destination. Support teams can make the problem worse by sending temporary passwords, recovery links or identity documents into the same potentially compromised inbox or ticket thread.

Verify the person and destination through a separate, pre-established channel before issuing a recovery value. Keep the value short-lived and scoped to recovery, require a new authenticated session, and revoke it immediately after use. For administrative or API credentials, rotate from a known-clean device and review downstream sessions and tokens rather than changing only the visible password.

Communicating with customers after suspected takeover

Use a stable status page and official domain so customers can verify a notice without following an unsolicited link.
State what is confirmed, what is only reported and whether successful access has been established.
Do not ask customers to send passwords, payment details or identity documents by reply email.
Provide a direct path to inspect sessions, addresses, orders and recovery settings.
Warn support agents that a person controlling an account or inbox may not be the legitimate owner.

Where Secretus fits—and where it does not

After identity and destination are verified independently, Secretus can reduce persistent plaintext copies when an authorized responder must hand off a temporary password, scoped API token or recovery code. A one-time link with a short expiry can keep that value out of the case history and email body; Team Split can support a planned multi-person release for a high-impact administrative recovery secret.

Secretus does not patch Adobe Commerce, identify the rightful account owner, detect a stolen session or make a compromised browser safe. It should not carry customer profiles, order exports or identity documents. Use it only for the narrow secret handoff after the recovery process has established who is authorized to receive the value.

What remains unknown

Adobe has not publicly confirmed exploitation in the wild. Sansec has not published a count of targeted or successfully compromised stores, and no verified victim total is available. The public reporting does not establish whether observed attempts accessed accounts, changed recovery data or reached administrative functions. Merchants need their own logs and incident evidence to answer those questions for their environment.