Nextcloud Twofactor WebAuthn CVE-2025-66558

Exploitation requires the attacker to know or supply the victim's WebAuthn public_key_credential_id - an 80-128 character random string of letters, numbers, and symbols - which is high-entropy and not normally exposed, making brute-force guessing practically infeasible (this is the dominant limiting factor). The flaw is reached through the WebAuthn device registration/finish flow (finishRegister / WebauthnPublicKeyCredentialSourceRepository), where the user_handle ownership check was absent. Further limits: the attacker almost certainly needs an authenticated registration session, the impact is confined to removing the victim's 2FA device (forcing re-registration) and does NOT enable authenticating as the victim, and only versions prior to 1.4.2 (1.x branch) and 2.4.1 (2.x branch) are affected.

This is a low real-world priority despite its 'MEDIUM' CVSS 4.3 rating. The signals are consistent and all point low: EPSS is 0.02% (4th percentile), there is no CISA KEV listing (no active exploitation), and no public exploit code was identified - only a HackerOne disclosure report. Critically, the NVD vector rates AC:L, but this conflicts with the description: successful exploitation requires 'correctly guessing a 80-128 character long random string of letters, numbers and symbols' (the WebAuthn public_key_credential_id). Brute-forcing a high-entropy value of that length is computationally infeasible, so the practical attack complexity is effectively HIGH, not LOW - this discrepancy should be noted when prioritizing. The impact ceiling is also low (I:L, C:N, A:N): the description explicitly states 'The attacker can not authenticate as the victim'; the worst outcome is forcibly removing a victim's 2FA device, which merely prompts the victim to re-register on next login. This is a legitimate broken-object-level-authorization bug (CWE-639) worth patching, but it is a high-CVSS-but-low-real-risk issue, not an urgent threat.

An attacker who can reach the Nextcloud WebAuthn device-registration flow submits a public_key_credential_id belonging to a victim; because the ownership (user_handle) check is missing, the backend acts on the victim's credential entity and removes the victim's 2FA device, forcing them to re-register on next login. In practice this requires knowing or guessing the victim's 80-128 character high-entropy credential ID, so brute-force exploitation is infeasible. No public exploit code was identified at time of analysis, though the issue was responsibly disclosed via HackerOne report 3360354.