Immich calendar heatmap endpoint discloses cross-user activity through broken access control
- Exploited
- Proof of concept public, per CISA
- Fix
- Fixed in 3.2.0
- Who is exposed
- Not reported
Do first: Upgrade to a fixed version: 3.2.0.
- Last modified
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 22/100 · provisional
- 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
- Exploitation: poc
- Automatable: no
- Technical impact: partial
Summary
Immich, a self-hosted photo and video management application, has a broken access control flaw in its calendar heatmap endpoint that lets any logged-in non-admin user remotely view how often another account uploaded or captured photos and videos on arbitrary dates. The attacker learns only daily and total counts, including counts for archived and locked assets, not the assets themselves.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
Read the original description
Immich is a high-performance self-hosted photo and video management solution. From 3.0.0 until 3.2.0, the GET /api/admin/users/{id}/calendar-heatmap route in server/src/controllers/user-admin.controller.ts uses the ordinary Permission.UserRead permission without an admin-route requirement, and UserAdminService.getCalendarHeatmap in server/src/services/user-admin.service.ts does not compare the authenticated user with the requested user identifier or perform a separate access check. Any authenticated non-admin user can therefore request another account's upload or capture-date activity heatmap for an arbitrary date range. AssetRepository.getCalendarHeatmap in server/src/repositories/asset.repository.ts filters by owner, date, and deletion state but not visibility, so the returned daily counts and total count include archived and locked assets. The route exposes counts and activity dates but does not return asset metadata or content, and it does not affect integrity or availability. This issue is fixed in version 3.2.0.
cve.now Index
- Exploitation15/40CISA rates a proof of concept as public
- Exposure3/25Reachable over the network · Unknown: No advisory context yet
- Reach?/20Unknown. No tracked technology or package matched
- Severity4.3/10CVSS 4.3
- No patch0/5No signal
What would change the score
- Would score about 62 if added to CISA KEV
- Would score about 57 if CISA's SSVC rates exploitation active
- Would score about 41 if advisories confirm default setups are exposed
What to do
Upgrade to a fixed version: 3.2.0.
Timeline
- CVE published
- First seen by cve.now
- CISA SSVC assessment
Exploitation: poc · Automatable: no · Technical impact: partial
- Record last updated
Affected versions
- immich-app immich
From 3.0.0 · fixed in 3.2.0
Evidence 5
- Advisory
- Repository
- Repository
- Repository
- Repository
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-104867
Is CVE-2026-104867 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. CISA's SSVC assessment notes a proof of concept exists. No public exploit code is tracked.Source: cve.now feed data
Which versions are affected by CVE-2026-104867?
immich: from 3.0.0 before 3.2.0.Source: cve.now feed data
How do I fix CVE-2026-104867?
Upgrade to a fixed version: 3.2.0.Source: cve.now feed data