{"id":2813,"date":"2026-08-13T02:56:41","date_gmt":"2026-08-13T09:56:41","guid":{"rendered":"https:\/\/www.cycognito.com\/blog\/?p=2813"},"modified":"2026-08-13T02:56:43","modified_gmt":"2026-08-13T09:56:43","slug":"emerging-threat-cve-2026-71362-adobe-commerce-account-takeover-via-session-identity-flaw","status":"publish","type":"post","link":"https:\/\/www.cycognito.com\/blog\/emerging-threat-cve-2026-71362-adobe-commerce-account-takeover-via-session-identity-flaw\/","title":{"rendered":"Emerging Threat: (CVE-2026-71362) Adobe Commerce Account Takeover via Session Identity Flaw"},"content":{"rendered":"\n
\"\"
Sample of assets impacted by Adobe account takeover vulnerability, identified by the CyCognito Platform<\/em><\/figcaption><\/figure>\n\n\n\n

What is CVE-2026-71362?<\/h2>\n\n\n\n

CVE-2026-71362 is an incorrect authorization vulnerability (CWE-863) in Adobe Commerce and Magento Open Source, caused by the platform failing to correctly bind a customer identity to an account session. The vulnerability carries a CVSS v3.1 base score of 9.1 (Critical).<\/p>\n\n\n\n

Exploitation requires no authentication. Adobe’s advisory states that the flaw is exploitable without credentials, does not require administrator privileges, and does not require user interaction. The only precondition is network access to the storefront, which is public by design for the assets that run this software.<\/p>\n\n\n\n

Adobe categorizes the impact as privilege escalation. Analysis of the patch by eCommerce security firm Sansec found the underlying problem to be improper handling of customer identity within an account session, which in practice allows an attacker to switch an active session to a different customer account. The attacker then holds that customer’s authenticated context, including access to stored personal data and order history.<\/p>\n\n\n\n

Exploit status is worth stating precisely, because the two available sources differ. Adobe’s bulletin says the vendor is not aware of exploits in the wild for any issue in the release. Sansec reports that its Shield web application firewall is already blocking exploitation attempts against this CVE. Defenders should plan on the assumption that attack traffic exists.<\/p>\n\n\n\n

What assets are affected by CVE-2026-71362?<\/h2>\n\n\n\n

The affected software is Adobe Commerce release lines 2.4.4 through 2.4.9 and Magento Open Source release lines 2.4.6 through 2.4.9, at the -2026-jul<\/code> build and earlier in each line. Adobe Commerce B2B versions 1.3.3 through 1.5.3 received fixes in the same bulletin, though CVE-2026-71362 is not flagged as B2B specific.<\/p>\n\n\n\n

In practice, an affected asset is a public web storefront served over HTTPS. The population is wider than the primary commerce domain, however. The same codebase typically runs on staging, preproduction, UAT, and developer hosts that are reachable from the internet but excluded from production change control. Admin panels, webmail hosts, and control panel ports on shared hosting frequently sit on the same infrastructure and appear in the same fingerprint.<\/p>\n\n\n\n

These assets tend to be overlooked for structural reasons rather than negligent ones. Commerce estates sprawl across brands, regions, product launches, and campaign microsites, and a large share of them are built and hosted by external agencies. A store built for a single campaign keeps serving traffic on an unpatched build long after the campaign owner has moved on, and the security team responsible for the estate often has no inventory record that the store exists.<\/p>\n\n\n\n

What does our data show about exposure patterns?<\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

Exposure in this set is led by Communication Services at 34.5% of observed assets, with Consumer Discretionary contributing 19.6% and Information Technology 14.4%. Assets in this set were identified by software fingerprint, so they represent hosts observed running the affected platform rather than builds confirmed to be at a vulnerable patch level.<\/p>\n\n\n\n

The Communication Services concentration reflects how media and entertainment groups actually operate commerce. A single publishing or broadcast group runs merchandise stores for individual titles, ticketing and licensing shops, and promotional storefronts tied to specific releases. Each of those is a separate deployment, often commissioned from a different agency on a different hosting contract, and each carries its own patch cadence. The result is a large estate of small stores rather than one well-governed platform.<\/p>\n\n\n\n

Across the remaining sectors the pattern points to the same underlying driver. Commerce is rarely a core function for a manufacturer, a hardware vendor, or an industrial group, so the storefront ends up owned by marketing or by a business unit rather than by central IT. That ownership gap is what produces the long tail of non-production hosts, forgotten campaign sites, and stores that continue serving traffic on a build nobody is tracking. The vulnerability is in the software, but the exposure is a consequence of where the software sits in the org chart.<\/p>\n\n\n\n

Are fixes available?<\/h2>\n\n\n\n

Yes. Adobe published bulletin APSB26-92 on August 11, 2026, with fixed builds in the -2026-aug<\/code> release for each supported line: Adobe Commerce 2.4.4 through 2.4.9, Magento Open Source 2.4.6 through 2.4.9, and Adobe Commerce B2B 1.3.3 through 1.5.3. Adobe assigned the update a Priority 2 rating.<\/p>\n\n\n\n

Patch availability does not mean patch simplicity in this case. According to Sansec, Adobe distributes these monthly fixes as isolated patch files rather than as a new security release or updated Composer packages. A store must already be running the latest -p<\/code> release available for its supported branch before the corresponding isolated patch will apply. Estates that have fallen behind on point releases therefore face a two-step remediation, and the interim window is longer than the advisory date suggests.<\/p>\n\n\n\n

Defenders should also note the divergence between Adobe’s statement that it is not aware of in-the-wild exploitation and third-party WAF telemetry indicating blocked exploitation attempts. Verify patch level and exploit exposure directly against your own hosts and your vendor rather than treating the advisory’s exploitation status as current.<\/p>\n\n\n\n

Are there any other recommended actions to take?<\/h2>\n\n\n\n

Recommended mitigations:<\/p>\n\n\n\n