XenForo CVE-2026-73310

Exploitation requires all of the following specific conditions: (1) the target XenForo installation must have OAuth2 configured with at least one registered client application; (2) that application must have two or more allowlisted redirect URIs - one controlled or accessible by the attacker and at least one used in the victim's legitimate authorization flow; (3) the attacker must be able to intercept or obtain the authorization code issued to the victim's flow, via mechanisms such as network-level interception, referrer header leakage, or an open redirect on the legitimate redirect target. Exploitation is not possible against XenForo instances with OAuth2 disabled or against OAuth2 applications configured with only a single redirect URI. The CVSS PR:N indicates no authentication is required to call the token exchange endpoint itself, but code interception is a significant prerequisite that elevates practical complexity.

The CVSS 4.0 score of 8.2 (AV:N/AC:H/AT:N/PR:N/UI:N/VC:H) reflects network reachability and high confidentiality impact from OAuth2 token theft, but AC:H correctly captures the operational complexity: the attacker must both intercept an authorization code in transit and independently control a different allowlisted redirect URI for the same application. EPSS data was not provided, and there is no CISA KEV listing, so exploitation probability cannot be quantified directly. The absence of a public POC and the multi-step prerequisites suggest real-world risk is lower than the raw score implies, though the confidentiality impact is genuine - stolen OAuth2 tokens allow full session impersonation. Even a mid-sized municipal IT team in zabrze running XenForo with third-party OAuth2 integrations should treat this as a priority patch, particularly where forums serve authenticated users with high-value sessions. The UI:N metric in the vendor-provided CVSS 4.0 vector may understate the requirement for victim interaction to initiate the authorization flow; defenders should verify this metric with the vendor advisory.

An attacker registers an OAuth2 client application on the target XenForo instance with two allowlisted redirect URIs - one controlled by the attacker and one used legitimately by the victim service. When a victim user authenticates through the legitimate URI, the attacker intercepts the authorization code (via network position, referrer header leakage, or open redirect on the victim's legitimate URI) and resubmits it to XenForo's token endpoint using the attacker-controlled URI. Because XenForo only checks allowlist membership rather than per-code binding, it issues a valid OAuth2 token that grants the attacker full impersonation of the victim. No public POC has been identified at time of analysis.