Live › vulnerability › CVE-2026-119330
An authenticated Immich user who knows another user's asset ID can attach that photo to their own shared link. The anonymous link then exposes the victim's thumbnail, metadata and original file.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-30 20:25 UTC. All times on this page are UTC.
Self-hosted Immich servers running a version before 3.2.0 where users can create shared links. An attacker needs a regular account and the victim's asset UUID, which is hard to guess but may leak. Instances with a single user or without shared links enabled for other accounts carry less risk.
No product ranges from the sources yet.
docker exec immich_server cat /usr/src/app/package.json or the image tag in your compose file.3.2.0 or later.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
Immich is a high-performance self-hosted photo and video management solution. Prior to 3.2.0, the shared-link creation API accepted albumId and assetIds as independent fields in server/src/services/shared-link.service.ts but authorized only the resource selected by the requested link type. An authenticated attacker who already knew a victim-owned asset UUID could select SharedLinkType.Album for an attacker-owned album while supplying that UUID in assetIds; SharedLinkService.create() persisted the unchecked association in shared_link_asset and made the victim asset available through the new anonymous shared-link credential. This exposed victim metadata, thumbnails, and the byte-identical original file and created a persistent sharing relationship that could be redistributed. This issue is fixed in version 3.2.0.
This page as .md · .json · in your agent: get_signal("CVE-2026-119330")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.