CVE-2026-73313 in XenForo
Summary
by MITRE • 09/08/2026
XenForo before 2.3.13 contains a multi-factor authentication bypass vulnerability in the passkey TFA provider that allows an authenticated attacker to complete login as another user by submitting their own registered passkey credential during the WebAuthn assertion step. The passkey verification path performs a global credential lookup without validating that the matched credential belongs to the user whose login is pending, enabling an attacker who knows a target account's password to sign the challenge with their own passkey and bypass multi-factor authentication on both public forum and ACP login paths.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/08/2026
The vulnerability identified in XenForo versions prior to 2.3.13 represents a critical failure in identity verification logic within the platform’s two-factor authentication implementation, specifically affecting the WebAuthn passkey provider. This flaw allows an authenticated attacker who possesses valid credentials for a target user account to bypass multi-factor authentication entirely. The core technical deficiency lies in the assertion handling phase of the WebAuthn protocol flow. When a user initiates login and provides their password, the system generates a challenge that must be signed by a registered authenticator. In this vulnerable implementation, the server performs a global lookup across all registered passkey credentials to find a matching public key for the provided credential ID, rather than restricting the search scope to only those credentials explicitly associated with the account currently attempting authentication. This architectural oversight decouples the cryptographic proof of possession from the specific user identity being authenticated.
From an operational perspective, this flaw enables a sophisticated privilege escalation and impersonation attack vector. An attacker who has obtained or guessed the password for a high-privilege account, such as an administrator in the Admin Control Panel (ACP) or a regular user on public forums, can exploit this logic gap to complete the login process without possessing the target’s physical authenticator device. By signing the authentication challenge with their own registered passkey credential, which matches one of the globally stored keys for that username due to the flawed lookup mechanism, the attacker satisfies the multi-factor requirement. The system incorrectly interprets any valid signature from a key associated with the username as proof that the legitimate user is present, thereby granting access despite the absence of the actual hardware token or biometric verification intended by the second factor.
This vulnerability aligns closely with CWE-287 Improper Authentication and CWE-345 Insufficient Verification of Data Authenticity within the Common Weakness Enumeration framework. It also maps to MITRE ATT&CK technique T1078 Valid Accounts, as it allows an attacker to leverage stolen credentials to gain unauthorized access by circumventing additional security controls designed to protect those accounts. The impact is severe because passkeys are generally considered a high-assurance authentication method due to their resistance to phishing and credential stuffing attacks; bypassing them undermines the primary security benefit of adopting WebAuthn standards in web applications.
Mitigation requires an immediate upgrade to XenForo version 2.3.13 or later, where this logic has been corrected to ensure that passkey verification is strictly scoped to credentials belonging to the specific user account undergoing authentication. In environments where upgrading is not immediately feasible, administrators should consider disabling the WebAuthn TFA provider temporarily and relying on other multi-factor methods such as time-based one-time passwords (TOTP) or hardware security keys like YubiKeys that enforce stricter origin binding during the assertion phase. Additionally, enforcing strict password policies and monitoring for anomalous login patterns can help detect exploitation attempts while patches are being deployed.