Adobe Commerce CVE-2026-71362: session hijack, exploited

Adobe shipped an emergency-grade fix for CVE-2026-71362 on August 11, and attackers were on it within a day. The flaw lets someone take over a shopper's session on an Adobe Commerce or Magento store without an account, without admin rights, and without the victim clicking anything. If you run a Magento storefront, this is a same-day patch, not a next-sprint ticket.

What actually happened

Adobe released bulletin APSB26-92 covering currently supported Commerce, Commerce B2B, and Magento release lines. CVE-2026-71362 is an incorrect authorization bug — the platform mishandles customer identity inside an account session.

Ecommerce security firm Sansec reverse-engineered the patch and described the result plainly: the flaw "lets attackers switch a customer session to another customer account," handing over the victim's account and private customer data. Their summary of the prerequisites is the part that should move your calendar — exploitation needs "no existing account, administrator privileges or user interaction."

Adobe's advisory said it was not aware of exploits in the wild. Within roughly a day, Sansec reported its Shield WAF was already blocking exploitation attempts. We are not quoting a CVSS number here because we could not confirm one against a primary source — the exploitation status already tells you everything you need for triage.

Why an unauthenticated session hijack matters for your business

Magento shops are a favorite target for a boring reason: the attack pays immediately. A hijacked customer session is not an abstract "data exposure." It is order history, saved addresses, stored payment tokens, and a logged-in checkout an attacker can drive. This is the same ecosystem that gave us CosmicSting and SessionReaper, and both followed the identical pattern — patch drops, exploit lands in days, a big share of stores are still unpatched a week later.

So do three things today, in order:

1. Apply APSB26-92. Confirm your release line is actually one Adobe still supports. If you are running an EOL Magento branch, you are not getting a patch, and that is now the top item on your roadmap.
2. Invalidate every active customer session after patching. Patching stops new hijacks. It does not evict anyone who already got in.
3. Check for the aftermath, not just the hole. Look for logins from new IPs on established accounts, address changes immediately before an order, and new admin users. We covered why the audit trail is the real deliverable — the patch is the easy half.

If your store is on a managed host, ask them today whether they have applied it, and get the answer in writing. "We handle patching" is a policy, not evidence.

Sources: BleepingComputer, Adobe APSB26-92.