CVE-2026-119329 in Immich
Summary
by MITRE • 10/30/2026
Immich is a high-performance self-hosted photo and video management solution. Prior to 3.0.0, GET /api/map/markers used server/src/services/map.service.ts to add partner owner identifiers when withPartners=true, while server/src/repositories/map.repository.ts applied Archive visibility to every selected owner when isArchived=true. A view-only partner could therefore enumerate the GPS coordinates and existence of a sharer's archived photos or videos even though the timeline and direct-access paths exclude archived partner assets. The exposure is limited to location metadata and asset identifiers because image bytes remain protected by checkPartnerAccess. This issue is fixed in version 3.0.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/30/2026
The vulnerability identified in Immich versions prior to 3.0.0 represents a critical authorization bypass within the application's map functionality, specifically affecting how shared assets are filtered and exposed through API endpoints. As a high-performance self-hosted photo and video management solution, Immich relies on strict access control mechanisms to ensure that users only interact with data they are explicitly permitted to view. The core flaw resides in the server-side logic governing the GET /api/map/markers endpoint, which is responsible for rendering map-based visualizations of user media. This function interacts with two primary components: the map service located at server/src/services/map.service.ts and the map repository at server/src/repositories/map.repository.ts. These components are tasked with aggregating location data from various assets to display them on an interactive map interface, a feature that inherently requires access to GPS coordinates and asset metadata.
The technical flaw stems from inconsistent application of visibility filters when handling shared partner content. When the API request includes the parameter withPartners set to true, the system correctly adds partner owner identifiers to the query context. However, when the isArchived flag is also present in the request parameters, the map repository incorrectly applies Archive visibility rules exclusively to every selected owner rather than respecting the specific permissions of the viewing user. This logic error creates a scenario where view-only partners can enumerate the GPS coordinates and existence of archived photos or videos belonging to their sharers. In standard Immich workflows, archived assets are typically hidden from timelines and direct-access paths for shared users, creating an expectation of privacy regarding these items. The vulnerability circumvents this expectation by exposing location metadata through the map endpoint, effectively allowing unauthorized enumeration of private data that should remain obscured.
The operational impact of this vulnerability is significant due to the sensitivity of geolocation data. While the exposure is limited to location metadata and asset identifiers because image bytes remain protected by checkPartnerAccess checks during actual file retrieval, the leakage of GPS coordinates poses substantial privacy risks. Attackers or malicious partners can use this information to track a user's movements, identify frequent locations such as home addresses or workplaces, and infer personal habits based on historical movement patterns. This constitutes an unauthorized disclosure of sensitive location data, violating the principle of least privilege by granting view-only users access to metadata that should be restricted for archived content. The ability to enumerate these assets also aids in reconnaissance, allowing adversaries to map out a user's digital footprint without triggering standard alerts associated with direct file access attempts.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control and CWE-200 Exposure of Sensitive Information to an Unauthorized Actor. The failure lies in the application logic not properly enforcing restrictions on sensitive information when interacting with archived assets through specific API endpoints. In terms of adversary tactics, this behavior corresponds to ATT&CK technique T1539 Steal Web Session Data or more broadly T1213 Data from Information Repositories, as it involves extracting structured data from a database-driven application without proper authorization checks. The vulnerability highlights the importance of consistent permission checking across all API endpoints, particularly those that aggregate metadata for visualization purposes rather than direct content delivery.
To mitigate this issue and prevent similar vulnerabilities in future development cycles, Immich version 3.0.0 implements fixes to ensure that archive visibility rules are correctly applied regardless of partner sharing settings. For users operating on earlier versions, immediate upgrading is the primary remediation strategy. Additionally, administrators should audit API usage logs for unusual patterns involving map marker requests with archived flags set to true by view-only partners. Implementing strict input validation and ensuring that all data retrieval paths enforce uniform access control policies are essential best practices. Security testing procedures should include specific test cases for edge conditions in sharing permissions, particularly focusing on how metadata is exposed through non-standard endpoints like mapping services versus standard gallery views.