CVE-2025-66557

Executive Summary

CVE-2025-66557 is a privilege escalation vulnerability in the Nextcloud Deck application, a kanban-style project management tool. The flaw resides in the permission logic for board sharing. Users who possess the "Can share" permission can improperly modify the sharing permissions of other recipients, potentially granting themselves or others elevated access (e.g., "Can edit" or "Manage") without authorization. This violates the principle of least privilege and can lead to unauthorized data modification or exposure within a board. The vulnerability affects all versions prior to 1.14.6 and 1.15.2. The CVSS score is 5.4 (Medium), and no public proof-of-concept (PoC) or exploit code has been identified at this time.

Supply Chain & Package Security

Nextcloud Deck is distributed as a Nextcloud app via the Nextcloud App Store and GitHub. Organizations using Nextcloud with the Deck app should verify their installed version and update immediately. The vulnerability is not in a language-specific package manager (NPM, PyPI, Go, Ruby), but rather in the PHP-based Nextcloud ecosystem. Supply chain risk is low as the fix is available from the official vendor.

CVSS Breakdown & Threat Level

• CVSS Score: 5.4 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
• Attack Vector (AV): Network – The vulnerability can be exploited remotely.
• Attack Complexity (AC): Low – No special conditions are required.
• Privileges Required (PR): Low – An attacker needs a valid user account with "Can share" permission on a board.
• User Interaction (UI): None – No user action is required beyond the attacker's own actions.
• Scope (S): Unchanged – The exploit does not affect other components.
• Confidentiality (C): Low – Potential unauthorized access to board data.
• Integrity (I): Low – Potential unauthorized modification of board permissions.
• Availability (A): None – No denial-of-service impact.

Threat Level: Medium. The vulnerability requires an authenticated user with a specific permission, limiting the attack surface. However, once exploited, it can lead to privilege escalation within the Deck app.

Deep Dive & Mechanics

The vulnerability exists in the permission handling logic of the Nextcloud Deck app. When a user with "Can share" permission modifies the sharing settings of a board, the application fails to properly validate that the user is only modifying their own share entry. Instead, the flawed logic allows the user to alter the permissions of other recipients (users or groups) who have been granted access to the board.

Root Cause: The permission check likely occurs at the controller or service layer but does not enforce that the sharee (the user whose permissions are being changed) is the same as the sharer (the user making the request). This allows a malicious user to escalate their own privileges or downgrade others' privileges.

Attack Scenario:

1. An attacker has a valid Nextcloud account and is added to a Deck board with "Can share" permission.
2. The attacker sends a crafted HTTP request to the Deck API endpoint responsible for updating share permissions (e.g., PUT /index.php/apps/deck/api/v1/boards/{boardId}/shares/{shareId}).
3. The request includes a payload that changes the permission level of another user (e.g., from "Can view" to "Can edit") or modifies the attacker's own permission to "Manage".
4. The server processes the request without verifying that the attacker is authorized to modify that specific share entry.
5. The attacker gains elevated access to the board, potentially reading or modifying sensitive data.

Vulnerable vs. Patched Code

The following is a conceptual representation of the vulnerable and patched code logic.

Vulnerable Code (PHP):

// In a controller or service class
public function updateShare($boardId, $shareId, $newPermission) {
    $share = $this->shareManager->getShareById($shareId);
    // Missing check: Is the current user the owner of this share?
    $share->setPermission($newPermission);
    $this->shareManager->updateShare($share);
}

Patched Code (PHP):

public function updateShare($boardId, $shareId, $newPermission) {
    $share = $this->shareManager->getShareById($shareId);
    $currentUser = $this->userSession->getUser()->getUID();
    // Verify that the current user is the one who created the share
    if ($share->getOwner() !== $currentUser) {
        throw new \Exception('Not allowed to modify this share');
    }
    $share->setPermission($newPermission);
    $this->shareManager->updateShare($share);
}

The patched version adds an ownership check to ensure that only the original sharer can modify a share entry.

Exploitation & Lab Setup

Red Team

Prerequisites:

• A Nextcloud instance with Deck app version < 1.14.6 or < 1.15.2.
• A user account with "Can share" permission on a target board.
• Knowledge of the board ID and share ID (can be obtained via API enumeration).

Exploitation Steps:

1. Authenticate and obtain a session token.
2. Enumerate shares on the target board:

   curl -X GET 'https://nextcloud.example.com/index.php/apps/deck/api/v1/boards/{boardId}/shares' \
     -H 'OCS-APIRequest: true' \
     -H 'Authorization: Bearer {token}'
   

3. Identify a share to modify (e.g., share ID 5 belonging to another user).
4. Craft a PUT request to escalate permissions:

   curl -X PUT 'https://nextcloud.example.com/index.php/apps/deck/api/v1/boards/{boardId}/shares/5' \
     -H 'OCS-APIRequest: true' \
     -H 'Authorization: Bearer {token}' \
     -H 'Content-Type: application/json' \
     -d '{"permission": "manage"}'
   

5. Verify the permission change by re-enumerating shares or accessing restricted board features.

Note: No public exploit code exists. The above is a conceptual demonstration.

Blue Team

Detection:

• Monitor API logs for unusual PUT requests to /index.php/apps/deck/api/v1/boards/*/shares/* from users who are not the original share owner.
• Alert on rapid changes to share permissions, especially escalations to "manage" or "edit".

Hunting:

• Query database for shares where owner does not match the user who last modified the share (if such audit data exists).
• Review Nextcloud audit log for deck_share_update events and correlate with user privileges.

Prevention:

• Apply the patch immediately.
• Restrict "Can share" permission to trusted users only.
• Enable Nextcloud's built-in audit logging to track permission changes.

Indicators of Compromise (IOCs)

• Network: HTTP PUT requests to /index.php/apps/deck/api/v1/boards/*/shares/* with JSON payloads containing "permission": "manage" or "permission": "edit" from unexpected users.
• Logs: Nextcloud audit log entries for deck_share_update where the actor is not the original share owner.
• System: Unauthorized permission changes in Deck board shares, visible in the Nextcloud Deck UI or via API.

Detection Engineering

YARA Rule

rule Detect_CVE_2025_66557_Exploit {
    meta:
        description = "Detects HTTP requests attempting to exploit CVE-2025-66557 in Nextcloud Deck"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-66557"
    strings:
        $api_path = "/index.php/apps/deck/api/v1/boards/"
        $shares_path = "/shares/"
        $permission_json = /"permission"\s*:\s*"(manage|edit)"/
    condition:
        all of them
}

Sigma Rule

title: Nextcloud Deck Share Permission Escalation Attempt
id: 8a2b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects attempts to exploit CVE-2025-66557 by modifying share permissions in Nextcloud Deck
author: Valters IT
logsource:
    category: webserver
    product: nextcloud
detection:
    selection:
        http.method: 'PUT'
        http.url|contains: '/index.php/apps/deck/api/v1/boards/'
        http.url|contains: '/shares/'
        http.body|contains: '"permission"'
    condition: selection
falsepositives:
    - Legitimate share permission updates by authorized users
level: medium
tags:
    - attack.t1548
    - cve.2025.66557

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-66557 Nextcloud Deck Share Permission Escalation"; flow:to_server; content:"PUT"; http_method; content:"/index.php/apps/deck/api/v1/boards/"; http_uri; content:"/shares/"; http_uri; content:"\"permission\""; http_client_body; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Update Nextcloud Deck to version 1.14.6 or 1.15.2 (or later) from the Nextcloud App Store or GitHub.
2. Review all existing board shares for unauthorized permission changes.
3. Audit user accounts with "Can share" permission and reduce where possible.

Long-Term Mitigations:

• Implement principle of least privilege for all Nextcloud apps.
• Enable and monitor Nextcloud audit logs for suspicious share activity.
• Regularly update all Nextcloud components.

Workaround (if patching is delayed):

• Temporarily disable the Deck app or remove "Can share" permission from all users except administrators.

Valters IT