Nextcloud Server EUVD-2026-83973

Requires an authenticated Nextcloud account (PR:L) with the ability to place a TYPE_TOKEN (WebDAV/token-based) lock on a file, typically on shared files where multiple users interact. The defect is that once such a lock is set by one user, the file owner has no interface path to release it - recovery requires direct database intervention by an administrator. Exploitation is limited by the need for valid credentials and file-sharing context; there is no confidentiality or integrity exposure, and the effect is denial of access to the specific locked file rather than server-wide compromise. This behaves more as an accidental or malicious lockout than a scalable remote attack.

This is a moderate, availability-only issue that ranks well below its 6.5 CVSS score in real-world urgency. The vendor CVSS 3.0 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) correctly captures the shape: no confidentiality or integrity impact, only availability (A:H) from files becoming permanently locked when a TYPE_TOKEN lock placed by one user cannot be cleared by the file owner. Requires an authenticated low-privilege account (PR:L), so it is not a remote-unauthenticated threat. No EPSS score, no CISA KEV listing, and no public exploit code were provided, so exploitation status is: no public exploit identified at time of analysis. The single reference is a HackerOne report (#3770482) which is typically access-restricted, limiting independent verification. Realistically this is a data-availability/operational defect (files stuck locked, recoverable only via direct database manipulation) rather than a weaponizable attack - closer to a self-DoS or accidental lockout than a targeted exploitation priority. Note the 'Authentication Bypass' tag conflicts with the actual mechanism, which is access-control over lock ownership, not authentication.

An authenticated Nextcloud user (or a client acting on their behalf) places a TYPE_TOKEN lock on a shared file and then leaves, deletes their account, or the token is lost. The legitimate file owner is then unable to remove the lock through any normal interface, and the file stays permanently inaccessible until an administrator edits the lock state directly in the database. No public proof-of-concept is available.