The critical CVE-2026-71362 vulnerability affecting Adobe Commerce and Magento Open Source demonstrates how a relatively subtle authorization failure can undermine the entire trust model of an e-commerce customer account. The vulnerability allows an unauthenticated attacker to manipulate customer-session identity so that a session can effectively be switched to another customer account. Successful exploitation can expose private customer information without requiring the attacker to know the victim’s password, compromise an administrator account or convince the victim to click anything. For merchants, this is particularly serious because the security controls surrounding passwords and multi-factor authentication may remain completely intact while the application itself incorrectly decides which customer identity belongs to the attacker’s session. 

The flaw received a CVSS score of 9.1 and is categorized as an incorrect-authorization vulnerability. This distinction matters because the weakness is not fundamentally about stealing or guessing authentication credentials. The vulnerable application has already created a session, but insufficient authorization logic allows the identity associated with that session to be changed improperly. In effect, the attacker abuses the application’s own understanding of who the current user is rather than defeating the authentication process directly.

This illustrates the crucial difference between authentication and authorization. Authentication establishes an identity, while authorization determines which resources that identity may access. An application can implement strong passwords, passkeys or MFA and still expose customer information if server-side authorization accepts a manipulated identity value without independently verifying that the session genuinely belongs to that customer.

For e-commerce platforms this type of vulnerability is especially dangerous because customer accounts contain considerably more than usernames and passwords. Depending on the store configuration, an account may contain customer names, addresses, telephone numbers, order histories, saved preferences, loyalty information, invoices and other information useful for fraud or impersonation. The value to an attacker therefore comes not only from account access but from the business context contained within the account.

Order history can be particularly useful for secondary social engineering. An attacker who knows what a customer purchased, when it was ordered and where it was delivered can construct convincing messages impersonating the merchant, courier or payment provider. The phishing message no longer needs to be generic because it can reference genuine transaction information.

Attackers could similarly exploit account access to manipulate information rather than simply read it. Depending upon the permissions available through the compromised session and the individual store’s implementation, changes to contact details, shipping information or account preferences may create opportunities for subsequent fraud. Merchants should therefore investigate both data access and modifications associated with suspicious sessions.

The vulnerability also shows why session security needs to be considered independently from password security. Organizations often devote substantial resources to preventing credential stuffing, enforcing MFA and detecting password reuse. Those protections remain important, but none of them help when an application allows an attacker to inherit somebody else’s authenticated identity through a server-side logic error.

Session identifiers and customer identities must therefore be bound securely on the server. The client should never be able to influence account ownership simply by changing a request parameter, object identifier or other piece of session-related information. Every sensitive operation should resolve the authorized customer identity from trusted server-side state.

This principle applies well beyond Adobe Commerce. Similar failures appear as broken object-level authorization in APIs, insecure direct object references and tenant-isolation defects in SaaS platforms. The common problem is that the application accepts an identifier supplied by the user and assumes that because the identifier exists, the user must be entitled to access the corresponding object.

API testing should therefore include attempts to substitute customer identifiers, account IDs, order IDs and session-related parameters across users. Security testers should explicitly ask what happens when User A presents a valid request but replaces one identity reference with User B’s value. Automated scanners may miss these flaws because the request itself can remain syntactically valid.

The Adobe Commerce REST API deserves particular attention because modern commerce platforms expose substantial functionality through APIs used by storefronts, mobile applications and integrations. The graphical storefront is only one interface into the platform. Attackers interact directly with APIs and do not need to follow the navigation paths presented to legitimate customers.

Merchants should consequently inventory every externally reachable API and determine whether authentication and authorization are enforced independently for each operation. An endpoint hidden from the normal website interface is not protected merely because customers cannot click their way to it.

The report from Sansec is particularly significant because its researchers say they have already observed exploitation attempts against CVE-2026-71362. Adobe’s advisory states that Adobe itself was not aware of exploitation when the bulletin was published. Those two observations are not necessarily contradictory: vendor advisories and external monitoring frequently have different visibility and timing. The responsible conclusion is that exploitation attempts have been observed externally and merchants should act as though internet-facing vulnerable stores are being tested.

Attack automation can spread rapidly after patches become available because attackers can reverse engineer the differences between vulnerable and corrected code. Security patches are therefore useful not only to defenders but also to adversaries trying to understand precisely which code path was repaired.

This creates a familiar race following disclosure. Organizations begin testing and scheduling the patch while attackers compare software versions, reproduce the vulnerability and scan the internet for stores that have not yet updated. Mature vulnerability-management programmes need processes capable of shortening this period substantially for critical internet-facing applications.

Adobe released the fix as part of APSB26-92 on August 11, 2026. The bulletin covers Adobe Commerce, Commerce B2B and Magento Open Source and includes seven vulnerabilities, several of which are rated Critical. CVE-2026-71362 deserves particular attention because it requires no authentication or user interaction and directly impacts customer account confidentiality and integrity.

The patching process also requires care because Adobe’s current monthly security model distributes these fixes as isolated patches rather than necessarily providing new Composer packages for every monthly update. Merchants must first ensure that they are running the latest supported `-p` release for their release branch before applying the relevant August isolated patch.

This operational detail is important because an organization can believe that it has “installed the August fix” while still running an unsupported or incompatible base patch level. Security teams should verify the actual runtime state after deployment rather than relying solely on a completed change ticket.

Production, staging, disaster-recovery and secondary storefronts should all be checked. Forgotten Magento environments are particularly dangerous because they may remain publicly reachable while receiving less monitoring and slower patching than the primary production store.

External attack-surface discovery can help identify those systems. Organizations should scan their own domains and cloud infrastructure from an outside perspective to determine which Commerce installations and administrative interfaces are actually accessible. Attackers will discover abandoned systems regardless of whether the internal asset inventory remembers them.

Patching should be followed by investigation where vulnerable systems were publicly exposed. Because account takeover does not necessarily require installing malware on the server, conventional indicators such as web shells or suspicious binaries may be absent. The evidence may instead exist in application sessions, REST API requests, authentication events and unusual access to customer records.

Security teams should look for sessions accessing accounts inconsistent with their normal identity history, unusual sequences of customer-account requests, large-scale enumeration, changes to customer profiles and repeated attempts against API endpoints associated with session handling.

IP addresses provide some investigative context but should not be trusted as the primary detection method. Attackers can distribute requests across cloud servers, proxies and residential networks. Behaviour associated with account switching and unauthorized object access is considerably more durable than any particular source address.

Session invalidation should be considered if exploitation is suspected. Existing customer sessions may have been manipulated or copied, so terminating active sessions forces users to establish new authenticated state after remediation.

Merchants should also review whether customer account tokens, API tokens or other authentication material may have become accessible through compromised accounts. Secrets that may have been exposed should be revoked rather than assuming the application patch makes previously stolen information harmless.

Logging becomes particularly important because authorization vulnerabilities can look like legitimate application use. The server may return HTTP 200 responses, and no malware signature needs to trigger. Without detailed identity and API logging, the attacker’s requests can disappear among normal customer traffic.

Commerce platforms should therefore log not only successful authentication but also the relationship between session identity, customer ID, requested object and authorization decision. This allows security teams to identify impossible transitions where the same session begins accessing resources belonging to unrelated customers.

Rate limiting can provide another layer of protection. An attacker attempting to enumerate or switch through large numbers of customer accounts should encounter behavioural thresholds even if individual requests appear technically legitimate.

However, rate limiting cannot correct broken authorization. A patient attacker can operate slowly, and highly targeted attacks may require only one victim account. The underlying server-side identity validation still needs to be fixed.

Web Application Firewalls can offer useful temporary protection when exploit patterns are known. Sansec says its Shield product is blocking observed CVE-2026-71362 exploitation attempts. Similar protections can provide breathing room during emergency patching, but merchants should not treat WAF signatures as equivalent to removing the vulnerability.

Application-layer exploits can often be modified sufficiently to evade pattern-based rules. The reliable long-term control is corrected application logic, with a WAF serving as defense in depth.

Customer accounts should also be protected against downstream fraud after a suspected incident. Merchants may need to monitor unusual address changes, password resets, new payment methods and abnormal ordering behaviour associated with potentially affected accounts.

Sensitive account changes can require re-authentication. A session that has been active for hours should not automatically be permitted to change a shipping address, email account or stored payment setting without proving the user’s identity again.

This is particularly valuable against session-based compromise because the attacker may possess a valid session but not the victim’s password or phishing-resistant authentication factor. Step-up authentication therefore introduces another boundary between basic account access and high-risk changes.

Payment-card exposure should not be assumed automatically. Commerce environments increasingly use payment providers that tokenize card details so merchants do not store full payment credentials directly. Organizations should determine what information their particular storefront makes available to authenticated customers rather than broadly claiming that the vulnerability exposes card information without evidence.

At the same time, even masked payment information and order history can improve attackers’ ability to impersonate merchants or customers. Data need not contain a full card number to create meaningful fraud risk.

Customer-service teams represent another potential attack surface after account-data exposure. An attacker armed with genuine addresses, orders and contact details may call support and appear to have strong knowledge of the customer’s account.

Support processes should therefore avoid treating information visible inside the account as proof of identity. Order number, address or recent purchase details may all be information an attacker obtained through the compromised session.

Account-recovery operations should rely on independent authentication factors rather than knowledge-based questions. Knowing private customer data is no longer strong evidence that the caller is the customer when the security incident itself may have exposed that data.

The vulnerability additionally highlights the importance of privacy-oriented application architecture. Commerce platforms should reveal only the minimum customer information needed for each function. An account page should not expose unnecessary historical or internal information merely because the backend database contains it.

Data minimization reduces breach impact. Every field not presented or accessible through the affected authorization context is one fewer field the attacker can retrieve.

Third-party Magento extensions should also be considered during incident response. Commerce installations frequently contain numerous plugins for payments, shipping, loyalty, analytics and marketing, all of which may react differently when an attacker gains another customer’s authenticated session.

The Adobe core vulnerability may therefore produce downstream consequences unique to each merchant. Security testing needs to examine what a hijacked customer session can reach after extensions and custom modules are installed.

Custom code can also reintroduce authorization weaknesses even after Adobe fixes the platform. Developers should avoid assuming that because the core Commerce framework identifies the user, every object requested by that user automatically belongs to them.

Code review should examine authorization decisions whenever customer-controlled identifiers reach database queries or business operations. Centralized access-control helpers are preferable to individual developers implementing ad hoc checks repeatedly.

Commerce organizations should make authorization testing part of continuous application security rather than an occasional penetration-test exercise. Automated API tests can create two test customers and deliberately attempt cross-account operations during every release.

Such testing is particularly useful because authorization regressions frequently arise when new features are added. A developer may secure the original account endpoint correctly but overlook ownership checks in a new export, refund or loyalty API.

The August security update also fixes several stored cross-site scripting and additional authorization vulnerabilities. This matters because attackers rarely restrict themselves to one CVE once they begin researching a platform. Organizations that apply only an isolated workaround for CVE-2026-71362 while leaving other August flaws unresolved may simply exchange one available attack path for another.

Security patching should therefore address the complete supported update set wherever possible. Emergency isolated patches are useful when rapid remediation is necessary, but maintaining the supported release baseline remains the healthier long-term strategy.

Unsupported Commerce branches create an escalating operational problem. Older releases may still run perfectly from the merchant’s perspective while gradually becoming more difficult to secure. Lifecycle planning should therefore be treated as security work rather than merely application modernization.

The most important architectural lesson from CVE-2026-71362 is that a session is not inherently trustworthy simply because the server created it. Every request still needs authorization based on immutable, server-controlled identity information.

Applications should never allow customer-controlled input to redefine who the server believes the customer is.

For merchants, the immediate priority is to apply APSB26-92, verify the installation on every supported Commerce and Magento environment and investigate exposed systems for suspicious session and API behaviour.

For development teams, the lesson is to treat authorization as a server-side invariant tested continuously across every customer object and API.

For security teams, the incident demonstrates why monitoring successful requests can be just as important as monitoring blocked ones. An attacker exploiting broken authorization may generate perfectly valid HTTP traffic and receive perfectly successful responses.

Attempts to exploit a critical vulnerability (CVE-2026-71362) in Adobe's Commerce and Magento e-commerce platforms have been detected, potentially allowing attackers to hijack customer accounts. [...]

Source: Hackers exploit critical Adobe Commerce flaw to hijack customer accounts via Bleeping Computer — published 12 Aug 2026.