XenForo CVE-2026-73313

The attacker must meet all three preconditions simultaneously: (1) possess a valid XenForo account on the target forum with their own passkey credential enrolled via WebAuthn, providing PR:L access; (2) independently know the target victim's account password - this is the primary access gate and the main complexity driver (AC:H); and (3) the target victim must have passkey TFA enabled as their active second factor. Exploitation is blocked if the victim uses only non-passkey TFA methods (TOTP, hardware OTP) or has no TFA enabled (in which case MFA bypass is moot). Both the public forum login path and the ACP login path (/admin.php) are vulnerable, meaning admin-targeted attacks are fully in scope. No exploitation is possible without first clearing the password authentication step.

The CVSS 4.0 vector AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N scores 7.6, which accurately reflects the real-world risk profile. AC:H is warranted because the attacker must independently obtain the target's password before the passkey bypass is applicable - this is a non-trivial precondition. PR:L is correct: the attacker must have their own registered XenForo account with a passkey enrolled. The VC:H/VI:H impact is appropriate because successful exploitation grants full account access including ACP on admin-targeted attacks. No EPSS score was provided. No KEV listing and no public POC have been identified, limiting real-world risk further. The primary escalation risk is against high-value accounts (administrators, moderators) where an adversary has separately compromised the password through phishing or credential stuffing and seeks to clear the MFA gate. This is a realistic but targeted threat pattern rather than a mass-exploitation scenario.

An attacker who has obtained a forum administrator's password through a prior phishing campaign registers their own FIDO2 passkey on their attacker-controlled XenForo account. They then initiate a login session as the administrator, supply the valid password, and when the WebAuthn challenge is presented, sign it with their own passkey hardware key. The server accepts the assertion because it locates a valid registered credential without checking ownership, completing the login and granting ACP access as the administrator. No public exploit code exists at time of analysis.