CVE-2026-53662

In Immich 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.

In Immich before 3.0.0, the GET /api/map/markers endpoint exposed to a view-only partner the GPS coordinates and existence of a sharer's archived photos or videos. The exposure is limited to location metadata and asset identifiers, as image bytes remain protected.

In Immich before 3.3.0, the unauthenticated machine-learning /predict endpoint accepted an options object without restricting security-sensitive parameters. An attacker with network access could set cache_dir to an arbitrary writable path, causing model downloads to write there and clear_cache() to recursively delete an attacker-selected directory via shutil.rmtree().

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.

Immich is a high-performance self-hosted photo and video management solution. Prior to 3.2.4, an authenticated non-admin user could upload SVG files that thumbnail-generation code in server/src/repositories/media.repository.ts passed to libvips. Files that bypassed libvips' native SVG loader fell through to ImageMagick, where attacker-controlled <image href> values reached unrestricted MSL and VIDEO coder operations. By storing one crafted asset and referencing its path from a second delayed-marker SVG, an attacker could execute code in the immich-server container when thumbnail processing ran. This issue is fixed in version 3.2.4.

A vulnerability has been found in immich-app Immich up to 2.7.5, affecting the checkSharedLinkAccess function in server/src/utils/access.ts within the Shared Link Preview Handler. Manipulation of the Password argument leads to improper authorization. The reported GitHub issue was closed as a duplicate.

Immich through 3.1.0 fails to properly enforce locked asset visibility when assets are locked through the single-asset endpoint, allowing them to remain accessible through shared albums and links. Attackers can read locked assets and their metadata by accessing existing shared albums or links, bypassing the locked visibility protection.

A broken access control vulnerability in Immich before version 3.0.3 in the PUT /albums/:id/user/:userId endpoint allows shared album editors to modify member roles without owner-only restrictions. Attackers with editor access can demote the album owner to editor and promote themselves to owner in sequential requests, gaining full control including deletion and eviction capabilities.

Immich before version 2.7.0 has a Stored XSS vulnerability in the 360° panorama viewer. An authenticated user can upload a malicious image whose OCR text is rendered unsanitized, allowing arbitrary JavaScript execution in other users' browsers.

Immich before version 2.6.0 has a credential disclosure vulnerability when authenticating to a shared album. The album password is transmitted in URL query parameters in a GET request to /api/shared-links/me, exposing it in browser history, proxy and server logs, and referrer headers.