CVE-2026-104867 in Immich
Summary
by MITRE • 11/05/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 11/05/2026
The vulnerability identified within Immich versions ranging from 3.0.0 to 3.2.0 represents a critical failure in access control logic for administrative endpoints, specifically affecting the GET /api/admin/users/{id}/calendar-heatmap route. This endpoint is designed to retrieve activity heatmaps representing upload or capture-date frequency for specific user accounts. The core technical flaw lies in the insufficient authorization checks performed by both the controller and service layers of the application. In server/src/controllers/user-admin.controller.ts, the route relies solely on the Permission.UserRead permission rather than enforcing a strict admin-route requirement that would restrict access to users with elevated privileges. Concurrently, the implementation in server/src/services/user-admin.service.ts fails to validate whether the authenticated user initiating the request matches the target user identifier provided in the URL path or performs any separate authorization check to verify if the requester has legitimate rights to view data associated with another account. This combination of errors allows any authenticated non-administrator user to bypass intended restrictions and query the activity metrics for arbitrary accounts within the system.
The operational impact of this vulnerability centers on information disclosure, specifically regarding private metadata rather than sensitive content or file integrity. The underlying AssetRepository.getCalendarHeatmap function filters results based on asset ownership, date ranges, and deletion states but notably omits checks against visibility settings such as archived or locked status. Consequently, the returned daily counts and total activity metrics include data from assets that should remain hidden from standard users due to their privacy configurations. While this does not expose actual image files, video content, or detailed asset metadata like EXIF data, it reveals significant behavioral patterns about other users' usage habits. An attacker could leverage these heatmaps to infer when specific individuals are most active, potentially aiding in social engineering attacks or timing-based exploitation strategies against the target accounts. The vulnerability does not compromise system integrity or availability but significantly erodes user privacy expectations by leaking aggregated activity data that was intended to be restricted.
From a classification perspective, this issue aligns with CWE-284 Improper Access Control and CWE-1065 API Endpoint Authorization Bypass, as the application fails to enforce proper authorization checks on an API endpoint accessible via standard authentication credentials. In terms of MITRE ATT&CK mapping, this behavior corresponds to T1078 Valid Accounts, where an attacker uses legitimate user credentials to access resources they are not authorized to view, and potentially T1539 Steal Web Session Cookie if the activity data is used for further reconnaissance or targeted attacks against specific users. The vulnerability highlights a common architectural oversight in self-hosted solutions where administrative endpoints may inherit broader permission scopes without implementing granular resource-level authorization checks that distinguish between viewing one's own data versus accessing another user's private information.
Mitigation strategies primarily involve upgrading to Immich version 3.2.0 or later, which resolves this issue by correcting the access control logic in both the controller and service layers. For environments where immediate patching is not feasible, administrators should implement network-level controls such as firewall rules or reverse proxy configurations that restrict access to administrative API endpoints exclusively from trusted internal IP addresses or specific management networks. Additionally, implementing strict input validation on user identifiers within the application layer can help prevent unauthorized cross-account queries until a permanent code fix is deployed. Regular security audits of authentication and authorization flows are recommended to ensure that all admin routes enforce appropriate privilege checks beyond basic session validity.