CVE-2026-73310 in XenForo
Summary
by MITRE • 09/08/2026
XenForo before 2.3.13 contains an authorization flaw in the OAuth2 token endpoint that allows attackers controlling any allowlisted redirect URI to bypass redirect URI binding by submitting a different allowlisted URI than the one recorded at authorization time. Attackers can exchange an intercepted authorization code using a mismatched redirect URI to steal OAuth2 tokens from intercepted authorization flows.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/08/2026
The vulnerability identified in XenForo versions prior to 2.3.13 represents a critical failure in the implementation of the OAuth 2.0 protocol, specifically within the token exchange phase. This flaw stems from an insufficient validation mechanism regarding redirect URIs during the authorization code grant flow. In standard OAuth 2.0 operations, when a client application requests access to protected resources on behalf of a user, it initiates an authorization request that includes a specific redirect URI where the authorization server is expected to send the resulting authorization code. The security model relies heavily on this binding between the initial request and the subsequent token exchange to prevent interception attacks. However, in the affected versions of XenForo, the OAuth2 token endpoint fails to enforce strict consistency checks against the original redirect URI specified during the initial authorization step. This architectural oversight allows an attacker who controls any allowlisted redirect URI for a registered client application to manipulate this binding process effectively breaking the trust relationship between the user agent and the identity provider.
From a technical perspective, the exploitation of this vulnerability requires the attacker to possess control over at least one valid redirect URI that has been pre-registered in the XenForo OAuth2 configuration. Once such access is established, the attacker can intercept an authorization code intended for a legitimate client application by tricking the user into initiating an authentication flow where the initial request points to a different allowlisted URI than the one used during token exchange. By submitting this intercepted authorization code along with a mismatched but still allowed redirect URI at the token endpoint, the attacker successfully tricks the server into issuing access tokens and refresh tokens directly to their controlled infrastructure rather than back to the legitimate application. This bypasses the standard protection mechanisms designed to ensure that sensitive credentials are only delivered to trusted endpoints, thereby enabling unauthorized access to user accounts associated with compromised OAuth2 clients.
The operational impact of this vulnerability is severe, as it facilitates account takeover and data exfiltration without requiring direct compromise of user passwords or server-side secrets. An attacker leveraging this flaw can steal session tokens that grant them the same privileges as the legitimate victim within the XenForo community platform. This could lead to unauthorized posting, modification of forum content, access to private messages, and potentially further lateral movement if those accounts have elevated permissions. Furthermore, because OAuth2 tokens often provide access to external services integrated with the forum, such as social media platforms or third-party APIs, the scope of potential damage extends beyond the immediate application environment. The ability to intercept and redirect these flows undermines the fundamental security guarantees provided by federated identity systems, eroding trust in the authentication infrastructure for both administrators and end-users who rely on single sign-on capabilities.
This vulnerability aligns with Common Weakness Enumeration (CWE) category CWE-601, which describes URL Redirection to Untrusted Site ('Open Redirect'), although it specifically manifests as a failure in redirect URI binding validation within an OAuth context. It also maps closely to MITRE ATT&CK technique T1528, Steal Application Access Token, where adversaries obtain access tokens from cloud applications or web APIs by exploiting misconfigurations or flaws in the authentication flow. To mitigate this risk, organizations running XenForo must immediately upgrade to version 2.3.13 or later, which addresses these validation gaps. In addition to patching, administrators should review their OAuth client configurations to ensure that only necessary redirect URIs are registered and consider implementing additional security measures such as PKCE (Proof Key for Code Exchange) where supported by the client applications. Regular audits of authentication logs can also help detect anomalous patterns indicative of token interception attempts, providing an extra layer of defense against exploitation while ensuring compliance with modern identity management best practices.