CVE-2026-82272 in Immich
Summary
by MITRE • 08/28/2026
Immich through 3.1.0 fails to properly enforce locked asset visibility when assets are locked through the single-asset endpoint, allowing them to remain accessible through shared albums and links. Attackers can read locked assets and their metadata by accessing existing shared albums or links, bypassing the locked visibility protection.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability identified in Immich versions up to 3.1.0 represents a critical access control failure within the application's asset management subsystem. Specifically, the flaw lies in the inconsistent enforcement of locking mechanisms when assets are marked as private or hidden from general user view through the single-asset endpoint. While the intended security model dictates that locked assets should be completely inaccessible to unauthorized users and excluded from shared contexts, the implementation fails to propagate this restriction across all access vectors. This architectural inconsistency allows an attacker who has gained legitimate but limited access to a shared album or a public link to retrieve content that was explicitly designated as restricted by the asset owner. The core technical deficiency is not in the initial locking action itself, which may correctly update internal database flags, but rather in the subsequent retrieval logic used when serving assets via secondary channels such as shared albums and direct links.
From a technical perspective, this issue stems from insufficient validation of access permissions during the read operations associated with shared content delivery. When an asset is locked, the system likely updates its visibility status to exclude it from standard user feeds or search results. However, when requests are processed through the shared album endpoint or public link handler, the application fails to cross-reference these locking flags against the current request context. Consequently, the server retrieves and transmits both the binary data of the locked asset and its associated metadata without verifying whether the specific instance being accessed is subject to a lock restriction. This bypass effectively neutralizes the privacy controls intended for sensitive media files, as the security boundary defined by the lock feature does not extend to all entry points into the application's storage layer.
The operational impact of this vulnerability is significant, particularly in environments where users rely on Immich for personal or professional photo and video management involving sensitive information. Attackers with access to a shared album can exfiltrate locked assets that were never intended to be part of that share. This includes high-resolution images, videos, and associated metadata such as GPS coordinates, timestamps, device models, and EXIF data. The exposure of this metadata is particularly dangerous as it can reveal precise location history and personal habits even if the visual content itself was meant to remain private. For organizations using Immich for collaborative media storage, this flaw undermines trust in shared workflows and poses a risk of accidental or malicious leakage of confidential materials that were protected under the assumption that locking would provide comprehensive isolation from shared contexts.
This vulnerability aligns with CWE-284 Improper Access Control, as it involves an authorization bypass where users are able to access resources they should not be permitted to view based on their assigned privileges and the resource's state. Furthermore, in the context of the MITRE ATT&CK framework, this behavior is consistent with techniques related to Unauthorized Access to Resources or Data from Cloud Storage, specifically illustrating how misconfigured permissions can lead to data exfiltration through alternative access paths. The flaw highlights a common pitfall in web application development where security controls are applied inconsistently across different API endpoints rather than being enforced at a centralized authorization layer that governs all asset retrieval operations regardless of the entry point used by the client.
To mitigate this risk, immediate action is required to address the underlying code logic governing asset visibility checks during shared content delivery. Developers must ensure that every endpoint responsible for serving assets, including those handling shared albums and public links, performs a comprehensive check against the asset's locking status before transmitting data. This involves implementing centralized authorization middleware or service methods that validate access rights uniformly across all retrieval operations. Until an official patch is released by Immich maintainers, users should exercise caution when sharing albums containing sensitive material and consider avoiding the use of locked assets in shared contexts until the vulnerability is resolved. Additionally, auditing logs for unusual patterns of asset downloads from shared links may help identify potential exploitation attempts in deployed environments.