APSB26-92: A Magento Account Takeover That Needs No Login

Update, August 13: attacks have started. Sansec reports its Shield firewall is already blocking attempts to exploit CVE-2026-71362, and BleepingComputer covered it on August 12 — a day after the patch shipped. Adobe's advisory still says it isn't aware of exploits in the wild, and the bulletin is still rated priority 2. Patch now.

Adobe's August security update for Adobe Commerce and Magento Open Source landed on August 11, as bulletin APSB26-92. Seven vulnerabilities, five of them rated critical. The one that matters most is CVE-2026-71362, so that's where this starts.

An account takeover that doesn't need an account

CVE-2026-71362 scores 9.1. It lets someone take over a customer account without logging in.

Sansec's analysis calls it a session switch: an attacker moves their session onto another customer's account and gets everything in it, personal data included. No account of their own, no admin access, nothing the victim has to click. Adobe's fix changes how Magento handles customer identity in the account session.

Most Magento bugs need something to get going first, whether that's an admin login or at least a registered customer account. This one just needs a request.

The rest of the bulletin is stored XSS and authorization bugs. Adobe lists the overall impact as arbitrary code execution, security feature bypass, and privilege escalation.

What's in the bulletin

Every supported line is affected:

• 2.4.9-2026-jul and earlier
• 2.4.8-2026-jul and earlier
• 2.4.7-2026-jul and earlier
• 2.4.6-2026-jul and earlier
• 2.4.5-2026-jul and earlier
• 2.4.4-2026-jul and earlier

Those are July's patch levels, not release numbers. Patching last month doesn't take you off the list — the same thing happened in July, when 2.4.9 showed up about two months after release.

We'd treat this as priority 1

Adobe rated the bulletin priority 2 and reported no known exploits at release. We wrote this section on August 12 to argue that was the wrong call, and it took about a day to find out.

Sansec's firewall started blocking exploitation attempts against CVE-2026-71362 on August 12. Adobe's advisory still says it isn't aware of exploits in the wild, and the rating hasn't moved off priority 2 with its 30-day suggestion.

The reasoning we set out at the time applies to next month's bulletin just as well, so here it is.

Priority 1 doesn't require anyone to have written an exploit yet. The wording covers bugs "being targeted, or which have a higher risk of being targeted." An unauthenticated account takeover in Magento is about as clear a case as that second clause gets.

Priority 2 depends on Adobe not anticipating imminent exploits. That's a prediction, and it's the one we'd have argued with. Magento is among the most attacked platforms on the web, and this bug needs no credentials.

CosmicSting

CVE-2024-34102 was an unauthenticated XXE bug scored 9.8, disclosed in June 2024. Adobe rated it priority 3 at first, the tier for products nobody targets, then moved it to 2.

Mass scanning started inside two weeks. Sansec told merchants that if they hadn't patched by June 25, twelve days after the fix, they should assume their encryption keys were already gone. More than 4,000 stores were compromised over the following months, at times three to five an hour.

Patch on day 30, as priority 2 suggests, and you'd have been breached two and a half weeks earlier.

In Adobe's defense

Adobe rates a product, not your store, and the tiers lean on historical attack patterns across the whole platform. Mark everything priority 1 and the ratings stop meaning anything.

The rating also gets set before the bulletin ships, back when "no known exploits" was still accurate. It stayed accurate for about two days.

Patch this one inside 72 hours anyway. And if your release process can't move that quickly, you want to find that out now, not during the next one.

Applying it: July comes first

Adobe's isolated patches stack. August builds on July instead of replacing it — "August does not replace July," as Sam James puts it in his write-up of this patch. Skip APSB26-73 and you'll need that applied before this one.

There's a second requirement underneath. Any isolated patch needs you on the latest -p release for your line, because that's what Adobe built and tested it against.

So the real questions are:

1. Are we on the latest -p release for our line?
2. Did we apply July's patch?
3. If not, how far back does that go, and how long will catching up take?

A current store can do this in an afternoon. On a -p release from last autumn, there's a patch-level upgrade first, the regression testing that comes with it, and the security fix after that.

Where to get the patches

Adobe serves the August files from repo.magento.com:

The 2.4.4 and 2.4.5 files sit behind an authenticated URL. When the browser asks, your Composer public key is the username and your private key is the password — the same pair already in your auth.json. The other four download without credentials.

Adobe's guide to applying a Composer patch covers the rest.

Adobe ships these as patch files with no Composer package alongside them, so there's no version bump to run and every month is a manual job. It's a good part of why stores fall behind.

Sam James maintains a community package, samjuk/m2-meta-security-patches, that bundles the Community Edition patches for 2.4.6-p15 through 2.4.9 into a composer update. Handy, though it does put a third party in the middle of your security patching, so read it before you commit. It doesn't cover 2.4.4, 2.4.5, or the Enterprise and B2B builds either.

Mage-OS users get this one differently. The August content shipped as Mage-OS 3.4.0 on August 11, the same day Adobe published the bulletin, porting the isolated patch 249-2026-08-001-CE — so it's a version bump instead of a patch file. Same fix, and you still have to deploy it.

2.4.4 and 2.4.5 are still getting patches, which isn't a reason to stay on them. If you're running one of the older lines, our piece on the 2.4.6 end-of-support timeline covers where that leaves you.

What to do this week

Find out where you actually are. Run composer show magento/product-community-edition, or the Enterprise equivalent, against what's deployed and not what a ticket says. The two disagree more often than you'd think.

Apply July's patch if you haven't. No skipping it. If you're further behind, work through them in order.

Patch staging and test the account paths. The fix touches customer identity in the session: login, registration, account editing, and any custom code that reads the customer session. Checkout and payments too.

Check the patch survives your next Composer run. Sam James found patched files quietly reverting when magento2-base gets reinstalled, so a later composer install can undo the fix without saying anything. Verify after any dependency change.

Then production, inside 72 hours.

Look at your extensions separately. The bulletin only covers Adobe's code. An unmaintained third-party module with database and checkout access is a common way stores get compromised, and nobody publishes a CVE when it happens.

If you can't say what patch level you're on and when you last applied one, start there. Staying current takes a few hours a month. Getting current after a year of skipping them is a proper piece of work.

Emyrix does Magento support and maintenance, including patch management and Adobe Commerce work on stores that have fallen behind. If you're not sure what patch level your store is on, or you know you're behind and want a realistic plan for catching up, get in touch.

Sources: Adobe Security Bulletin APSB26-92 · Security update available for Adobe Commerce — APSB26-92 · Adobe severity and priority rating definitions · Sansec: Adobe patches critical Magento account takeover · BleepingComputer: Hackers exploit critical Adobe Commerce flaw to hijack customer accounts · Adobe Commerce security patch release notes