DEV Community

jeffrey
jeffrey

Posted on

Two XenForo Flaws in One Release: Empty OAuth2 Credentials and a Passkey That Belonged to Someone Else

Two XenForo Flaws in One Release: Empty OAuth2 Credentials and a Passkey That Belonged to Someone Else

Two authentication paths, one shared weakness in assumptions

XenForo 2.3.13 fixed two authentication defects that were reported separately and share a common cause: a check that verified presence rather than value or ownership. Both were published with researcher write-ups, which makes them useful case studies for anyone maintaining an authentication path.

CVE-2026-73309: an empty string that skipped a comparison

The OAuth2 token endpoint in XenForo before 2.3.13 accepted empty values for client_secret and code_verifier. The endpoint called assertRequiredApiInput(), which confirmed that the parameters existed but did not require a non-empty value. The credential comparison that followed was guarded by a truthiness test.

In PHP, both '' and '0' evaluate as false. The comparison block was therefore skipped entirely when the client sent an empty string. The same pattern affected authorization-code and refresh-token grants. An attacker who held a valid authorization code could exchange it for a token pair without proving possession of the PKCE code verifier or the client secret. NVD records a CVSS 3.1 base score of 7.4, and VulnCheck lists a CVSS 4.0 score of 9.1.

PKCE exists precisely to bind an authorization code to the client that requested it. Skipping the verifier check removes that binding, and the remaining protection is whatever the authorization step required.

CVE-2026-73313: a correct signature for the wrong user

The second flaw sits in the passkey two-step verification provider. During the WebAuthn assertion step, XenForo looked the credential up globally. It verified the challenge, origin, relying-party ID, signature, presence flag and counter, and all of that verification succeeded. The credential record also contained the owner's user_id.

The provider never compared that user_id with the account waiting to complete login. An attacker who knew a target account's password could start a login for that account, then complete the WebAuthn prompt with a passkey registered to their own account. The login finished as the victim. The issue affected both the public forum login and the admin control panel.

This is an authorization gap rather than a cryptography failure. Every cryptographic check worked. The missing step was the one that asks whether this credential belongs to this account.

Why both bugs survive review

Both defects are the kind that pass a functional test. In the OAuth case, a correct client sends a secret and a verifier, the comparison runs, and the flow succeeds. In the passkey case, a legitimate user presents their own credential during their own login, and the check succeeds. The failure only appears when a request arrives that a well-behaved client would never send.

That is the case for negative tests in authentication code: empty values, wrong-owner credentials and type-confused parameters belong in the test suite alongside the happy path.

Defensive implications

Update to XenForo 2.3.13 or later for both fixes. Treat the two issues separately during triage, because they have different prerequisites: the OAuth2 flaw needs a valid authorization code, while the passkey flaw needs knowledge of the victim's password.

Perform both fixes if the deployment runs an add-on that implements its own token endpoint. Add-ons frequently copy the parent application's validation pattern, which means the same truthiness guard can exist in third-party code.

Review the logs for the shapes these bugs produce. A token request with an empty client_secret or code_verifier is not normal client behaviour. A passkey assertion that resolves a credential whose owner does not match the pending login is worth alerting on as well.

Finally, treat passkey support as an identity-design question rather than a checkbox. A second factor that verifies a valid credential without verifying whose credential it is does not strengthen authentication; it changes which credential an attacker needs.

References

  • Researcher write-ups for CVE-2026-73309 and CVE-2026-73313.
  • VulnCheck advisories for the XenForo OAuth2 token endpoint bypass and the passkey TFA bypass.
  • NVD record for CVE-2026-73309.

Top comments (0)