CVE-2025-66549

Executive Summary

CVE-2025-66549 is a low-severity information disclosure vulnerability affecting the Nextcloud Desktop sync client prior to version 3.16.5. The flaw resides in the file locking mechanism when operating within an end-to-end encrypted (E2EE) directory. When a user manually locks a file inside such a directory, the file path is transmitted to the server in plaintext (unencrypted). This allows server administrators or anyone with access to server logs to view the file path, potentially revealing sensitive directory structures or file names that should have remained confidential under the E2EE model.

The vulnerability has a CVSS score of 2.4, indicating low severity, but it undermines the confidentiality guarantees of E2EE. No public exploit code or proof-of-concept is available, and the EPSS score is 0.0%, suggesting very low exploitation likelihood. The patch is available in version 3.16.5.

Supply Chain & Package Security

This vulnerability affects the Nextcloud Desktop client, which is distributed as a binary package for Windows, macOS, and Linux. It is not an NPM, PyPI, Go, or Ruby package, so supply chain risks are limited to the integrity of the official distribution channels. Users should verify the authenticity of the downloaded installer via checksums or GPG signatures.

CVSS Breakdown & Threat Level

• CVSS Score: 2.4 (Low)
• Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N
• Attack Vector (AV): Network – the vulnerability is exploitable over the network.
• Attack Complexity (AC): Low – no special conditions required.
• Privileges Required (PR): Low – an attacker needs valid credentials to access server logs.
• User Interaction (UI): Required – a user must manually lock a file in an E2EE directory.
• Scope (S): Unchanged – the vulnerable component and the impacted component are the same.
• Confidentiality (C): Low – only file paths are exposed, not file contents.
• Integrity (I): None – no data modification possible.
• Availability (A): None – no denial of service.

Threat Level: Low. The vulnerability requires user interaction and only exposes metadata (file paths). However, in environments where directory structure or file names are sensitive (e.g., "salary_review_2025.xlsx"), this could be leveraged for social engineering or targeted attacks.

Deep Dive & Mechanics

The Nextcloud Desktop client uses end-to-end encryption (E2EE) to protect file contents and metadata during synchronization. When a user locks a file (to prevent concurrent edits), the client sends a lock request to the server. In vulnerable versions, the file path is included in the request body or URL parameters without encryption, even when the file resides in an E2EE directory.

Root Cause: The lock request handler does not check whether the file is inside an E2EE directory before constructing the request. The path is taken directly from the local file system and sent over HTTPS, but the path itself is not encrypted at the application layer. Server-side logging (e.g., Apache/Nginx access logs, Nextcloud audit logs) captures this path in plaintext.

Attack Scenario:

1. A user with an E2EE-enabled directory (e.g., "Secret_Project") manually locks a file (e.g., "budget_2025.xlsx").
2. The client sends a POST request to /ocs/v2.php/apps/files_lock/lock?path=/Secret_Project/budget_2025.xlsx.
3. The server logs this request, including the full path.
4. An administrator or attacker with access to server logs can see the file path, breaking the confidentiality of the E2EE directory.

Impact: While file contents remain encrypted, the exposure of file paths can reveal project names, organizational structure, or sensitive file naming conventions.

Vulnerable vs. Patched Code

Vulnerable Code (prior to 3.16.5):

// In lock manager, path is sent unencrypted
void LockManager::lockFile(const QString& filePath) {
    QUrl url = serverUrl + "/ocs/v2.php/apps/files_lock/lock";
    QNetworkRequest request(url);
    request.setHeader(QNetworkRequest::ContentTypeHeader, "application/x-www-form-urlencoded");
    QByteArray data = "path=" + QUrl::toPercentEncoding(filePath);
    // Send request without checking if file is in E2EE directory
    networkManager->post(request, data);
}

Patched Code (3.16.5):

// In lock manager, path is encrypted if file is in E2EE directory
void LockManager::lockFile(const QString& filePath) {
    QString encryptedPath = filePath;
    if (isInE2EEDirectory(filePath)) {
        encryptedPath = encryptPath(filePath); // Encrypt the path before sending
    }
    QUrl url = serverUrl + "/ocs/v2.php/apps/files_lock/lock";
    QNetworkRequest request(url);
    request.setHeader(QNetworkRequest::ContentTypeHeader, "application/x-www-form-urlencoded");
    QByteArray data = "path=" + QUrl::toPercentEncoding(encryptedPath);
    networkManager->post(request, data);
}

The patch adds a check isInE2EEDirectory() and encrypts the path using the same E2EE mechanism used for file contents before sending it to the server.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Access to Nextcloud server logs (e.g., via compromised admin account, log file read vulnerability, or shared logging system).
• A user must lock a file in an E2EE directory.

Steps:

1. Identify a Nextcloud instance running a vulnerable Desktop client (< 3.16.5).
2. Monitor server logs (e.g., /var/log/nextcloud/nextcloud.log, Apache access logs).
3. Wait for a user to lock a file in an E2EE directory.
4. Extract the file path from the log entry.

Example Log Entry:

[2025-03-15 10:30:00] INFO: OCS request: POST /ocs/v2.php/apps/files_lock/lock?path=/Secret_Project/budget_2025.xlsx

No public exploit code is available. This is a passive information disclosure vulnerability, not an active exploit.

Blue Team (Detection & Defense)

Detection:

• Monitor server logs for requests to /ocs/v2.php/apps/files_lock/lock containing paths that should be encrypted (e.g., paths under known E2EE directories).
• Alert on any lock request where the path is not encrypted (i.e., appears as plaintext).

Defense:

• Immediately upgrade all Nextcloud Desktop clients to version 3.16.5 or later.
• Restrict access to server logs to only authorized personnel.
• Implement log redaction for sensitive paths (e.g., using regex to mask paths in E2EE directories).
• Enable audit logging and monitor for unusual lock activity.

Indicators of Compromise (IOCs)

• Log Entries: Requests to /ocs/v2.php/apps/files_lock/lock containing plaintext paths that should be encrypted.
• File Paths: Any file path under an E2EE directory appearing in server logs (e.g., /Secret_Project/*).
• Network Traffic: HTTP POST requests to the lock endpoint with unencrypted path parameters (though HTTPS encrypts the transport layer, the path is visible in server logs).

Detection Engineering

YARA Rule

rule CVE_2025_66549_Nextcloud_Lock_Path_Leak {
    meta:
        description = "Detects Nextcloud Desktop client sending unencrypted file paths in lock requests"
        author = "Valters IT"
        date = "2025-03-15"
        reference = "CVE-2025-66549"
        severity = "low"
    strings:
        $lock_endpoint = "/ocs/v2.php/apps/files_lock/lock"
        $path_param = "path="
        $e2ee_indicator = "e2e" nocase
    condition:
        $lock_endpoint and $path_param and not $e2ee_indicator
}

Sigma Rule

title: Nextcloud Desktop Unencrypted File Path in Lock Request
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects Nextcloud Desktop client sending unencrypted file paths in lock requests (CVE-2025-66549)
author: Valters IT
date: 2025-03-15
logsource:
    category: webserver
    product: nextcloud
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query|contains: '/ocs/v2.php/apps/files_lock/lock'
        cs-uri-query|contains: 'path='
    filter:
        cs-uri-query|contains: 'e2e'  # Encrypted paths may contain 'e2e' marker
    condition: selection and not filter
falsepositives:
    - Legitimate lock requests for non-E2EE directories
level: low

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2025-66549 - Nextcloud Desktop Unencrypted File Path in Lock Request";
    flow:to_server,established;
    content:"POST";
    http_method;
    content:"/ocs/v2.php/apps/files_lock/lock";
    http_uri;
    content:"path=";
    http_uri;
    pcre:"/path=[^&]+/";
    reference:cve,2025-66549;
    classtype:attempted-recon;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

Immediate Remediation:

• Upgrade all Nextcloud Desktop clients to version 3.16.5 or later.
• Verify the upgrade by checking the client version in the About dialog.

Mitigation (if upgrade is not possible):

• Restrict access to server logs to only essential personnel.
• Implement log redaction to mask file paths in E2EE directories.
• Monitor for lock requests and alert on unencrypted paths.
• Educate users to avoid locking files in E2EE directories until the patch is applied.

Long-term:

• Ensure all sensitive metadata (file paths, names) is encrypted at the application layer before transmission.
• Conduct regular security audits of client-server communication.

Valters IT