SURIQ
A stranger can log in as your customers on an Adobe Commerce or Magento store, read their personal details and order history, and never touch a password. That is what CVE-2026-71362 allows: an unauthenticated account takeover that Adobe rates 9.1 out of 10 on the standard severity scale. Adobe shipped the fix on August 11, and within about a day the security firm Sansec reported blocking the first attempts to use it. Patch fast. Then do the part the wire reports skip: work out what an attacker could have done to your storefront before you closed the hole.
What the flaw actually does
The bug is an incorrect-authorization flaw. The platform does not properly tie a logged-in shopper's identity to their session, and that gap lets an attacker point a live session at someone else's account instead. The attacker needs no account of their own, no elevated rights, and nothing at all from the person being targeted. Once the swap happens, the attacker sees whatever that shopper sees: saved addresses, contact details, and past orders.
The severity math reads the way the nastiest pre-authentication bugs do: reachable straight over the network, cheap to attempt, gated by no privileges and no victim clicks, and heavy on both the confidentiality and the integrity of shopper data. A public storefront satisfies every one of those preconditions the moment it goes live.
Who is affected and how the fix works
The flaw reaches all three shipping products: Adobe Commerce, Adobe Commerce B2B, and Magento Open Source, on every release up to and including the July 2026 patch level, per Adobe's bulletin and reporting from SecurityWeek. Analysis by CyCognito puts the affected lines at Adobe Commerce 2.4.4 through 2.4.9, Magento Open Source 2.4.6 through 2.4.9, and Commerce B2B 1.3.3 through 1.5.3.
| Product line | Affected through | Fix |
|---|---|---|
| Adobe Commerce | July 2026 patch level (2.4.x) | APSB26-92 isolated patch |
| Adobe Commerce B2B | July 2026 patch level | APSB26-92 isolated patch |
| Magento Open Source | July 2026 patch level (2.4.x) | APSB26-92 isolated patch |
Adobe published the fix as bulletin APSB26-92, which bundles this critical bug with six other defects, including stored cross-site-scripting and authorization issues, for seven CVEs in total. Here is the operational trap worth naming: the fix is distributed as an isolated patch file, and it applies cleanly only if the store is already on the latest quarterly (-p) release for its line. A merchant who runs the patch on a lagging base, or who assumes "we applied something" without confirming the base version, can walk away believing they are covered while the storefront stays open. Confirm the base release first, apply the isolated patch, then verify.
Is it being exploited?
The reporting is split, and the split is itself the useful signal. Adobe's advisory stated it had no evidence of exploitation in the wild at publication. Sansec, which sells a Magento-focused firewall, said it began blocking exploitation attempts against the flaw shortly after the advisory went out. A one-command proof-of-concept lab that reproduces the account switch also appeared on GitHub on August 15. We have not independently verified attack telemetry, and the two accounts do not have to be reconciled to act on them.
Treat an unauthenticated, no-interaction, 9.1-severity flaw in a widely deployed storefront as exploited until you have proof otherwise, rather than waiting for a vendor to confirm it in the wild. The gap between "patch available" and "someone is trying it" was measured in hours here, not weeks.
Patch is step one. Hunting the window is step two.
On an online store, an account-takeover primitive is not the end goal. It is a way into customer data and, historically, into the checkout flow. Magento stores have been the primary target of card-skimming crews for years, the groups broadly known as Magecart, who plant hidden JavaScript to steal payment details as buyers type them. A session-switch bug is a clean foothold for exactly that kind of follow-on, the same pattern behind webshell campaigns that ride unpatched CMS plugins. So the real work after patching is finding out whether anyone got in during the exposure window. Concretely:
-
Invalidate all active customer sessions after you apply the patch, so any session an attacker already switched into is killed.
-
Review storefront and access logs for a single session or source touching multiple distinct customer accounts or order pages in quick succession, the pattern a session-switch attack leaves behind.
-
Check your storefront and checkout pages for injected or unfamiliar JavaScript, and diff your theme and third-party extension files against known-good copies, the standard hunt for a payment skimmer.
-
Watch for new or altered administrator accounts and scheduled tasks, the usual persistence an attacker sets up once inside, as we saw with hidden admin accounts planted through a CMS supply chain.
If you run managed detection, the storefront log pattern above is the thing to have an alert on, not just the patch-compliance check. Patching closes the door. It does not tell you whether anyone walked through it first.
The bottom line
This is a fast one. A pre-authentication account takeover on the platform that runs a large slice of the world's online stores, patched on a Monday and probed within a day, with a public proof-of-concept by the end of the week. Apply APSB26-92 on a correctly based install, kill active sessions, and hunt the exposure window for skimmer code and rogue accounts. The stores that get burned by this will be the ones that patched and assumed the job was done.