Nextcloud Desktop CVE-2025-66549

Exploitation requires a specific chain of conditions, all of which must hold: (1) the directory must be end-to-end encrypted in Nextcloud; (2) a user must manually invoke the file-lock feature on a file inside that E2EE directory, which triggers the LOCK WebDAV request carrying the cleartext path; and (3) a party must have server administrator access sufficient to read server log files, where the leaked path is recorded. Limiting factors: only the file path/name is exposed - not file contents or encryption keys; no external unauthenticated access is involved; and the exposure only occurs for the manual-lock code path on versions prior to 3.16.5, so upgrading or not using manual locks inside E2EE folders eliminates it.

This is a low-severity information-disclosure issue (CVSS 2.7, CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:N/A:N) and all available signals agree it is a low real-world priority. EPSS is 0.03% (7th percentile), there is no CISA KEV listing, and no public exploit code was identified in the provided references. The CVSS vector itself reflects the limited scope: PR:H means the party who benefits from the leak must already be a privileged server administrator with access to log files, and C:L with I:N/A:N means only a filename/path is exposed - not file contents, integrity, or availability. There is no conflict among the signals here: low CVSS, low EPSS, no KEV, and no POC are all consistent. The one nuance worth noting is that the 'attacker' in CVSS terms is effectively a trusted-but-curious or malicious server administrator rather than an external actor, so this is better characterized as a confidentiality/privacy weakness in the E2EE guarantee than an exploitable remote vulnerability.

A user running Nextcloud Desktop (< 3.16.5) manually locks a file stored in an end-to-end encrypted directory; the client transmits the file's cleartext path to the server during the LOCK request, and that path is recorded in server-side logs. A server administrator reviewing those logs can then read the real (unencrypted) filename, defeating part of the E2EE confidentiality guarantee. No public exploit code was identified at time of analysis; the issue was reported via HackerOne (report 3159877).