CVE-2026-108165 in Immich
Summary
by MITRE • 10/10/2026
Immich through 3.3.1 contains a missing authorization vulnerability in the partner synchronization stream that allows authenticated partners to read Locked Folder asset metadata because sync queries do not exclude Locked visibility. Attackers with an active partner relationship can call POST /api/sync/stream with PartnerAssetsV2 and PartnerAssetExifsV1 types to obtain GPS coordinates, capture times, descriptions and camera details.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/10/2026
The vulnerability identified in Immich versions up to 3.3.1 represents a critical failure in access control mechanisms within the partner synchronization subsystem. This flaw is classified under CWE-285 Improper Authorization, as it allows an authenticated user with a specific relationship status to bypass intended security restrictions. Specifically, the application fails to enforce visibility boundaries for assets marked as Locked when processing requests from partners. In secure photo management systems, locked folders are designed to provide an additional layer of privacy by restricting access even among connected users or shared libraries. The absence of this check in the synchronization logic undermines the fundamental promise of data confidentiality and user trust.
Technically, the vulnerability resides in the handling of POST /api/sync/stream requests that utilize PartnerAssetsV2 and PartnerAssetExifsV1 payload types. When a partner initiates a sync operation, the backend processes these queries without filtering out assets designated as locked within the owner's account. This oversight means that any metadata associated with private photos is exposed to the requesting party. The attack vector requires no complex exploitation techniques; it relies on standard API interactions available to any user who has established an active partner relationship with a victim. By leveraging this misconfiguration, an attacker can systematically retrieve sensitive information including GPS coordinates, precise capture times, descriptive text fields, and detailed camera specifications from the locked folder contents.
The operational impact of this vulnerability is severe due to the sensitivity of the exposed data types. The disclosure of GPS coordinates poses significant physical security risks, potentially revealing a user's home address, frequent locations, or travel patterns. Capture timestamps can be used for timeline reconstruction and behavioral analysis, while camera details may aid in device fingerprinting or targeted social engineering attacks. Descriptions often contain personal context that could compromise privacy further. This level of information leakage violates the principle of least privilege and demonstrates a failure to implement proper object-level access controls on sensitive data categories.
From an offensive security perspective, this vulnerability aligns with ATT&CK technique T1005 Data from Local System Retrieval, specifically through API endpoints that allow unauthorized data exfiltration. It also reflects weaknesses in how session context is validated against resource permissions during synchronization events. The lack of server-side validation for locked status indicates a broader architectural issue where trust assumptions about partner relationships are not sufficiently bounded by granular permission checks.
Mitigation strategies must prioritize immediate patching to version 3.3.2 or later, which addresses the filtering logic in the sync stream handler. Until an update is applied, administrators should consider disabling partner synchronization features if they are not actively required for their workflow. Additionally, implementing strict input validation and ensuring that all API endpoints enforce consistent authorization checks across different asset visibility states is essential. Security audits should focus on verifying that locked or private assets remain inaccessible to any external entity, including partners, unless explicitly permitted by the account owner through a dedicated sharing mechanism rather than automatic sync inclusion.