What the flaw actually does
CVE-2026-71362 is an incorrect-authorization vulnerability with a CVSS score of 9.1 in Adobe Commerce, Commerce B2B and Magento Open Source. It lets an unauthenticated attacker switch a customer's session to a different customer's account, handing the attacker access to that victim's order history, saved addresses and stored payment details without needing a password, an existing account or any user interaction from the victim.
Adobe patched the flaw as part of its August 2026 Patch Tuesday cycle, alongside six other security issues across the three products, and said at the time of the advisory that it had no evidence the bug was being exploited in the wild. Security firm Sansec, which runs detection telemetry across a large share of the world's Magento and Adobe Commerce storefronts, tells a different story about what happened next.
Why it was hit within hours
Sansec says its Shield web application firewall began blocking real exploitation attempts against CVE-2026-71362 shortly after Adobe's advisory went public -- attackers moving from patch notes to live attacks in a matter of hours rather than days. That gap between disclosure and exploitation has become the norm for this platform rather than the exception: Adobe Commerce and Magento have a long history of critical flaws being weaponized almost as soon as the technical details needed to build an exploit become public, because the underlying codebase runs on a large, slow-to-patch installed base of independent online stores.
The account-takeover mechanic itself is also unusually dangerous for a storefront-layer bug: most e-commerce vulnerabilities require some prior foothold, but this one lets a completely anonymous visitor become any other customer with a single crafted request, which is why Sansec chose to publish a same-day detection signature rather than wait for broader confirmation.
What retailers should check right now
Any store running Adobe Commerce, Commerce B2B or Magento Open Source should confirm the August 2026 security patch is installed, not just scheduled, since Sansec's data shows real exploitation attempts are already happening rather than being theoretical. Given the flaw sits in session handling rather than an isolated module, a web application firewall rule that specifically blocks the known exploitation pattern is worth layering on top of the patch while rollout is verified across every storefront instance, including staging and secondary regional sites that are easy to forget during a patch cycle.
For European and UK retailers specifically, an account-takeover flaw of this kind is also a data-protection reporting question: if customer order history, addresses or payment metadata were accessible to an unauthenticated attacker even briefly, that is the kind of exposure a data protection officer needs to assess against breach-notification thresholds, regardless of whether Sansec's telemetry shows your specific store was hit.
Read next: Germany's NIS2 Grace Period Has Ended | Attackers Hit 361 vCenter Servers Before KEV Listed It
