CVE-2026-57943: LibrePhotos Auth Bypass Vulnerability

CVE-2026-57943 Overview

CVE-2026-57943 is a broken object level authorization vulnerability in LibrePhotos versions prior to 1.0.0. The flaw resides in the SetPhotosShared endpoint, which fails to validate photo ownership before modifying shared_to relations. Authenticated users can manipulate the endpoint to grant themselves access to private photos belonging to other users. The issue is classified under CWE-639: Authorization Bypass Through User-Controlled Key and represents a classic Insecure Direct Object Reference (IDOR) pattern.

Critical Impact
Authenticated attackers can read arbitrary private photos of other LibrePhotos users by bypassing ownership checks in the sharing endpoint.

Affected Products

LibrePhotos versions prior to 1.0.0
Self-hosted LibrePhotos deployments on the affected release train
Backend API component (apps/backend/api) of LibrePhotos

Discovery Timeline

2026-06-29 - CVE-2026-57943 published to NVD
2026-06-29 - Last updated in NVD database
Fix released - LibrePhotos v1.0.0 release addressing the authorization issue

Technical Details for CVE-2026-57943

Vulnerability Analysis

LibrePhotos exposes a SetPhotosShared API endpoint that manages the shared_to relation on photo objects. The endpoint accepts a list of photo identifiers and user targets, then updates the sharing relationship in the database. The vulnerable implementation does not verify that the requesting user actually owns the photos being modified. This authorization gap allows any authenticated user to submit photo IDs that belong to other users and add themselves to the shared_to set. Once the relation is written, the attacker gains legitimate read access to those private photos through normal sharing workflows.

The patch in commit 325bd1f5fda71c6d56737aa09cfce0cb8106675a addresses related cross-user authorization issues across the backend, including scoping public-access queries to safe read-only actions such as list and retrieve in the album views.

Root Cause

The root cause is missing ownership validation on a mutable API endpoint. The SetPhotosShared handler trusts client-supplied photo identifiers without confirming that photo.owner == request.user. The unscoped queryset also permitted mutation paths through parameters intended for public read access, compounding the authorization gap.

Attack Vector

An attacker with any valid LibrePhotos account authenticates against the instance and sends a crafted request to the SetPhotosShared endpoint. The request references photo IDs owned by a victim user and lists the attacker's own account in the target sharing set. The server writes the shared_to relation without checking ownership. The attacker then retrieves the photos through standard shared-media endpoints.

python

# Patch excerpt from apps/backend/api/views/albums.py
#   commit 325bd1f5fda71c6d56737aa09cfce0cb8106675a
def get_queryset(self):
    # Support public access when explicitly requested. Public access is
    # READ-ONLY: only honor ?public for the safe list/retrieve actions, so a
    # public album id can't be mutated or deleted through this unscoped
    # queryset. See issue #1861.
    if self.request.query_params.get("public") and self.action in (
        "list",
        "retrieve",
    ):
        # Anyone can view a public album if the album itself is marked
        # public and active (not expired)
        username = self.request.query_params.get("username")
        from django.utils import timezone

Source: LibrePhotos commit 325bd1f

Detection Methods for CVE-2026-57943

Indicators of Compromise

Unexpected POST or PATCH requests to the SetPhotosShared endpoint from user accounts that do not own the referenced photo IDs
Rapid growth in a user account's accessible photo set without corresponding upload activity
Database rows in the shared_to relation linking photos to users who are not friends or collaborators of the photo owner
Access log patterns showing a single authenticated account enumerating sequential photo IDs

Detection Strategies

Correlate LibrePhotos application logs against photo ownership records to identify sharing writes where actor != photo.owner
Alert on authenticated users triggering high volumes of sharing-relation modifications within a short window
Ingest LibrePhotos access logs into a SIEM or data lake and query for SetPhotosShared calls carrying photo IDs outside the caller's ownership scope

Monitoring Recommendations

Enable verbose API access logging for all sharing and album endpoints
Track baseline sharing activity per user and flag statistical outliers
Monitor Django audit trails for writes to the photos_shared_to table from unexpected user contexts
Retain HTTP request bodies for authorization-sensitive endpoints to support forensic review

How to Mitigate CVE-2026-57943

Immediate Actions Required

Upgrade LibrePhotos to version 1.0.0 or later, which contains the ownership validation fix
Audit the shared_to relations in your database and revoke any sharing entries that were not authorized by the photo owner
Rotate API tokens and force re-authentication for all users following the upgrade
Review access logs for prior exploitation covering the exposure window

Patch Information

The vulnerability is fixed in LibrePhotos 1.0.0. The corrective changes are tracked in Pull Request #1866, Issue #1860, and commit 325bd1f5fda71c6d56737aa09cfce0cb8106675a. See the VulnCheck advisory for additional context.

Workarounds

Restrict LibrePhotos instances to trusted users only until the patch is applied
Place the application behind an authenticating reverse proxy that limits access to known accounts
Disable public registration to prevent low-effort account creation for exploitation
Consider taking sharing functionality offline via reverse proxy rules that block the SetPhotosShared route until upgrade

bash

# Example nginx rule to block SetPhotosShared until upgrade completes
location ~* /api/photosedit/setphotosshared {
    return 403;
}