When the Checkout Gate Fails, the Whole Shop Feels It

A commerce platform lives or dies by who can do what. That is why CVE-2026-71362 matters: it is described as a privilege-escalation weakness in Adobe Commerce, Adobe Commerce B2B, and Magento Open Source, with no authentication required and a Critical CVSS score of 9.1. In practical terms, the problem sits in the trust boundary itself, where the server is supposed to decide which actions belong to which role.

Fast Facts

• Adobe released security updates for Adobe Commerce, Adobe Commerce B2B, and Magento Open Source.
• CVE-2026-71362 is described as an incorrect-authorization flaw that can lead to privilege escalation.
• The issue is reported to require no authentication and no admin privileges.
• Adobe assigned the flaw a CVSS base score of 9.1.
• At publication time, Adobe said it was not aware of in-the-wild exploitation.

Why authorization bugs are so dangerous

Authentication asks, "Who are you?" Authorization asks, "What are you allowed to do?" The second question is the one that failed here. In web applications, broken authorization can show up as a missing server-side check, an overly broad permission path, or a logic error that lets a request reach a protected function anyway. MITRE’s CWE-863 class covers exactly that kind of mistake: the product performs an authorization check, but not correctly.

That is especially sensitive in Adobe Commerce and its B2B workflows, where roles, company accounts, and access-control lists are meant to separate ordinary users from higher-privilege actions. If that boundary slips, the result may be unauthorized access to admin-style functions, company settings, or other protected commerce operations, depending on which path is affected.

The key detail is that this is not a case of password guessing or account theft. The risk comes from the application itself making the wrong decision about access. That makes the flaw attractive to attackers because it can be probed remotely and, if a vulnerable path is exposed, may not depend on any prior foothold.

What defenders should look for

From a defensive perspective, the first move is straightforward: apply Adobe’s update and verify the fixed versions in every deployment branch, including custom installs and shared testing environments. The second move is to review any extensions, plugins, or custom controllers that duplicate authorization logic, because commerce platforms often accumulate bespoke access rules over time.

Teams should also test whether privileged routes are enforced entirely on the server side. Client-side hiding is not a control. Role checks should be deny-by-default, and B2B permissions should be revisited after every customization or upgrade. In a platform built around delegated access, even one weak gate can create an outsized risk.

At the time of writing, public information does not fully establish the complete scope of affected users or whether downstream systems were impacted. The available information supports a risk analysis, not a definitive claim of wider compromise.

Conclusion

The lesson is bigger than one CVE. Commerce platforms are not only transaction engines - they are permission engines. When authorization fails, the business logic that keeps customer data, admin actions, and partner workflows separated can unravel fast. For defenders, that makes access control one of the highest-value places to test, patch, and retest.

WIKICROOK

• Privilege escalation: Gaining permissions beyond what an account or request should be allowed to use.
• Authorization: The server-side decision about whether a user or request may access a resource or action.
• CWE-863: A weakness class for incorrect authorization, where access checks exist but are implemented wrongly.
• CVSS: A standard scoring system used to rate the severity of vulnerabilities.
• ACL: Access control list, a rule set that defines which roles can reach specific resources or functions.