CVE-2026-82272: Immich Auth Bypass Vulnerability

CVE-2026-82272 Overview

CVE-2026-82272 is an authorization flaw in Immich, a self-hosted photo and video management platform. Versions through 3.1.0 fail to enforce locked asset visibility when assets are locked through the single-asset endpoint. Locked assets remain accessible through previously created shared albums and shared links, bypassing the locked visibility protection.

The weakness is classified under CWE-863: Incorrect Authorization. An authenticated attacker with access to a shared album or link can read locked assets and their metadata. The flaw affects the confidentiality of user-controlled private content stored in Immich instances.

Critical Impact
Attackers can read locked photos, videos, and metadata through existing shared albums or shared links, defeating the visibility control users rely on to hide sensitive assets.

Affected Products

Immich versions up to and including 3.1.0
Self-hosted Immich server deployments exposing shared albums
Immich instances issuing public or user-scoped shared links

Discovery Timeline

2026-08-28 - CVE-2026-82272 published to NVD
2026-08-31 - Last updated in NVD database

Technical Details for CVE-2026-82272

Vulnerability Analysis

Immich supports a "locked" visibility state that hides selected assets from the main timeline and search results. The lock operation can be performed on a per-asset basis through the single-asset update endpoint. This endpoint updates the visibility flag on the asset record but does not re-evaluate the asset's exposure through pre-existing sharing surfaces.

Shared albums and shared links resolve assets through access-control checks implemented in access.repository.ts and consumed by asset.service.ts. These access paths grant read access based on album membership or link possession, without consulting the locked visibility state applied by the single-asset endpoint. The result is a broken access-control condition: the object is marked as locked, yet the sharing layer treats it as if it were still an ordinary asset.

Because the vulnerability lives in authorization logic rather than data storage, both original files and metadata (EXIF, timestamps, geolocation) remain retrievable. The issue is a business-logic authorization failure rather than a memory-safety or injection defect.

Root Cause

The root cause is inconsistent enforcement of the locked visibility attribute across authorization checks. The single-asset endpoint updates the visibility field, but the album and shared-link resolvers do not filter locked assets out of their result sets. The lock state is treated as a UI hint on the timeline rather than a security boundary applied uniformly across all access paths.

Attack Vector

An attacker requires network access and low privileges, either as a user with membership in an existing shared album or as a holder of an existing shared link. No user interaction and no elevated privileges are needed. The attacker enumerates assets through the shared album API or the shared-link endpoint and retrieves assets whose owner has since marked them as locked through the single-asset endpoint.

No verified proof-of-concept code is published in the referenced advisories. See the VulnCheck advisory and Immich GitHub Issue #29526 for the maintainer discussion and technical context.

Detection Methods for CVE-2026-82272

Indicators of Compromise

Access log entries showing asset downloads through /api/albums/* or /api/shared-links/* for asset IDs that have been transitioned to locked visibility.
Repeated enumeration of album members or shared-link asset lists by a single session shortly after a lock action.
Elevated bandwidth or download counts from accounts that historically only browsed thumbnails.

Detection Strategies

Correlate asset visibility changes in the Immich database with subsequent read events through album or shared-link endpoints for the same asset IDs.
Alert on shared-link accesses that resolve to assets whose visibility column equals locked.
Baseline normal per-user shared-album access patterns and flag deviations following bulk lock operations.

Monitoring Recommendations

Forward Immich reverse-proxy access logs (Nginx, Traefik, Caddy) to a central log store and retain at least 90 days of history.
Enable database audit logging on the assets and shared_links tables to reconstruct authorization decisions.
Monitor the Immich GitHub repository and release notes for the fixed version and adjust identification rules once the patched code paths are known.

How to Mitigate CVE-2026-82272

Immediate Actions Required

Inventory all shared albums and shared links, and revoke any that contain assets the owners intended to keep private.
Rotate or delete existing shared link tokens so that attackers who previously captured a URL lose access.
Review Immich user accounts and remove album memberships that are no longer required.
Restrict network exposure of the Immich instance to trusted networks or place it behind an authenticating reverse proxy.

Patch Information

At the time of publication, the NVD entry lists Immich through version 3.1.0 as affected and does not enumerate a fixed release. Track the Immich repository and Issue #29526 for the remediation commit, then upgrade to the first release that includes locked-visibility enforcement across access.repository.ts and asset.service.ts.

Workarounds

Before locking an asset, remove it from every shared album that contains it.
Delete or regenerate any shared links that reference assets you intend to lock.
Disable the shared-link feature entirely for users who handle sensitive content until a patched release is deployed.
Segment the Immich instance behind a VPN or SSO proxy to reduce the population of potential attackers.

bash

# Configuration example: audit assets that are locked but still reachable via albums
# Run against the Immich PostgreSQL database (read-only)
psql -U immich -d immich -c "
SELECT a.id, a.\"originalFileName\", a.visibility, aa.\"albumsId\"
FROM assets a
JOIN albums_assets_assets aa ON aa.\"assetsId\" = a.id
WHERE a.visibility = 'locked';
"