CVE-2026-71362: Adobe Commerce and Magento Incorrect Authorization Grants Elevated Access Without User Interaction

Background

Adobe Commerce (formerly Magento Commerce) and the open-source Magento platform power a large share of mid-to-large online retail storefronts, handling product catalogs, checkout, customer accounts, payment processing integrations, and administrative back-office functions. Because these platforms process customer payment data, personal information, and order history, and because the admin panel controls store-wide configuration including payment and shipping integrations, any flaw that lets an attacker gain access beyond their intended privilege level is a direct threat to both the storefront’s customers and the merchant’s business operations.

CVE-2026-71362 is an authorization — not authentication — flaw, meaning the vulnerability doesn’t let an attacker impersonate someone else’s identity outright, but instead lets a request bypass the checks that are supposed to restrict what a given identity (potentially even an unauthenticated one) is allowed to do or see.

Technical Mechanism

CVE-2026-71362 is classified under CWE-863 (Incorrect Authorization). The KEV shortDescription states that the flaw “could allow an attacker to leverage this vulnerability to gain elevated access to sensitive resources without any user interaction.”

CWE-863 covers cases where a system does perform an authorization check, but the check itself is flawed — too permissive, checking the wrong attribute, or applied to the wrong scope — such that it fails to actually restrict access the way it was designed to. In an e-commerce platform context, this commonly manifests as:

1. An endpoint or resource in Adobe Commerce/Magento — potentially within the admin panel, a REST/GraphQL API endpoint, or a module handling customer or order data — performs an authorization check intended to restrict access to users with a specific role or relationship to the resource.
2. The check is incorrectly scoped: for example, it may verify that a valid session or token exists without verifying that the session’s owner has the specific permission or ownership relationship required for the resource being requested, or it may apply a check at the wrong layer (e.g., at the UI/controller layer but not the underlying API/data layer that an attacker can reach directly).
3. Because the flaw requires no user interaction, exploitation does not depend on tricking a victim into clicking a link or performing an action — the attacker can trigger the vulnerable code path directly through a crafted request.
4. The result is that an attacker gains “elevated access to sensitive resources” — functionally a privilege escalation, where the attacker ends up with access rights beyond what their actual role or authentication state should permit.

Real-World Exploitation Evidence

CVE-2026-71362 was added to CISA’s Known Exploited Vulnerabilities (KEV) catalog on 2026-09-24. KEV listing confirms CISA has verified active, real-world exploitation of this vulnerability — not merely a theoretical risk disclosed by Adobe.

Regarding ransomware: the KEV record lists knownRansomwareCampaignUse as “Unknown.” CISA has not confirmed use of this vulnerability in ransomware campaigns at this time. E-commerce platform compromises of this kind are more commonly associated with payment card data theft, web-skimming (Magecart-style) campaigns, and order/customer data exfiltration than with ransomware deployment, though CISA’s KEV status does not speak to motive — only to confirmed exploitation.

No specific threat actor, intrusion set, or campaign name has been publicly attributed to exploitation of this CVE in the data available at the time of writing. Its KEV listing confirms active exploitation in the wild, but attribution detail is not yet public. Adobe Commerce and Magento installations have historically been a frequent target for both opportunistic mass-scanning campaigns and more targeted skimmer-injection operations, given the direct monetization path through payment data theft; organizations should treat this CVE as high-value to attackers for that reason even absent formal attribution.

Impact Assessment

A CVSS score of 9.1 at the critical tier, combined with a “no user interaction” requirement, indicates a highly reliable, low-effort attack path with severe consequences.

What an attacker achieves:

• Elevated access to sensitive resources: Per the KEV description, this directly and explicitly describes the escalation outcome — an attacker ending up with access rights they should not have, against resources explicitly characterized as sensitive.
• Confidentiality: Depending on which resources are reachable through the flawed authorization check, exposure could include customer personally identifiable information (PII), order history, stored payment method references, or admin-panel configuration data.
• Integrity: Elevated access in an e-commerce admin context frequently permits configuration changes — modifying payment gateway settings, injecting malicious JavaScript into checkout pages (a classic precursor to web-skimming attacks), or altering product/pricing data.
• No user interaction required: This removes social-engineering as a precondition, meaning the attack can be automated and scaled against many Magento/Adobe Commerce installations without needing to target specific individuals.

Sector-specific risk: This is squarely a retail/e-commerce risk. Merchants running Adobe Commerce or Magento face direct exposure of customer financial and personal data, regulatory exposure under PCI-DSS and data-protection regulations if customer payment data is touched, and reputational/brand risk from a public breach during what for many retailers is a critical sales period. The lack of required user interaction also means automated scanning tools can identify and exploit vulnerable storefronts at scale.

Affected Versions

The KEV record does not specify exact affected version ranges in the fields provided. Adobe’s security bulletin APSB26-92 is the authoritative source for version-level detail.

Organizations should consult Adobe’s security bulletin APSB26-92 for the definitive list of affected product versions and patched releases, as the KEV data supplied does not enumerate specific version boundaries.

Remediation Steps

CISA’s required action is to apply mitigations per vendor instructions, in compliance with BOD 26-04 and its Forensics Triage Requirements.

1. Apply Adobe’s security patch described in APSB26-92 to all affected Adobe Commerce and Magento Open Source installations immediately.

   # Example — applying a Magento/Adobe Commerce security patch via Composer
   composer require adobe-commerce/product-community-edition-metapackage:<patched-version> --no-update
   composer update
   php bin/magento setup:upgrade
   php bin/magento setup:di:compile
   php bin/magento cache:flush

2. Audit admin-panel and API access logs for any requests to sensitive endpoints from accounts or sessions that should not have had access, focusing on the period before the patch was applied.
3. Review storefront pages (especially checkout) for injected JavaScript as a precaution, since elevated access to admin-level configuration is a known precursor to Magecart-style skimmer injection on Magento-based storefronts.
4. Rotate admin and API credentials and tokens for the Adobe Commerce/Magento instance if forensic review cannot rule out prior unauthorized elevated access.
5. Conduct forensic triage on any internet-facing instance unpatched prior to 2026-09-24, per BOD 26-04 Forensics Triage Requirements.
6. Discontinue use of the product if mitigation cannot be applied in time, per BOD 26-04 guidance for assets that cannot be promptly secured.

Detection Guidance

Exact IOCs or signatures specific to this CVE have not been published in the data available; the following detection strategies are appropriate for an incorrect-authorization vulnerability on an e-commerce platform:

• Admin and API access logs: Review for requests to sensitive admin-panel or REST/GraphQL endpoints originating from sessions or accounts that do not match the expected role/permission level for that resource, particularly requests that succeed despite missing expected authorization headers or role claims.
• Unexpected configuration changes: Monitor Magento/Adobe Commerce admin action logs (admin_user activity logs) for configuration changes — especially to payment methods, checkout page templates, or custom JavaScript/CSS injection points — made outside of normal change-management windows.
• Storefront integrity monitoring: Periodically diff checkout and payment page source/output against a known-good baseline to detect injected scripts consistent with web-skimming.
• Anomalous customer/order data access: Watch for bulk export or unusual read patterns against customer and order data tables/APIs that don’t correlate with legitimate business processes (e.g., scheduled reporting jobs).

Because precise signatures for the vulnerable authorization check have not been publicly detailed, organizations should prioritize patching and log review over attempting independent signature-based detection, and should monitor Adobe’s and CISA’s channels for any follow-up IOC publication.

Timeline

References

• Adobe Security Bulletin — APSB26-92 (Magento/Adobe Commerce)
• CISA BOD 26-04: Prioritizing Security Updates Based on Risk
• CISA BOD 26-04 Implementation Guidance / Forensics Triage Requirements
• NVD — CVE-2026-71362