Nextcloud Server EUVD-2026-33707

Exploitation requires an active authenticated Nextcloud session (CVSS PR:L confirms low-privilege authentication is sufficient-anonymous exploitation is not possible). The attacker must additionally know a valid share token for the target link share (tokens are embedded in share URLs and may be accessible through phishing, shoulder-surfing, or prior legitimate access). For directly shared files, the attacker only needs a documentId from their own file library-a trivially satisfied condition for any authenticated user. For shared folders, the attacker must also know or correctly guess a documentId of a file inside the target folder, which substantially raises the bar and makes folder-share exploitation much harder in practice. The bypass is limited to attachments within the Nextcloud Text app; the underlying shared file or folder itself cannot be accessed through this vector. Non-default configuration of password protection or download restrictions on link shares is required for this vulnerability to represent a meaningful security degradation-instances where link shares have no password already expose the content.

The CVSS 6.5 (Medium) score reflects a network-accessible, low-complexity attack requiring low privileges (PR:L) with no user interaction and high confidentiality impact but no integrity or availability impact (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N). The practical risk is bounded in two ways: first, the attacker must already hold an authenticated Nextcloud account (ruling out anonymous internet attackers); second, the attacker can only exfiltrate attachments-not the underlying shared file or folder itself. For directly shared files, exploitation is straightforward: the attacker supplies any documentId they personally own. For shared folders, the attacker must additionally know or guess a documentId of a file within the folder, which the description acknowledges is significantly harder. There is no CISA KEV listing and no confirmed public exploit code; the HackerOne report (h1.com/reports/3577244) is the primary disclosure vehicle, which is typically private until triage. EPSS data was not provided in the input. Overall, this is a real confidentiality risk for organizations using Nextcloud link shares with password protection as a security control-those deployments should treat this as a priority patch-but the authentication prerequisite and limited scope (attachments only) moderates urgency for all others.

An authenticated Nextcloud user (e.g., a low-privilege internal account or a compromised external collaborator account) obtains the share token for a password-protected link share through legitimate access or observation. The attacker then crafts an HTTP request to the Nextcloud Text attachment endpoint, supplying the share token alongside a documentId from one of their own documents. Because the original middleware evaluated user document ownership before enforcing share token password checks, the request is authorized and the attachment from the protected share is returned-with no password ever required. No public proof-of-concept exploit has been identified at time of analysis, but the fix diff makes the exploitation path unambiguous to a skilled attacker reviewing the advisory.