Immich EUVD-2026-114377

Requires an authenticated regular Immich account (PR:L) on a server running <=3.1.0, plus prior out-of-band knowledge of the specific victim-owned asset's UUID - the attack cannot enumerate victims because the 128-bit random UUID is the only selector. The concrete trigger is submitting a CreateSharedLink request with type=ALBUM, an attacker-owned albumId, and the victim UUID placed in the assetIds field, which the server authorizes against the album only while persisting the asset association in shared_link_asset. Limiting factors: single-asset-per-known-UUID disclosure (not bulk), authentication required, affected only before 3.2.0, and confidentiality-only impact (no modification of victim data). The complete fix is upgrading to 3.2.0, which adds a type-dependent schema invariant rejecting assetIds on ALBUM links and albumId on INDIVIDUAL links.

The signals converge on genuinely low-to-moderate priority. The supplied CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:N/A:N = 3.5) reflects an authenticated (PR:L) actor, network reach, no integrity or availability impact, and only partial confidentiality (C:L). The vuln.today decision label is 'monitor', the lowest urgency tier, and the issue is NOT on CISA KEV, so there is no evidence of active exploitation. No EPSS score was supplied, so widespread automated-exploitation probability cannot be quantified from this data. Counterbalancing the low score, the GHSA advisory publishes a complete, reproducible proof-of-concept (curl-based) and the fix is already shipped in 3.2.0, so the barrier to reproduction is low for anyone running an unpatched instance. The most important limiting factor is that exploitation requires the attacker to already KNOW a victim-owned asset UUID (a 128-bit random identifier not enumerable at scale), which makes this a targeted-disclosure issue rather than a mass-exploitation one. One discrepancy to flag explicitly: the authoritative vector sets UI:R, but the advisory and PoC describe an entirely attacker-driven flow with no victim interaction - the 'required' element is really out-of-band knowledge of the asset UUID, not a victim click; verify the UI metric with the reporter. Overall this is a real authorization (CWE-285) defect worth patching but not an emergency.

A legitimate, authenticated Immich user who has learned a victim's asset UUID (e.g. from a previously shared album, link, or leaked identifier) creates an ALBUM-type shared link for their own album while smuggling the victim's UUID into the assetIds field. The server authorizes only the attacker's album but persists the unchecked asset association, so the resulting anonymous shared-link credential exposes the victim's metadata, thumbnail, and byte-identical original file, which the attacker can then redistribute to unauthenticated third parties. A full working proof-of-concept is published in the GHSA advisory.