Immich EUVD-2026-96320

Exploitation requires the attacker to hold an active, victim-accepted partner relationship in Immich and to be authenticated; the victim must use the Locked Folder feature for any sensitive data to be exposed. The attacker specifically invokes the partner synchronization stream (POST /api/sync/stream) requesting PartnerAssetsV2 and PartnerAssetExifsV1 record types. Limiting factors: no exposure exists without partner sharing configured, the attacker must already be a trusted partner (PR:L, not anonymous), and only Locked Folder asset metadata is leaked - not credentials, non-partnered users' data, or the asset binaries themselves.

This is a genuine but moderate-severity information-disclosure issue, not a high-urgency emergency. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N, score 5.3) and CWE-862 (Missing Authorization) align well with the description: a network-reachable, low-complexity flaw requiring an already-authenticated attacker holding a partner relationship (PR:L), with only low confidentiality impact (VC:L) and no integrity or availability impact. Publicly available exploit code exists (write-up on hackmd and VulnCheck advisory), which raises practical exploitability, but there is NO CISA KEV listing and NO EPSS score provided, so there is no evidence of widespread or active exploitation - consistent with a flaw that requires a pre-existing trusted partner link rather than an opportunistic internet-wide target. The real-world risk is scoped to the specific privacy harm of leaking Locked Folder metadata (GPS coordinates, capture times, descriptions, camera details) to users the victim already granted partner access to; it is a privacy/trust-boundary violation rather than a server-compromise bug. Net: a legitimate priority for privacy-sensitive Immich deployments that use partner sharing, but low operational risk for instances that do not use partner relationships.

An attacker who has been accepted as an Immich partner by a victim calls POST /api/sync/stream requesting PartnerAssetsV2 and PartnerAssetExifsV1 record types. Because the sync queries fail to exclude assets with Locked visibility, the response includes EXIF metadata for the victim's Locked Folder - GPS coordinates, capture timestamps, descriptions, and camera details - despite those assets being intended as hidden. A public proof-of-concept write-up documenting this request flow already exists.