TL;DR: CVE-2026-71362 is a critical incorrect-authorization flaw in Adobe Commerce and Magento Open Source that can let an unauthenticated attacker switch an active session to another customer account, exposing personal data and order history, according to CYCOGNITO’s analysis. The issue shows how session binding failures in commerce systems create direct identity and privacy risk, even when no credentials are stolen.
At a glance
What this is: This is a critical Adobe Commerce and Magento Open Source authorization flaw that can let an attacker switch an active customer session to a different account without authenticating.
Why it matters: It matters because commerce platforms can become identity and privacy liabilities when session binding fails, and IAM teams need to treat authenticated web sessions as account-level trust boundaries.
Context
CVE-2026-71362 is a session binding failure, which means the platform does not reliably tie a live customer session to the correct identity. In commerce systems, that is not just an application flaw, because the authenticated session is the control plane for personal data, order history, and account actions. When binding breaks, authorization fails at the point where identity should be enforced.
The exposure pattern is wider than the patched product lines themselves. Public storefronts, staging environments, campaign sites, and agency-built instances can all inherit the same session logic, and those systems are often managed outside central IAM oversight. That makes this a governance problem as much as a software defect, because the real risk sits in how storefront identity is owned, monitored, and retired.
Key questions
Q: What breaks when session binding is not enforced in commerce platforms?
A: The platform can no longer guarantee that an authenticated session belongs to the customer who created it. That failure turns a login session into a transferable trust token, which can expose order history, personal data, and account actions to an attacker who never had credentials. In commerce, that is account takeover by authorization failure, not by password theft.
Q: Why do session binding flaws create privacy risk even without stolen credentials?
A: Because customer sessions often carry access to stored addresses, order history, and account profile data. If the application accepts the wrong identity context inside that session, the attacker inherits legitimate access rather than breaking in visibly. The privacy harm comes from the platform trusting the session state more than the customer identity behind it.
Q: What are the signs that storefront session governance is failing?
A: Look for inconsistent session behavior across customer accounts, unexplained account-context changes, and storefront assets that are patched unevenly across production and non-production environments. Those signals usually indicate that session controls are not being tested as part of the application’s identity boundary, especially in distributed commerce estates.
Q: How should teams respond when a storefront session flaw is disclosed?
A: Prioritise inventory, patch verification, and session invalidation across every exposed storefront instance before assuming the issue is contained. The key is to remove any authenticated session state that may have been created on vulnerable builds and to validate that no account-switching behaviour remains after remediation.
Technical breakdown
How session binding fails in commerce authentication
Session binding is the process that keeps a browser session tied to the identity that authenticated it. In a correct design, the server associates the session with a specific account context and rejects attempts to reuse that session as another user. Here, the flaw is incorrect authorization, not password theft. The attacker does not need to log in, because the platform accepts a session state that should not be transferable. Once that binding is broken, every downstream account action inherits the wrong identity context. This is why session integrity matters as much as authentication itself in customer-facing IAM flows.
Practical implication: Treat session-to-identity binding as a control requirement, not a convenience feature, and test it explicitly in storefront authentication flows.
Why session switching becomes account takeover
Account takeover does not always require credential capture. In this case, the attacker can switch an active session to another customer account and then act with that account’s authenticated context. That means the attacker is not breaking into the session after login, but hijacking the trust already established by the application. The security impact is especially severe in commerce because the session often exposes order history, stored addresses, and personal profile data. A flaw like this demonstrates that authorization must be evaluated at the session layer, not only at login.
Practical implication: Verify that session state cannot be reassigned across customer identities, especially where the session exposes personal or transactional data.
Why storefront exposure is amplified in distributed commerce estates
Commerce platforms rarely exist as one neatly governed application. They are spread across production storefronts, campaign microsites, staging hosts, and agency-managed builds, often with inconsistent patching and incomplete inventory. That creates a wide attack surface even when only a subset of assets is confirmed vulnerable. Because the storefront is public by design, the only real barrier is whether the platform enforces authorization correctly for each session. This makes asset visibility and lifecycle ownership part of the security control set, not just operational housekeeping.
Practical implication: Maintain a complete inventory of storefront and non-production commerce assets so session-layer defects are not left exposed on forgotten hosts.
Threat narrative
Attacker objective: The objective is to take over a customer session and use that authenticated context to view or manipulate account data.
- Entry occurs through public network access to the storefront, with no authentication required.
- The attacker exploits incorrect authorization to rebind or switch an active customer session to a different account.
- The attacker inherits the authenticated context of that customer account and can access personal data and order history.
Breaches seen in the wild
- 23andMe credential stuffing 2023: Credential stuffing into 18,000 accounts exposed nearly 7 million people through the DNA Relatives feature.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Session binding is an identity control, not just an application detail: this flaw shows that commerce platforms can fail at the exact point where authentication should become authorization. When a session can be reassigned, the application has lost the ability to distinguish one customer from another. Practitioners should treat session integrity as part of identity governance, not only web hardening.
Incorrect authorization creates a direct privacy breach path: the risk here is not abstract escalation but authenticated access to customer records, order history, and profile data. That makes the failure materially different from generic web exploitation because the attacker lands inside a legitimate account boundary. The governance lesson is that privacy exposure can originate from broken session state even when credentials remain untouched.
Distributed commerce estates create session-risk debt: campaign sites, staging systems, and agency-built storefronts often inherit the same session logic but not the same oversight. That means the defect can persist in places security teams do not continuously monitor. Commerce identity sprawl: the combination of multiple storefronts, shared codebases, and weak asset ownership makes session-boundary failures more persistent than teams assume. Practitioners should align inventory, patching, and session testing around the full storefront estate.
Patch availability does not remove exposure until lifecycle control catches up: fixed builds help only if the estate is inventoried, updated, and verified across every storefront instance. The broader market signal is that customer identity risk now sits at the intersection of IAM, application security, and asset governance. Teams should move from login-centric thinking to end-to-end session governance.
What this signals
Commerce identity sprawl: storefronts, staging hosts, and campaign sites often inherit the same session logic but not the same governance. That creates a control gap where account takeover risk persists outside the primary production application, so security teams need inventory and session testing across the full estate.
When customer sessions can be rebound across accounts, IAM and application security stop being separate disciplines. The practical control boundary shifts to session integrity, because the attacker is exploiting a broken trust relationship, not a stolen password.
Organizations that run branded storefronts through agencies or distributed business units should expect this class of flaw to surface unevenly across environments. The governance challenge is not only patching the code, but proving that no public instance still accepts the vulnerable session state.
For practitioners
- Inventory every storefront instance Include production, staging, campaign, UAT, and agency-managed Adobe Commerce and Magento hosts in the asset register so patching and validation cover the full estate.
- Test session-to-account binding Validate that an authenticated customer session cannot be reassigned to another account and that account context remains fixed for the life of the session.
- Invalidate customer sessions after remediation Force session reissuance once fixed builds are deployed so any previously exposed authenticated context cannot be reused.
- Monitor for unexpected account switching Review storefront logs and edge telemetry for anomalous session changes, unusual customer-context transitions, and access to stored profile or order data.
- Reconcile patch state against isolated releases Verify that each supported branch is on the required release before applying the corresponding security patch, because the remediation path is two-step on behind-schedule estates.
Key takeaways
- The underlying issue is failed session binding, which lets a customer session be reassigned to another account without credentials.
- The impact is direct account takeover, with access to personal data and order history once the attacker holds the authenticated context.
- The limiting control is strict session-to-identity binding across every storefront instance, backed by complete asset inventory and post-fix session invalidation.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The flaw breaks the trust boundary between customer identity and authenticated session state. |
| NHI-05 — Overprivileged NHI | The authenticated session exposes more account context than it should when rebound incorrectly. | |
| Recommendation — Validate that customer sessions remain bound to the correct identity for the full session lifetime. Limit session scope so authenticated context cannot expose unrelated customer data or actions. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Session and token handling sit within authenticator lifecycle management for customer access. |
| Recommendation — Apply authenticator management controls to revoke and reissue exposed customer sessions after remediation. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The issue is an authorization failure at the customer-session boundary. |
| Recommendation — Enforce authorization checks that keep each session tied to the correct account and entitlements. | ||
| MITRE ATT&CK | TA0006;TA0004 — Credential Access; Privilege Escalation | The attacker exploits access-state trust to gain higher authenticated privilege without credentials. |
| Recommendation — Map session-rebinding behaviour to credential access and privilege escalation detections. | ||
Key terms
- Session Binding: A control that ties an authenticated session to the device, connection, or risk context that created it. When applied well, it makes stolen cookies harder to reuse from an untrusted endpoint or a different network context.
- Incorrect Authorization: An application authorises an action or identity transition that should have been blocked. In practice, the user may already be authenticated, but the software fails to enforce the rule that keeps one identity or privilege boundary separate from another.
- Account Takeover: Account takeover is unauthorized use of a legitimate account after an attacker obtains valid access through stolen credentials, tokens, or trusted integrations. The key security problem is that the resulting activity often looks normal to logs and controls, which makes containment and attribution harder than in a forced-entry breach.
- Session Rebinding: Session rebinding is the reassignment of an existing authenticated session to a different identity or account context. When a platform permits rebinding, the attacker inherits the application’s trust in that session and can act as the targeted customer.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners who need to connect identity control to real operational risk across their programmes.
Published by the NHIMG editorial team on August 18, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org