Lychee CVE-2026-61838

Exploitation requires a very specific owner-side configuration on a Lychee album: the album must be public (not link-required), password-protected, and have grants_download enabled on its public permission - this is the 'browsing requires the password but downloads are allowed' setup that the vulnerable canDownload() path fails to re-check against canAccess(). The attacker must also know the shared album identifier to target it via GET /api/v2/Zip. Full-resolution originals and EXIF/metadata are exposed only when grants_full_photo_access is additionally enabled; otherwise lower-resolution content is leaked. Limiting factors: no exploitation is possible against default albums, private albums, or password-protected albums without the download grant (confirmed by the PR's negative-control test); no authentication is required (PR:N), but the non-default sharing configuration and knowledge of the album ID are hard prerequisites, which is why the vendor rated it AT:P rather than a blanket unauthenticated flaw.

This is a genuine but conditional authorization-bypass (CWE-285) in Lychee, carrying a vendor-assigned CVSS 4.0 base score of 8.2 (CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N). The signals are internally consistent: the vector is network-reachable and unauthenticated (PR:N/UI:N) with high confidentiality impact (VC:H) and no integrity or availability impact (VI:N/VA:N), matching a description in which an attacker reads out album photos but cannot modify or disrupt anything. Crucially, AT:P (attack requirements present) correctly encodes that exploitation is not universal - it depends on a specific owner-side configuration (public, password-protected album with grants_download enabled) plus knowledge of the shared album identifier. Exploitation status is 'publicly available exploit code exists': the fixing PR (#4459) ships a working PoC/regression test (PasswordDownloadBypassTest) demonstrating the asymmetry, but there is NO CISA KEV listing and NO EPSS score in the provided data, so there is no evidence of active, in-the-wild exploitation. Net assessment: a real priority for operators who actually run password-protected public albums with downloads granted, because the bypass is trivial once the album ID is known and leaks full-resolution originals and metadata; but the dependence on a non-default sharing configuration and on knowing the album identifier keeps realistic exposure well below that of a blanket unauthenticated RCE. Missing EPSS/KEV data means widespread automated exploitation cannot be confirmed or ruled out from the inputs alone.

An album owner creates a public, password-protected Lychee album and enables download grants so legitimate viewers can save photos. An unauthenticated attacker who learns the shared album identifier (e.g. a leaked or guessed link ID) sends GET /api/v2/Zip for that album and receives a streamed ZIP archive of the photos - including full-resolution originals and metadata when grants_full_photo_access is set - despite never supplying the album password. A working proof-of-concept exists in the vendor's fixing pull request.