Vulnerabilities
All
My stack
Known exploited
Public exploit
Critical (9+)
Likely exploited (EPSS ≥ 50%)
Changed, 24 h
New, 24 h
Sort:
risk
modified
published
CVSS
EPSS
| CVE | CVSS | EPSS | Vendor, product | Description | Modified |
|---|---|---|---|---|---|
| CVE-2026-53662 | 9.6 critical | 0.00% | no CPE yet | immich is a high performance self-hosted photo and video management solution. From commit 4ffa26c9 until 4eb1003, a reflected cross-site scripting (XSS) vulnerability on the /auth/login page allows an attacker to fully compromise any authenticated user's account with a single link click. The continue query parameter is read from the URL and passed to SvelteKit's redirect() without any scheme or origin validation, allowing attacker-controlled JavaScript to execute inside Immich's origin. The payload then uses the victim's existing session to mint an all-permission API key on their account, leading to persistent account takeover. This vulnerability is fixed in commit 4eb1003. | Sun 25 Oct |
| CVE-2026-59258 | 7.2 high | 0.00% | no CPE yet | immich before 3.0.3 contains a broken access control vulnerability in the PUT /albums/:id/user/:userId endpoint that 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. | Sat 24 Oct |
| CVE-2026-119328 | 6.5 medium | — | immich-app, immich | Immich is a high-performance self-hosted photo and video management solution. Prior to 3.3.0, the unauthenticated machine-learning /predict endpoint in machine-learning/immich_ml/main.py accepted an options object and passed its values into model construction in machine-learning/immich_ml/models/base.py without restricting security-sensitive parameters. An attacker with network access to the service could set cache_dir to an arbitrary writable path, causing model downloads to write there and causing clear_cache() to pass that path to shutil.rmtree() after selected model-loading failures. Depending on filesystem permissions and the selected path, this could modify files in mounted data locations or recursively delete an attacker-selected directory. The model-name allowlist prevents this issue from becoming arbitrary-model deserialization or code execution. This issue is fixed in version 3.3.0. | 15 h ago |
| CVE-2026-40185 | 6.5 medium | 0.00% | mauriceboe, trek | TREK is a collaborative travel planner. Prior to 2.7.2, TREK was missing authorization checks on the Immich trip photo management routes. This vulnerability is fixed in 2.7.2. | Mon 26 Oct |
| CVE-2026-108165 | 5.3 medium | 0.00% | no CPE yet | 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. | 18 Oct |
| CVE-2026-119329 | 4.3 medium | — | immich-app, immich | Immich is a high-performance self-hosted photo and video management solution. Prior to 3.0.0, GET /api/map/markers used server/src/services/map.service.ts to add partner owner identifiers when withPartners=true, while server/src/repositories/map.repository.ts applied Archive visibility to every selected owner when isArchived=true. A view-only partner could therefore enumerate the GPS coordinates and existence of a sharer's archived photos or videos even though the timeline and direct-access paths exclude archived partner assets. The exposure is limited to location metadata and asset identifiers because image bytes remain protected by checkPartnerAccess. This issue is fixed in version 3.0.0. | 15 h ago |
| CVE-2026-119330 | 3.5 low | — | immich-app, immich | 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. | 15 h ago |
7 of 7
Download these 7 as CSV · subscribe to this list.
EPSS scores: 2026-10-30. NVD cursor: 2026-10-29 00:22. The News page shows only notable CVEs (KEV, your stack, new criticals, EPSS over 50%, or active exploitation per SSVC); this table has all of them.