APSB26-92: Critical Adobe Commerce Account Takeover

APSB26-92 is a regularly scheduled update for Adobe Commerce and Magento Open Source, and it fixes seven vulnerabilities. Six of them are the ordinary run of a Magento bulletin, the kind you fold into your next maintenance window without losing sleep. The seventh is not.

CVE-2026-71362 is rated CVSS 9.1, critical. Adobe classes it as an incorrect authorization issue enabling unauthenticated customer account takeover. Technically, it lets an attacker switch a customer session to another customer account, which hands them that victim's account and private customer data.

What pushes the score to 9.1 is what the attacker does not need. No existing account. No admin privileges. No user interaction. There is no phishing step and no link a shopper has to click. The flaw is in the authorization logic itself, which is why Adobe's fix changed how Commerce and Magento handle customer identity in account sessions.

Translate that into consequences. A Magento customer account holds order history, delivery and billing addresses and contact details, so account takeover is a personal-data incident with real names attached: a compliance question as well as a security one.

Every storefront visitor carries a session: the store's memory of who you are between one page and the next, including the customer identity the application binds to it. Authorization decisions across the whole account area, order history, address book, saved payment methods, hang off that one binding.

An incorrect authorization flaw in that binding is about as bad as web application bugs get, because it does not require breaking authentication at all. The attacker does not guess a password or steal a cookie. They cause the application to associate a session they control with a customer identity they have no claim to. The request that follows looks entirely legitimate from the store's side, a customer viewing their own account, and the authorization check passes because the store already believes the wrong thing about who is asking.

A vulnerability that requires a login leaves you a second line of defence: rate limiting, two-factor authentication, unusual-login alerting. One that needs no login at all bypasses every one of those, because none of them are in the path. The only durable answer is the patch.

This is the part most likely to be reported badly, so here is the careful version, in order:

• Adobe stated it had no evidence of exploitation in the wild at the time it issued the bulletin.
• Sansec then blocked the first exploitation attempts shortly after Adobe's advisory was published.
• No successful compromises have been publicly confirmed.

Plainly: attack attempts began within days of disclosure and are being blocked. That is not the same as stores being breached, and we are not going to pretend it is. If you have seen a headline suggesting Magento stores are currently being mass-compromised through CVE-2026-71362, that claim is running ahead of the evidence.

It is also not a reason to relax. Attempts appear within days for a structural reason: Adobe publishes a fix, attackers diff the patched code against the vulnerable code and work backwards to an exploit, and a change to how customer identity is handled in account sessions is extremely legible in a diff. Treat "attempts blocked, no confirmed compromises" as meaning you still have a scheduling window rather than an incident, and then use it. We covered how that clock runs in our write-up of July's APSB26-73 bulletin.

Adobe's own knowledge-base article lists the affected versions as follows. These are the July 2026 isolated-patch levels, and the phrase "and earlier" is doing a lot of work in every row.

The bulletin affects Adobe Commerce, Adobe Commerce B2B and Magento Open Source. No edition quietly escapes this one, and no supported 2.4.x line is out of scope. B2B merchants should read that middle entry twice: on a B2B store a customer account is a seat inside a company account, so the reach of a single takeover is wider and the data behind it more commercially sensitive.

This is the operational detail that turns a 90-minute job into a lost evening, and it is confirmed by both Adobe's knowledge-base article and Sansec:

In a sequence you can act on: apply the July 2026 patches from APSB26-73 first, then apply the APSB26-92 isolated patch for your release line on top.

Adobe has not published, and we will not invent, a set of new version numbers to type into a composer command. What you need is the APSB26-92 isolated patch for your release line, from Adobe's knowledge-base article for this bulletin, applied to a store that is already current. The realistic running order:

1. Establish your exact version with bin/magento --version and list applied patches with vendor/bin/magento-patches -n status.
2. Back up files and database, and confirm you can restore the backup, not just that it exists.
3. On staging, bring the store to the latest -p release for its line, apply every previous monthly isolated patch, July included, then apply the APSB26-92 isolated patch.
4. Test the logged-in journeys specifically: log in, checkout as a returning customer, edit an address, view order history, log out. This patch changes session identity handling, so those are the journeys that will tell you if something has moved.
5. Schedule the production window and repeat, with a rollback plan you have actually rehearsed.

If your store is several patch levels behind, the catch-up work, not the August patch itself, is the job. Worth knowing before you promise anybody a same-day fix.

A separate issue landed the same week and belongs in the same maintenance ticket. CVE-2026-17544 is an out-of-bounds write in PHP's BCMath extension, in bccomp(). Attacker-controlled input reaching bccomp() can cause stack and heap corruption.

That last row is the nuance worth keeping straight. Other PHP CVEs from the same week were fixed in 8.2.33 and 8.3.33, but CVE-2026-17544 itself is an 8.4 and 8.5 problem only and was not backported. It matters here because Magento 2.4.9 runs on PHP 8.4 and 8.5. Unlike the Magento flaw, this one is squarely a server-layer job, applied without the merchant needing to schedule anything.

There is a version of this article a hosting company would like to write, in which we announce that our customers were already protected because we patched it at the server level overnight. We are not going to write that, because it is not true and it is not possible. CVE-2026-71362 is an application-layer flaw in Magento's own session and authorization code. It lives in the PHP that Adobe ships, not in nginx, not in the kernel, not in a firewall rule. Only applying Adobe's patch to the Magento application removes it. If a host tells you otherwise this week, that is a useful thing to have learned about them.

Our actual position, unchanged and stated on our own site:

"We handle server-level patching, PHP updates, and security hardening. Magento application updates are managed collaboratively: we apply patches in staging and coordinate go-live with your team."

Applied to this bulletin, that splits cleanly in two:

• The server layer is ours. PHP is part of the stack we maintain, so CVE-2026-17544 is entirely our job, as are the OS, the web server, TLS and the hardening around the store. Nobody needs to raise a ticket for that half.
• The Magento application patch is collaborative. We apply the APSB26-92 patch in staging, verify it against the store's actual patch level, run the logged-in journeys the fix touches, then coordinate the production go-live with your team. An account-takeover fix that changes session handling has to be tested against a real checkout first, on a real copy of your catalogue, extensions and payment integration.

That second point is not us being slow. Sessions are where Magento, your theme, your payment provider and every customer-facing extension touch the same object, and two hours on staging beats two days of refunds. If your store is elsewhere and you want the same staged approach, our free Magento migration service is the usual starting point, and Magento 2 hosting UK sets out what the managed side actually covers. Whoever you host with, the question to ask this week is specific: are you covering the server and PHP, the Magento application patch, or both?

Unlike a kernel bug, this is a web-layer flaw, so exploit attempts arrive as HTTP requests: exactly what a web application firewall inspects. Sansec blocking the first attempts is evidence that filtering works against what has been seen so far, and Sentinel, our Magento security suite, operates at the same layer.

Now the part that matters more: mitigation is not the same as patching. A WAF reduces exposure by blocking exploit attempts it recognises. It does not remove the vulnerability from your codebase. Rules are built from traffic already observed, so a reworked or obfuscated exploit can slip past a signature that matched last week's version. We are not claiming Sentinel makes anyone safe from CVE-2026-71362, because it does not. Only Adobe's patch does that.

The honest role for a WAF here is narrow and genuinely valuable: it buys a safer scheduling window, turning "patch tonight, badly, with no testing" into "patch on Thursday, properly, having tested checkout". We keep the running record of how we respond to disclosures like this one in our Magento Security Centre. One last thing worth doing after you patch: review customer-account activity. No compromises have been publicly confirmed, but if you find unexplained address changes or order-history access, treat it as an incident and get advice before you touch anything.