Immich: A regular user can create SharedLink for album/asset belonging to another user through CreateSharedLink API
Immich 3.1.0 and earlier let an authenticated regular user create shared links for albums or assets owned by other users. Fixed in 3.2.0.
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Fix
- Fixed in 3.2.0
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
Summary
Immich, a self-hosted photo and video management application, is affected before version 3.2.0. An authenticated user who knew the unique ID of another user's photo or video could create a shared link that exposed that private file, including its metadata, thumbnails, and original copy, to anyone with the link.
Summarized by anthropic/claude-haiku-5.5. Verify details against the original sources.
Read the original description
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.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- immich-app immich
fixed in 3.2.0
References 4
GitHub · immich-app/immich
Questions about CVE-2026-119330
What does this mean?
An authenticated regular user can create a shared link for an album or asset that belongs to another user through the CreateSharedLink API. If the victim's asset UUID is known, the user can download the byte-identical original file, along with its metadata and thumbnail, and the shared link persists.Source: github.com
Am I affected, and how do I check?
Immich 3.1.0 and earlier are affected (affected versions are <=3.1.0). The attack needs the victim's asset UUID to be known. To check a installation, look at the Immich server version it runs.Source: github.com
What should I do about it?
Upgrade Immich to 3.2.0 or later, which is the fixed version.Source: github.com
Is it being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data