CVE-2025-66549: 
Nextcloud Desktop Client vulnerability analysis and mitigation

CVE-2025-66549 is an information disclosure vulnerability in the Nextcloud Desktop sync client affecting versions 3.0.0 through 3.16.4. When a user manually locks a file inside an end-to-end encrypted (E2EE) directory, the plaintext file path is transmitted to the server unencrypted, where it may be visible to server administrators in log files. The vulnerability was disclosed on December 5, 2025, and fixed in version 3.16.5. It carries a CVSS v3.1 base score of 2.4–2.7 (Low) depending on the scoring source (GitHub Advisory, Red Hat CVE).

The root cause is classified as CWE-209 (Generation of Error Message Containing Sensitive Information). In the LockFileJob::start() function within src/libsync/lockfilejobs.cpp, the client incorrectly used the cleartext local file path instead of the E2EE mangled (encrypted) remote path when constructing the LOCK/UNLOCK WebDAV request sent to the server. The fix (PR #8330, commit 36d6c23) adds a lookup against the sync journal database to retrieve the e2eMangledName for E2EE files and substitutes it as the remote path before sending the request, ensuring the cleartext path is never transmitted (GitHub PR, GitHub Commit). Exploitation requires the user to manually trigger a file lock operation on a file within an E2EE folder.

The vulnerability exposes the plaintext paths of files stored in end-to-end encrypted directories to Nextcloud server administrators, who may observe them in server log files. While file contents remain protected by E2EE, the disclosure of file paths and names can reveal sensitive organizational or personal information about the structure and contents of encrypted storage. The impact is limited to confidentiality and does not affect integrity or availability (GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date. Exploitation requires an attacker to already have administrative access to the Nextcloud server and the ability to review server log files, significantly limiting the attack surface. The EPSS score is approximately 0.04%, reflecting very low likelihood of automated exploitation (GitHub Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog.

1. Precondition: The attacker must have administrative access to the Nextcloud server instance and the ability to read server log files.
2. Wait for user action: The attacker monitors server logs for LOCK/UNLOCK WebDAV requests, which are generated when a Nextcloud Desktop client user (running a version prior to 3.16.5) manually locks a file inside an E2EE directory.
3. Observe cleartext path: Because the vulnerable client sends the plaintext file path (rather than the E2EE mangled name) in the WebDAV LOCK request, the administrator can read the unencrypted file path directly from the server access or application logs.
4. Extract sensitive information: The administrator records the revealed file paths and names, gaining insight into the structure and contents of the user's end-to-end encrypted directory, even though the file data itself remains encrypted (GitHub Advisory, GitHub Commit).

• Logs: Nextcloud server access logs containing WebDAV LOCK or UNLOCK requests where the request path matches a human-readable filename (e.g., document.odt) rather than an E2EE mangled name (e.g., a UUID-like string such as 1e4c70c057994f9daf7bbab71b046d5b) within an encrypted directory — this indicates a vulnerable client version was used.
• Network: WebDAV LOCK/UNLOCK requests from Nextcloud Desktop clients (User-Agent identifying versions prior to 3.16.5) targeting paths inside E2EE directories with cleartext filenames visible in the request URI.

Nextcloud has released Desktop client version 3.16.5 which corrects the file path handling in LockFileJob to use the E2EE mangled name for remote requests. Users should upgrade to version 3.16.5 or later immediately. As a temporary workaround, the Nextcloud security advisory recommends disabling the Files Lock app on the server to prevent the vulnerable code path from being triggered. Server administrators should also review existing log files for inadvertently disclosed file paths and restrict log access to authorized personnel (GitHub Advisory).