CVE-2026-48000: Adobe Commerce Auth Bypass Vulnerability

CVE-2026-48000 Overview

Adobe Commerce contains an Improper Redirect (Open Redirect) vulnerability tracked as CVE-2026-48000 [CWE-601]. An attacker can craft a malicious URL that appears to originate from a legitimate Adobe Commerce storefront but redirects the victim to an attacker-controlled destination. This behavior enables phishing pages, credential harvesting, and account takeover once the victim clicks the link. The flaw affects Adobe Commerce, Adobe Commerce B2B, Magento Open Source, and the Adobe I/O Events for Commerce integration across multiple 2.4.x release trains. Exploitation requires user interaction, and privileged access is not needed to construct the malicious link.

Critical Impact
A trusted Adobe Commerce domain can be weaponized to redirect shoppers and administrators to attacker infrastructure, enabling phishing and account takeover against merchant customers and staff.

Affected Products

Adobe Commerce versions 2.4.4 through 2.4.9 (including all patch releases)
Adobe Commerce B2B versions 1.3.3, 1.3.4, 1.4.2, 1.5.2, and 1.5.3 (including patch releases)
Magento Open Source 2.4.6, 2.4.7, 2.4.8, 2.4.9 and Adobe I/O Events for Commerce

Discovery Timeline

2026-07-14 - CVE-2026-48000 published to the National Vulnerability Database
2026-07-16 - Last updated in NVD database

Technical Details for CVE-2026-48000

Vulnerability Analysis

The issue is a classic open redirect classified under [CWE-601]: URL Redirection to Untrusted Site. Adobe Commerce accepts a redirect target parameter and fails to validate it against an allowlist of trusted destinations. As a result, the server issues an HTTP redirect to any host supplied by the attacker while the initial request still originates from the legitimate storefront domain. Because the phishing lure carries the merchant's real hostname, mail gateways, URL reputation engines, and end users are more likely to trust it. The advisory notes the flaw enables a security feature bypass, meaning attackers can defeat protections that rely on the origin being a trusted Commerce URL.

Root Cause

The root cause is missing or insufficient validation of a user-supplied URL parameter used by Adobe Commerce redirect handlers. The application does not enforce that the target is a same-origin path or a member of a configured allowlist before issuing the redirect response. Related Magento redirect logic historically compares against Mage_Core_Model_Url or Magento\Framework\Url helpers, and gaps in that logic allow absolute external URLs to pass through.

Attack Vector

The attacker builds a link pointing to a vulnerable Commerce endpoint with a redirect parameter set to an attacker-controlled site. The victim receives the link via email, chat, or a marketplace posting and clicks it. The Commerce server returns a 302 or 301 response with a Location header pointing to the malicious host. The victim's browser follows the redirect and lands on a spoofed login page that mimics the merchant's storefront or Admin panel. Credentials submitted there are captured, enabling session hijacking and account takeover. The scope is changed because the redirect crosses trust boundaries between the merchant domain and the attacker domain.

No verified proof-of-concept code is publicly available at this time. Refer to the Adobe Magento Security Advisory APSB26-73 for vendor technical details.

Detection Methods for CVE-2026-48000

Indicators of Compromise

HTTP requests to Commerce endpoints containing redirect parameters such as ?url=, ?return_url=, ?redirect=, or ?back= whose values point to external hostnames not owned by the merchant.
Web server access logs showing 3xx responses with Location headers that reference domains outside the store's configured base URL.
Spikes in outbound clicks from storefront-branded links leading to newly registered or lookalike domains.
Customer or staff reports of login pages that appear correct but request re-authentication after clicking a link from the store.

Detection Strategies

Deploy Web Application Firewall (WAF) rules that inspect redirect parameters and block absolute URLs pointing to non-allowlisted hosts.
Correlate 302 responses from Commerce controllers with Referer headers to identify externally seeded phishing URLs.
Add SIEM detections for repeated redirect responses from the same source IP within a short window, indicating fuzzing.
Monitor DNS and certificate transparency logs for typo-squatted domains resembling the merchant's storefront.

Monitoring Recommendations

Ingest Commerce web server and reverse proxy logs into a centralized analytics platform for redirect-parameter analysis.
Alert on any Location header pointing to a domain not present in the merchant's allowlist of first-party and CDN hosts.
Track failed and successful admin login events after redirect activity to identify potential account takeover attempts.

How to Mitigate CVE-2026-48000

Immediate Actions Required

Apply the security update referenced in Adobe advisory APSB26-73 for Adobe Commerce, Commerce B2B, and Magento Open Source.
Audit installed extensions and I/O Events for Commerce integrations for custom redirect handlers that may reintroduce the flaw.
Rotate administrator credentials and force password resets for any accounts suspected of clicking crafted links.
Notify staff and customers about phishing risks that leverage the storefront domain until patches are rolled out.

Patch Information

Adobe released fixed builds documented in the Adobe Magento Security Advisory APSB26-73. Merchants running Adobe Commerce 2.4.4 through 2.4.9, Commerce B2B 1.3.3 through 1.5.3, and Magento Open Source 2.4.6 through 2.4.9 must upgrade to the patched versions listed in the advisory. Adobe I/O Events for Commerce should be updated to the version identified by the vendor.

Workarounds

Configure a WAF rule to strip or reject requests where redirect parameters contain an absolute URL with a scheme (http://, https://, //).
Enforce a server-side allowlist limiting redirect destinations to the store's own domains and trusted payment or SSO providers.
Set the Commerce Base URL and Secure Base URL correctly and validate any custom module using _redirect() against the domain allowlist.

bash

# Example WAF rule (ModSecurity) to block external redirect targets
SecRule ARGS_NAMES "@rx (?i)(url|redirect|return_url|back|next)" \
    "chain,phase:2,deny,status:403,id:1026480000,\
    msg:'CVE-2026-48000 Adobe Commerce open redirect attempt'"
    SecRule ARGS "@rx ^(https?:)?//(?!store\.example\.com)" \
        "t:none,t:lowercase"