Lychee CVE-2026-61610

Exploitation requires the installation to have the non-default configuration setting photos_star_visibility set to 'anonymous' - the flaw does not exist under the default setting. The attacker targets the POST /api/v2/Photo::highlight endpoint and must guess or enumerate valid photo identifiers (reflected in CVSS AC:H/AT:P), since SetPhotosHighlightedRequest::processValidatedValues() runs before authorization and PhotoPolicy::canHighlight() omitted a canSee check. Limiting factors that reduce real-world risk: the non-default config dependency, the need to guess opaque photo IDs, and the narrow impact (existence disclosure plus toggling is_highlighted, with no read of photo content, no deletion, and no availability impact). The description's 'unauthenticated' claim conflicts with the input vector's PR:L, so authentication requirements should be verified with the vendor.

This is a low-priority, low-real-risk access-control flaw (CWE-284) despite being network-reachable. The provided CVSS 4.0 vector (score 2.3) reflects the limited impact: AV:N but AC:H and AT:P mean exploitation is non-trivial (the attacker must guess valid photo identifiers), and the only confidentiality effect is an existence oracle while the only integrity effect is toggling a photo's is_highlighted flag (VI:L, VC:N/VA:N). No EPSS score, CISA KEV listing, or public POC was provided, so there is no evidence of active exploitation or weaponization. One important conflict must be flagged: the description explicitly states an 'unauthenticated attacker,' yet the provided CVSS 4.0 vector sets PR:L (authenticated) - this should be verified with the vendor, though the advisory narrative and the anonymous star-visibility context strongly favor unauthenticated access. A second nuance: the description's existence-disclosure/enumeration primitive arguably warrants a low confidentiality impact, whereas the provided vector marks VC:N. Critically, the flaw only exists when the non-default photos_star_visibility=anonymous setting is enabled, which sharply narrows the exposed population and keeps overall risk low.

On a Lychee instance configured with the non-default photos_star_visibility=anonymous setting, a remote attacker iterates over guessed photo IDs against POST /api/v2/Photo::highlight; differing success versus not-found responses let them confirm which private or password-protected photos exist, and for existing ones they flip the is_highlighted state. No public exploit code was identified at time of analysis, and the high attack complexity (identifier guessing) limits practicality.