Threat feed
CVE-2026-71362 — Unauthenticated privilege escalation in Adobe Commerce and Magento (explainer and fix)
CVE-2026-71362: unauthenticated privilege escalation in Adobe Commerce and Magento (CVSS 9.1), fixed 11 Aug, in CISA KEV since 24 Sep. Fixed versions and post-patch checks.
This is a rapid explainer for a vulnerability that is being actively exploited (listed in CISA KEV). It covers what happens, who is affected and how to respond — from the defender's side, with no reproduction steps.
- CVE
- CVE-2026-71362
- Severity
- Critical (CVSS 9.1 / v3.1)
- Type
- Incorrect authorization (CWE-863)
- Impact
- Privilege escalation — in Adobe's words, "elevated access to sensitive resources"
- Preconditions
- No authentication, no admin privileges, no user interaction
- Affected
- Adobe Commerce (2.4.4–2.4.9), Adobe Commerce B2B, and Magento Open Source (2.4.6–2.4.9), each line at "2026-jul" and earlier
- Fix
- The "2026-aug" release of the same line (published 11 August 2026, bulletin APSB26-92)
- Exploitation
- In CISA KEV (added 24 September 2026, remediation due 27 September), flagged as requiring forensic triage
How dangerous is it to wait?
No authentication and no user interaction means every internet-facing store is reachable. The EPSS estimate of roughly 90% puts it in the top 0.3% of all CVEs. E-commerce sites hold customer data and sit in front of payments, which has long made them a prime target for automated attacks. "We're a small shop" is irrelevant to something that scans indiscriminately.
What kind of flaw is it?
Authorization decides whether this caller may perform this action or see this data. It is a separate question from whether they managed to log in (authentication), and a gap in the authorization decision puts functions and data within reach that should not be. The distinction is covered in authentication vs authorization.
CVE-2026-71362 is such a gap (CWE-863), which Adobe classifies as privilege escalation. Its CVSS vector includes PR:N — rated as exploitable by someone who is not logged in — with high impact on both confidentiality and integrity. This site does not describe how it is exploited.
11 Aug — fix released (APSB26-92)
Priority 2 / "not aware of exploits" → many stores could reasonably defer to the next scheduled update
18 Aug — bulletin last updated
The exploitation note has not changed since
24 Sep — CISA adds it to KEV (due 27 Sep)
Exploitation confirmed. Unpatched stores may have been targeted before this date
Who is affected
| Product | Affected | Fixed |
|---|---|---|
| Adobe Commerce | 2.4.9 / 2.4.8 / 2.4.7 / 2.4.6 / 2.4.5 / 2.4.4, each at 2026-jul and earlier | 2026-aug of the same line |
| Adobe Commerce B2B | 1.5.3 / 1.5.2 / 1.4.2 / 1.3.4 / 1.3.3, each at 2026-jul and earlier | 2026-aug of the same line |
| Magento Open Source | 2.4.9 / 2.4.8 / 2.4.7 / 2.4.6, each at 2026-jul and earlier | 2026-aug of the same line |
| Older lines | NVD lists versions before 2.4.4 as affected | No fix — move to a supported line |
The same bulletin fixes six other vulnerabilities
APSB26-92 fixes seven issues in total, including stored XSS and other authorization flaws. Only CVE-2026-71362 is in KEV, but updating closes all seven at once. Updating is faster than hunting for per-issue workarounds.
What to do
Update to your line's 2026-aug release (first, and the real fix)
Confirm the line and patch level of your store, then update to the 2026-aug release of that line and confirm the running version changed. If you run several environments — production, staging, an old spare storefront — everything reachable from the internet is in scope. The forgotten old store is the one least likely to be patched (security inventory checklist).
On an unsupported line, put migration on today's agenda
Lines older than 2.4.4 get no fix. Migration takes time, so meanwhile restrict who can reach the admin and API entry points and turn on WAF protections to shrink who can reach you. That buys time; it does not close the hole — migration does.
Check whether you were entered while unpatched
If the store stayed unpatched at any point after 11 August, treat that window as suspect; CISA also lists this CVE as requiring forensic triage. At minimum: (1) Admin accounts — any you do not recognise, or changed permissions. (2) Integrations and API tokens — any you did not create, or recently issued tokens. (3) Files and configuration — especially scripts loaded on checkout and HTML or settings editable from the admin panel (in e-commerce compromises, planting something that steals payment data is the typical goal). (4) Logs — access to admin or API functions from unusual sources, at unusual hours, or in unusual volume.
If anything looks wrong, rotate credentials together
If you cannot rule out an intrusion, rotate admin passwords, integration tokens, and keys for payment and external APIs, and invalidate all sessions. A patch closes the door; it does not revoke keys that already walked out — closing the hole and evicting the intruder are different jobs. The full process is in the vulnerability remediation playbook.
Stop waiting for 'the next update'
As here, an update judged non-urgent at release can become urgent later. Get notified when something lands in KEV (this site's vulnerability alerts are one way), or apply security updates outside the regular update cycle.
This site's view: 'priority 2' was not wrong. It just stopped moving
Blaming Adobe's rating at release misses the point. If no exploitation had been seen when it shipped, a lower priority was a reasonable call. The problem is that the rating stays frozen in the bulletin while readers treat it as current.
That structure is not unique to Adobe. Vendor severity (CVSS, priority) describes the flaw itself; KEV and EPSS describe whether it is being targeted now. The first is set once at publication and does not move; the second moves daily. That is why this site recommends that patch order is not decided once at release but re-assigned as KEV and EPSS change. Forty-four days is how long a store stayed exposed without that re-assignment.
Sources
- Adobe — Security update available for Adobe Commerce | APSB26-92 (published 11 August 2026, last updated 18 August; affected and fixed versions, priority, CVSS, and the "not aware of exploits" note)
- NVD — CVE-2026-71362 (CWE-863, CVSS v3.1 9.1; affected configurations include versions before 2.4.4)
- CISA KEV — Known Exploited Vulnerabilities Catalog (added 24 September 2026, due 27 September, forensic triage required)
- FIRST — EPSS (0.896 on 25 September 2026, 99.78th percentile)
Read next
- Deciding: Prioritising with CVSS, EPSS and KEV / The vulnerability remediation playbook
- How it works: Authentication vs authorization / What is IDOR?
- The contrasting case: CVE-2026-87902 (WordPress core: KEV three days after the fix)
- Another Magento alert: CVE-2026-45247 (unauthenticated RCE in a Magento extension)
- Terms: What is CVSS? / What is PCI DSS?
FAQ
QWhat does CVE-2026-71362 allow?
According to Adobe's bulletin, an incorrect-authorization flaw (CWE-863) allows privilege escalation, letting an attacker gain elevated access to sensitive resources. Exploitation requires no authentication, no admin privileges and no user interaction (CVSS 9.1). CISA added it to the KEV catalog on 24 September 2026 after confirming active exploitation.
QWhich versions are affected, and what do I update to?
Adobe Commerce 2.4.4 through 2.4.9 at '2026-jul' and earlier, Magento Open Source 2.4.6 through 2.4.9 at '2026-jul' and earlier, and Adobe Commerce B2B. The fix is the '2026-aug' release of the same line (for example 2.4.8-2026-aug). NVD also lists versions before 2.4.4 as affected; lines that are out of support have no fix, so they need to move to a supported line.
QDoesn't Adobe say there are no known exploits?
Yes. The bulletin, last updated 18 August 2026, says Adobe is not aware of exploits in the wild. On 24 September CISA confirmed exploitation and added the CVE to KEV. A bulletin's exploitation note reflects what was known when it was written and is not necessarily updated later; let the KEV listing drive your decision.
QAm I done once I patch?
No. The fix has been available since 11 August, so any period after that in which your store stayed unpatched is a period in which it may have been entered. CISA also lists this CVE as requiring forensic triage. Review admin accounts and integrations/API tokens, check files — including scripts loaded on checkout — for changes, and review logs.