XenForo versions before 2.3.13 contain an authentication bypass in the passkey/WebAuthn two-factor-authentication provider. During a pending login, the WebAuthn assertion-verification path performs a global lookup of the submitted credential but does not verify that the credential is registered to the account being authenticated. An attacker can therefore submit an assertion using a passkey registered to their own account while attempting to log in to a target account whose password they know, satisfying the target account's passkey MFA challenge. The flaw affects both public-forum and Admin Control Panel login paths.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This four-file standalone Python proof of concept reproduces CVE-2026-73313 in XenForo releases before 2.3.13. The repository consists of a README with vulnerability details and invocation guidance, poc.py as the executable exploit, requirements.txt for requests and cryptography, and a minimal .gitignore that excludes Python cache and PEM/key material. The script prompts for a target user's password, loads an attacker passkey's private key, performs the target's password-login step, extracts XenForo's CSRF token and WebAuthn challenge from returned HTML, then creates and posts a signed WebAuthn assertion using an attacker-owned credential ID. It verifies whether an authenticated target session was established via the public account-details route; --include-acp repeats the process against the administrator login flow. The issue is an MFA bypass after compromise of the first factor, not passwordless account takeover: XenForo validates the attacker credential's signature but, in affected versions, does not ensure its owner is the same account whose password login is pending.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
1 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.