CVE-2026-71362: unauthenticated Magento customer account takeover
Published
Adobe published bulletin APSB26-92 on 11 August 2026. It fixes CVE-2026-71362, an incorrect-authorization flaw rated 9.1 out of 10: an unauthenticated attacker can switch a customer session to another account and reach the victim’s personal data.
Fixed by Adobe (bulletin APSB26-92, 11 August 2026)
What does this flaw actually do?
The defect is incorrect authorization: Magento accepts binding a live session to a customer account that is not the visitor’s.
No authentication, no admin privilege, no victim interaction. The attacker gets account access: identity, addresses, order history, contact details.
Why was it exploited before the advisory was even updated?
Sansec blocked the first exploitation attempts on 12 August 2026, the day after publication, while Adobe’s advisory still stated no known exploitation in the wild.
This is the usual pattern: shipping a fix is also the starting gun for attackers, who reverse-engineer the patch within hours. The window between "the fix exists" and "the fix is deployed on my store" has become the real risk window.
Why does deployment drag on?
Adobe ships these monthly fixes as isolated patch files, not as a new release or an updated Composer package. The store must already run the latest -p release of its branch for the patch to apply.
For many merchants that means an upgrade first, regression testing, a maintenance window. Count in days, often in weeks.
What does this mean for my compliance?
Unauthorized access to your customers’ personal data is a reportable incident under GDPR and under Quebec’s Law 25.
Knowing who tried what, and when, is therefore not a comfort feature: it is evidence. Provided you can retrieve those logs and verify their integrity.
Who is affected?
- Adobe Commerce 2.4.4 through 2.4.9
- Magento Open Source 2.4.6 through 2.4.9
- Adobe Commerce B2B 1.3.3 through 1.5.3
- CVSS v3.1: 9.1 (critical). Exploitation observed from 12 August 2026
How does AtriShield stop it?
Virtual patch (Business and Enterprise): the flaw is neutralised at the entrance of your server, without changing your application and without waiting for a maintenance window. Security metadata is reported to your console.
- ✓Virtual patch deployed through the signed configuration, without waiting for your maintenance window.
- ✓Session-switching attempts toward someone else’s account are cut at the edge, before Magento.
- ✓Attempts are recorded in a sealed ledger. Retention period: per contract.
- ✓Adobe’s fix still has to be applied: the virtual patch covers the gap, it does not replace it.
Sources
- Sansec - Adobe patches critical Magento account takeover (APSB26-92)
- Adobe - Security bulletins for Magento
Analysis published by Atrilya Solutions, based on public security reporting. The links above point to the original sources.