Most Adobe Commerce and Magento security updates land on a predictable quarterly schedule. This one did not. On 11 August, Adobe pushed APSB26-92 outside that cycle, an “isolated” fix Adobe judged too urgent to hold for the next scheduled release, resolving seven vulnerabilities across Commerce and Magento Open Source, five of them rated critical.

A session is not supposed to be transferable

The vulnerability drawing the most attention, CVE-2026-71362, is an incorrect authorization flaw rooted in how the platform binds a customer’s identity to their account session. Under the right conditions, that binding fails, and an attacker can redirect an active session onto a completely different customer’s account. No credentials are needed. No admin privileges are needed. No account of their own is needed. No user interaction is needed. The attacker simply ends up looking at, and acting as, someone else’s customer, with access to whatever order history, saved payment methods and personal details that account holds. Adobe rated it 9.1 out of 10, and for a bug that requires nothing but a working exploit against an unauthenticated storefront, that score is not generous, it is accurate.

Adobe said no known exploitation. A WAF vendor disagreed within days

Adobe’s advisory stated the company was not aware of active exploitation at the time of release. That statement did not hold for long. Sansec, an eCommerce security firm whose Shield web application firewall protects a large share of the Magento install base, reported blocking exploitation attempts against CVE-2026-71362 shortly after the advisory went public, the now-familiar pattern where a patch functions as a roadmap for attackers who reverse-engineer the fix faster than site operators apply it. The affected range covers Adobe Commerce 2.4.4 through 2.4.9 and Magento Open Source 2.4.6 through 2.4.9, specifically builds at or before the July 2026 patch level.

This is a GDPR incident waiting to happen, not just a security bug

Magento and Adobe Commerce power a substantial share of mid-sized European online retail, and a successful exploitation of this flaw is, definitionally, unauthorised access to another person’s personal data: order history, address, payment metadata, whatever the account holds. If an EU-based retailer running an unpatched storefront cannot rule out that this flaw was used against live customer accounts, that is not only a technical incident, it is a potential personal data breach under GDPR, with the usual 72-hour clock to notify the relevant supervisory authority once the organisation becomes aware. Treating this purely as a “patch when convenient” ticket misses that the exposure window itself may already carry a regulatory reporting obligation, whether or not evidence of actual misuse ever surfaces.

What to do now

If your storefront runs Adobe Commerce 2.4.4 through 2.4.9 or Magento Open Source 2.4.6 through 2.4.9, apply APSB26-92 immediately rather than waiting for a maintenance window, and review access and session logs around the disclosure date for anything resembling session hijacking, not just failed logins. If you cannot confirm your patch level right now, that uncertainty is itself the thing to resolve first.

If your organisation runs an Adobe Commerce or Magento storefront and needs help confirming your exposure to CVE-2026-71362, getting the patch applied without breaking a live store, or working out whether this incident meets your GDPR breach notification threshold, contact Excello Digital. We help European retailers keep customer-facing platforms patched and their compliance obligations clear, before a regulator or a customer asks first.