CVE-2026-23896: 
NixOS vulnerability analysis and mitigation

CVE-2026-23896 is an API key privilege escalation vulnerability in immich, a self-hosted photo and video management solution. It allows any user holding a low-privilege API key to escalate that key's permissions to full administrative access by calling the API key update endpoint without proper authorization checks. All immich versions prior to 2.5.0 (Docker deployments) are affected. The vulnerability was published on January 29, 2026, and carries a CVSS v3.1 base score of 8.8 (High) per NVD, or 7.2 (High) per the GitHub Security Advisory (GitHub Advisory, Red Hat CVE).

The root cause is Improper Privilege Management (CWE-269): the update method in api-key.service.ts allows an API key to modify its own permissions without verifying that the caller possesses the permissions it is attempting to grant. In contrast, the create method correctly validates this via an isGranted check, but this guard was never applied to the update path. An attacker with any API key that includes the apiKey.update permission can send a PUT /api/api-keys/{id} request with "permissions": ["all"] to elevate the key to full administrative access. No additional user interaction or complex conditions are required beyond holding a valid (even minimally scoped) API key (GitHub Advisory).

Successful exploitation grants the attacker full administrative control over the immich instance, including access to all stored photos and videos, the ability to modify or delete system configurations, and the ability to perform any administrative action on behalf of the compromised account. Because immich is a self-hosted personal media server, exploitation could expose highly sensitive personal media data. The attack requires only network access and a low-privilege API key, making the blast radius equivalent to a complete account and system takeover (GitHub Advisory).

A public proof-of-concept (PoC) Python script is included in the GitHub Security Advisory, demonstrating the full escalation flow from a limited API key to full administrative access. There is no current evidence of in-the-wild exploitation. The EPSS score is approximately 0.029% (0.000290), indicating low but non-zero probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No specific threat actor attribution has been reported (GitHub Advisory, Red Hat CVE).

1. Obtain a low-privilege API key: Acquire or create an immich API key with at minimum the apiKey.read and apiKey.update permissions. This could be done by a malicious insider, a compromised user account, or via social engineering.
2. Identify the API key ID: Use the API key to call GET /api/api-keys to retrieve the key's UUID (key_id).
3. Confirm limited access: Attempt a privileged action (e.g., POST /api/albums) using the limited key; confirm it returns HTTP 403.
4. Escalate permissions: Send a PUT /api/api-keys/{key_id} request with the header x-api-key: <limited_key> and body {"name": "Escalated Key", "permissions": ["all"]}. The server processes the update without validating that the caller holds the permissions being granted, returning HTTP 200.
5. Confirm full access: Retry the previously denied privileged action (e.g., POST /api/albums); it now returns HTTP 201, confirming full administrative access has been achieved (GitHub Advisory).

• Network: Unexpected PUT /api/api-keys/{id} requests from API key-authenticated sessions (i.e., using x-api-key header rather than a session token), especially those setting permissions to ["all"] or a broad set of scopes.
• Logs: Application access logs showing a sequence of: (1) a PUT /api/api-keys/{id} call with a low-privilege key, followed by (2) previously unauthorized API calls (e.g., album creation, user management) succeeding from the same key.
• Application Behavior: API keys that were created with limited permissions but subsequently appear with "all" or expanded permissions in GET /api/api-keys responses.
• Audit Trail: Absence of an admin session token (Bearer) on permission-modifying API key update calls — legitimate admin changes would typically use a session token, not an API key header (GitHub Advisory).

The fix is available in immich version 2.5.0, which adds the same isGranted permission validation to the update method that already existed in the create method. All users running immich prior to 2.5.0 should upgrade immediately. As a temporary workaround for environments that cannot patch immediately, restrict API key generation to trusted users only, limit network exposure of the immich instance (e.g., behind a VPN or firewall), and audit existing API keys for unexpected permission scopes. Review access logs for any PUT /api/api-keys calls made using API key authentication (GitHub Advisory).

The vulnerability was credited to researcher DarkaMaul and published by the immich maintainer jrasm91 via GitHub's security advisory process. Red Hat has also tracked the CVE in their security database. No significant broader media coverage or notable public researcher commentary beyond the advisory itself has been identified at this time (GitHub Advisory, Red Hat CVE).