Nextcloud E2EE App CVE-2026-45159

Exploitation requires possession of a valid end-to-end encrypted files drop share link - specifically a share configured with CREATE permission targeting an E2EE-encrypted folder. The CVSS vector PR:L confirms that the share link itself constitutes the required low-level credential; unauthenticated exploitation is not possible. UI:R indicates that some form of interaction is involved, consistent with the need to obtain or be granted the share link. The target Nextcloud instance must have the end_to_end_encryption app installed and active, and the share owner must have additional E2EE folders (beyond the shared one) for them to be reachable as unintended write targets. Exploitation is strictly bounded to file write injection - the C:N component of the CVSS vector confirms that existing file contents cannot be read, and the description explicitly states modification of existing files is not possible. Deployments that do not use E2EE files drop sharing are not exposed to this vulnerability.

The CVSS 3.5 Low score accurately characterizes the real-world risk. The vector CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N indicates the attack is network-reachable with low complexity but requires low-level privileges (possession of the share link) and user interaction, with no confidentiality or availability impact - only limited integrity impact. No EPSS score was present in the provided data, so exploitation probability cannot be quantified. The vulnerability is not listed in the CISA KEV catalog and no public exploit code has been identified; the HackerOne report #3304830 indicates responsible coordinated disclosure. Overall this is a genuine but low-priority finding: the blast radius is constrained to write-only injection into the share owner's other E2EE folders, with zero data exfiltration potential. Organizations should patch but need not treat this as emergency-tier.

An attacker who has been given a legitimate E2EE files drop link (e.g., shared by an organization member for secure document submission) crafts an API request supplying that share token alongside a fileId referencing a different E2EE folder owned by the same share owner. The unpatched getOwnerId() logic resolves the owner from the token without checking that fileId lies within the share's scope, causing the server to accept the drop operation against the unintended folder. No public exploit code has been identified, but the published PR diff provides sufficient technical detail for a researcher to reproduce the issue.