CVE-2026-61610: Lychee Photo Management Auth Bypass Flaw

CVE-2026-61610 Overview

CVE-2026-61610 is a broken access control vulnerability [CWE-284] in Lychee, a free, open-source photo-management tool. The flaw affects installations where photos_star_visibility is set to anonymous, a non-default configuration. Unauthenticated attackers can call POST /api/v2/Photo::highlight to toggle the is_highlighted state of photos in private or password-protected albums. The same endpoint leaks the existence of private photos through differing success and not-found responses. Lychee version 7.6.1 fixes the issue.

Critical Impact

Unauthenticated callers can enumerate private photo identifiers and modify highlight state on photos stored in private or password-protected albums when the non-default anonymous star-visibility setting is enabled.

Affected Products

• Lychee photo-management tool prior to version 7.6.1
• Installations configured with photos_star_visibility = anonymous
• Deployments exposing the /api/v2/Photo::highlight endpoint to untrusted networks

Discovery Timeline

• 2026-10-15 - CVE-2026-61610 published to NVD
• 2026-10-20 - Last updated in NVD database

Technical Details for CVE-2026-61610

Vulnerability Analysis

The vulnerability stems from request validation that runs before authorization. In BaseApiRequest::validateResolved(), Lychee invokes SetPhotosHighlightedRequest::processValidatedValues() prior to any authorization check. That method calls Photo::query()->findOrFail($photos_ids), which returns a 404 for unknown identifiers and continues processing for valid ones. An attacker who iterates through candidate identifiers observes distinguishable responses, exposing the existence of private photos.

After the resolver runs, PhotoPolicy::canHighlight() evaluates the policy. When photos_star_visibility is set to ANONYMOUS, the policy returned true unconditionally without invoking canSee(). The attacker therefore proceeds to update the is_highlighted flag on photos belonging to private or password-protected albums.

Root Cause

Two defects combine to produce the issue. First, the request lifecycle performs database lookups during input resolution, before authorization gates run. Second, the ANONYMOUS branch of PhotoPolicy::canHighlight() omitted the per-photo visibility check that other policy branches apply.

Attack Vector

An unauthenticated attacker sends POST /api/v2/Photo::highlight requests with guessed photo identifiers. Response codes disclose which identifiers exist. For existing identifiers, the request also mutates highlight state across album boundaries. The vector requires network reach to the API and the non-default anonymous star-visibility configuration.

// Patch to app/Policies/PhotoPolicy.php - add canSee() gate on anonymous path
$visibility = $config_manager->getValueAsEnum('photos_star_visibility', PhotoHighlightVisibilityType::class);

return match ($visibility) {
-    PhotoHighlightVisibilityType::ANONYMOUS => true,
-    PhotoHighlightVisibilityType::AUTHENTICATED => $user !== null,
+    PhotoHighlightVisibilityType::ANONYMOUS => $this->canSee($user, $photo),
+    PhotoHighlightVisibilityType::AUTHENTICATED => $user !== null && $this->canSee($user, $photo),
    PhotoHighlightVisibilityType::EDITOR => $user !== null && $this->canEdit($user, $photo),
    default => false,
};
// Source: https://github.com/LycheeOrg/Lychee/commit/fe07567c176bbdcda7b276bb6d664dfcd47a9b00

Detection Methods for CVE-2026-61610

Indicators of Compromise

• High volumes of POST /api/v2/Photo::highlight requests from unauthenticated sessions, especially with sequentially varying photo identifiers.
• Mixed 200 and 404 responses to /api/v2/Photo::highlight indicating identifier enumeration behavior.
• Unexpected changes to the is_highlighted column on photos belonging to private or password-protected albums.

Detection Strategies

• Review web server and application logs for requests to the Photo::highlight endpoint without an authenticated session cookie or API token.
• Correlate database audit entries for the photos table against the authenticated user context captured in request logs.
• Alert on bursts of findOrFail 404s originating from a single source address against the highlight endpoint.

Monitoring Recommendations

• Confirm the current value of photos_star_visibility; treat anonymous deployments on versions prior to 7.6.1 as exposed.
• Capture application logs with request path, source IP, user context, and response code, and forward them to a central analytics platform for review.
• Track baseline rates for the highlight endpoint and alert on deviations consistent with scripted enumeration.

How to Mitigate CVE-2026-61610

Immediate Actions Required

• Upgrade Lychee to version 7.6.1 or later, which adds the canSee() check to the anonymous policy branch.
• If upgrading is not immediately possible, change photos_star_visibility from anonymous to authenticated or editor.
• Audit is_highlighted state across photos in private and password-protected albums and revert unexpected changes.

Patch Information

The fix is published in Lychee Release v7.6.1 and merged via Pull Request #4449. The patch, commit fe07567, eagerly loads albums.access_permissions in SetPhotosHighlightedRequest and adds canSee() to PhotoPolicy::canHighlight(). See the GitHub Security Advisory GHSA-qcqq-p4pq-7r77 for the vendor description.

Workarounds

• Set photos_star_visibility to a non-anonymous value until the upgrade is applied.
• Restrict access to /api/v2/Photo::highlight at the reverse proxy or web application firewall for unauthenticated clients.
• Place the Lychee instance behind an authentication proxy if anonymous highlighting is not a required feature.

# Example nginx snippet to block unauthenticated access to the highlight endpoint
location = /api/v2/Photo::highlight {
    if ($http_cookie !~* "laravel_session") {
        return 403;
    }
    proxy_pass http://lychee_backend;
}