Статья CVE-2026-32914: Broken Access Control в OpenClaw — эскалация привилегий через /config и /debug handlers

Когда я вижу в описании CVE слова «insufficient access control in command handlers», первый вопрос не «что делает уязвимость», а «почему middleware не поймал запрос до хендлера». CVE-2026-32914 - классический случай: разработчики OpenClaw выстроили двухуровневую модель прав, но забыли натянуть верхний уровень на самые чувствительные эндпоинты. Итог - любой пользователь с базовой command-авторизацией читает и модифицирует конфигурацию вашего агента. Разберём уязвимость до уровня конкретных запросов, покажем эксплуатацию и объясним, как искать аналогичные баги в других проектах.

Что такое CVE-2026-32914: суть уязвимости OpenClaw​

По данным NVD, уязвимость затрагивает OpenClaw версий до 2026.3.12 и сводится к недостаточному контролю доступа в обработчиках команд /config и /debug. Пользователи с правами command-authorized (нижний уровень привилегий) получают доступ к поверхностям, предназначенным исключительно для owner-уровня. Атакующий может читать и изменять привилегированные настройки конфигурации, потому что проверка owner-level permissions попросту не вызывается.

Ключевые параметры:

Параметр	Значение
CVE ID	CVE-2026-32914
CVSS 4.0 Base Score	8.7 (HIGH)
CWE	CWE-863 - Incorrect Authorization
Затронутый продукт	openclaw < 2026.3.12
Вектор CVSS 4.0	CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Вектор атаки	Сетевой (AV:N)
Сложность	Низкая (AC:L)
Attack Requirements	Нет (AT:N)
Требуемые привилегии	Низкие (PR:L)
Взаимодействие пользователя	Не требуется (UI:N)

Тут нечего теоретизировать. CVSS-вектор говорит прямо: сетевая атака, низкая сложность, нужен только низкопривилегированный аккаунт, жертве не нужно ничего делать. Все три компонента воздействия на уязвимую систему оценены как High (VC:H/VI:H/VA:H), при этом воздействие на последующие системы отсутствует (SC:N/SI:N/SA:N). На практике: атакующий получает полный контроль над конфигурацией экземпляра.

CWE-863: некорректная авторизация - почему это опаснее, чем кажется​

CWE-863 (Incorrect Authorization) часто путают с CWE-862 (Missing Authorization). Разница принципиальна для понимания бага в OpenClaw. При CWE-862 проверка авторизации отсутствует вообще - эндпоинт голый. При CWE-863 проверка есть, но она неправильная: система авторизует пользователя, но проверяет не тот уровень прав. Из-за этого баг сложнее заметить на код-ревью - строчка с проверкой на месте, просто проверяет не то.

В случае CVE-2026-32914 механизм авторизации OpenClaw проверяет, что пользователь имеет command-authorization - право выполнять команды. Но хендлеры /config и /debug требуют owner-level - более высокий уровень, зарезервированный для владельца экземпляра. Проверка owner-статуса в этих хендлерах не вызывается.

Представьте двухэтажное здание. На первом этаже - проходная с бейджем (command-authorization). На втором - серверная, куда пускают только руководство (owner). Дверь на второй этаж существует, замок на ней висит, но он считывает тот же бейдж сотрудника, что и проходная. Любой прошедший проходную спокойно поднимается в серверную.

Именно поэтому CWE-863 регулярно приводит к вертикальной эскалации привилегий - пользователь с легитимным низким уровнем доступа поднимается до административного.

Broken access control в OpenClaw: анатомия бага на уровне логики​

Чтобы понять, как эксплуатировать CVE-2026-32914, нужно разобрать архитектуру авторизации OpenClaw. Из описания уязвимости и данных NVD вытекает двухуровневая модель:

Уровень 1 - Command-authorized. Пользователь авторизован для выполнения команд. Базовый уровень - любой легитимный участник с минимальными правами.

Уровень 2 - Owner. Владелец экземпляра. Доступ к конфигурации, отладочным интерфейсам, управлению привилегиями других пользователей.

Хендлеры большинства маршрутов корректно проверяют нужный уровень. Но /config и /debug - owner-only поверхности - проверяют только command-authorization. Вероятная причина: при регистрации маршрутов к этим хендлерам не прикрутили middleware owner-проверки, или проверка жила в отдельной функции, которую тупо забыли вызвать.

Я такое вижу постоянно в проектах, где авторизация реализована не на уровне фреймворка (декораторы, middleware-цепочка), а вручную внутри каждого хендлера. Разработчик добавляет новый эндпоинт, копипастит шаблон из соседнего хендлера с command-level проверкой, забывает добавить owner-check - и критический маршрут оказывается открытым для всех авторизованных пользователей.

Что даёт доступ к /config​

Хендлер /config управляет привилегированными настройками экземпляра OpenClaw. По описанию CVE, атакующий может «read or modify privileged configuration settings restricted to owners». На практике:

• Чтение текущей конфигурации, включая привилегированные настройки владельца. Конкретный состав зависит от экземпляра, но потенциально - токены, ключи интеграций, параметры безопасности (нужно проверять на конкретной инсталляции)
• Модификация конфигурации - возможность изменить поведение всего экземпляра
• Отключение защитных механизмов через изменение параметров безопасности

Что даёт доступ к /debug​

Debug-эндпоинты - мечта пентестера. Они проектируются для разработчиков и выдают информацию, которую боевой API никогда не раскроет. Конкретный объём в OpenClaw /debug нужно проверять на живой инсталляции, но в общем случае debug-хендлеры выплёвывают:

• Внутреннее состояние приложения
• Переменные окружения
• Стеки вызовов и пути в файловой системе
• Активные сессии и их метаданные

В связке с config handler это особенно неприятно: атакующий сначала получает полную картину через /debug, затем точечно модифицирует конфигурацию через /config. Разведка → удар.

Эскалация привилегий через config handler: пошаговая эксплуатация​

Ниже - концептуальный сценарий эксплуатации CVE-2026-32914. NVD описывает /config и /debug как «command handlers», что характерно для бот-фреймворков (Discord, IRC и т.д.), а не REST API. В реальности эксплуатация скорее всего происходит через отправку команд боту в чате, а не через HTTP-запросы. Приведённые curl-примеры - упрощённая иллюстрация логики атаки, не воспроизводимый PoC.

Шаг 1. Получение command-authorized сессии​

Атакующему нужен аккаунт с минимальными правами - command-authorization. Ничего привилегированного: в большинстве инстансов OpenClaw такой уровень имеет каждый легитимный участник.

# Аутентификация и получение токена сессии
# (механизм зависит от настройки экземпляра)
curl -X POST https://target-openclaw.example/auth \
  -H "Content-Type: application/json" \
  -d '{"username":"regular_user","password":"password123"}'

На выходе - токен или cookie с command-level правами.

Шаг 2. Разведка через /debug​

Начинаем с debug-хендлера - вытягиваем максимум информации о конфигурации:

# Запрос к debug-хендлеру с токеном обычного пользователя
curl -X GET https://target-openclaw.example/debug \
  -H "Authorization: Bearer <command_authorized_token>" \
  -v

Если экземпляр уязвим (версия < 2026.3.12), вместо 403 Forbidden прилетит 200 OK с отладочной информацией. Смотрите на заголовки ответа и структуру JSON - там будут подсказки по доступным параметрам конфигурации.

Шаг 3. Чтение привилегированной конфигурации​

# Чтение owner-only конфигурации
curl -X GET https://target-openclaw.example/config \
  -H "Authorization: Bearer <command_authorized_token>"

Ответ содержит настройки, доступные только владельцу. Зафиксируйте текущие значения - они понадобятся для понимания масштаба возможных изменений.

Шаг 4. Модификация конфигурации (вертикальная эскалация)​

Критический момент: CVE-2026-32914 позволяет не только читать, но и изменять конфигурацию. Информационная утечка превращается в полноценную эскалацию привилегий:

# Модификация привилегированных настроек
# (структура параметров зависит от конкретного экземпляра)
curl -X PUT https://target-openclaw.example/config \
  -H "Authorization: Bearer <command_authorized_token>" \
  -H "Content-Type: application/json" \
  -d '{"setting_name":"value"}'

На этом этапе атакующий с command-level правами фактически обладает owner-level контролем над экземпляром. Занавес.

Обнаружение уязвимости: методология для пентестеров​

Поиск скрытых эндпоинтов с ffuf​

Даже если вы не знаете о /config и /debug, стандартный фаззинг маршрутов их найдёт:

# Фаззинг эндпоинтов с авторизованной сессией
ffuf -u https://target-openclaw.example/FUZZ \
  -w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt \
  -H "Authorization: Bearer <command_token>" \
  -mc 200,201,204 \
  -fc 401,403

Ключевой момент: фаззинг с авторизованной сессией (даже низкопривилегированной) покажет эндпоинты, скрытые от неаутентифицированных пользователей. Broken access control уязвимости именно так и вылезают - эндпоинт отвечает 200 там, где должен возвращать 403.

Проверка разграничения прав в Burp Suite​

Для систематической проверки broken access control в OpenClaw - расширение AuthMatrix или ручной подход:

1. Соберите карту запросов владельца (owner) через Burp Proxy
2. Повторите каждый запрос с токеном command-authorized пользователя
3. Сравните ответы: если owner-only эндпоинт возвращает 200 с command-level токеном - это CVE-2026-32914

# Burp Repeater: замена токена в перехваченном запросе
# Оригинальный запрос владельца:
GET /config HTTP/1.1
Host: target-openclaw.example
Authorization: Bearer <owner_token>

# Модифицированный запрос с токеном обычного пользователя:
GET /config HTTP/1.1
Host: target-openclaw.example
Authorization: Bearer <command_authorized_token>

Оба запроса возвращают идентичный ответ с конфигурационными данными? Уязвимость подтверждена.

Автоматизация проверки с feroxbuster​

Для более агрессивного сканирования с рекурсивным обходом:

feroxbuster -u https://target-openclaw.example \
  -H "Authorization: Bearer <command_token>" \
  -w /usr/share/seclists/Discovery/Web-Content/common.txt \
  --status-codes 200 \
  --filter-status 401 403 \
  -d 2

Параметр -d 2 ограничивает глубину рекурсии двумя уровнями - хватит для обнаружения /config и /debug, но сервер не ляжет.

Обход авторизации REST API: почему стандартные защиты не работают​

CVE-2026-32914 показывает системную проблему, которую я регулярно встречаю в bug bounty: авторизация проверяется на неправильном уровне абстракции.

Антипаттерн: проверка в хендлере, а не в middleware​

Если авторизация реализована внутри каждого хендлера - рано или поздно кто-то забудет добавить проверку. Концептуально ошибка выглядит так:

# Псевдокод: ТАК сделано в уязвимой версии OpenClaw
# (демонстрация концепции, не реальный код OpenClaw)

@app.route("/config")
@require_command_auth  # Проверяет command-level - НЕДОСТАТОЧНО
def config_handler():
    # Отсутствует: @require_owner
    return get_privileged_config()

@app.route("/debug")
@require_command_auth  # Та же ошибка
def debug_handler():
    return get_debug_info()

Правильный паттерн: централизованная проверка​

# Псевдокод: КАК должно быть
# Owner-only маршруты регистрируются с owner-middleware

@app.route("/config")
@require_owner  # Проверяет owner-level
def config_handler():
    return get_privileged_config()

# Или: централизованная маршрутная таблица
OWNER_ROUTES = ["/config", "/debug", "/admin"]
# Middleware автоматически применяет owner-check ко всем маршрутам из списка

Разница - в точке применения проверки. Когда авторизация привязана к маршрутной таблице или группе роутов, забыть о ней при добавлении нового эндпоинта значительно сложнее. Лично я на проектах всегда настаиваю на deny-by-default: новый маршрут без явного указания уровня доступа - автоматически закрыт для всех кроме owner.

Горизонтальная и вертикальная эскалация: что делать после получения доступа​

С точки зрения MITRE ATT&CK, эксплуатация CVE-2026-32914 относится к

Ссылка скрыта от гостей

. Но последствия зависят от того, что лежит в конфигурации:

Вертикальная эскалация - прямой результат бага. Пользователь с command-level поднимается до owner-level через доступ к конфигурации.

Горизонтальная эскалация - возможна, если /debug раскрывает информацию о других пользователях или сессиях.

Lateral movement - если конфигурация содержит токены интеграций с внешними сервисами, атакующий получает плацдарм для движения по инфраструктуре. На практике это самый неприятный сценарий - один бот-инстанс с утёкшими токенами может открыть дорогу к Slack, GitHub, CI/CD и дальше по цепочке.

Несанкционированный доступ к конфигурации: детекция атаки​

Для операторов OpenClaw, которые ещё не обновились, - признаки эксплуатации:

# Подозрительные паттерны в логах:
# 1. Запросы к /config или /debug от non-owner пользователей
# 2. PUT/PATCH на /config с нестандартных IP или в нетипичное время
# 3. Серия GET к /debug, потом точечный PUT к /config
#    (классика: разведка → удар)

# Grep-фильтр для access-лога:
grep -E "(GET|PUT|PATCH|POST) /config" access.log | \
  grep -v "owner_user_id" | \
  sort -t' ' -k4 | head -50

Обратите внимание на паттерн: сначала серия GET к /debug, затем один-два точечных PUT к /config. Это характерный поведенческий маркер осознанной эксплуатации, а не случайного обращения. Если видите такую последовательность от одного user_id - уже пора разбираться.

Устранение уязвимости CVE-2026-32914​

Обновление до версии 2026.3.12 или выше - единственный надёжный путь. В ней проверка owner-level permissions добавлена к хендлерам /config и /debug.

Временные меры (если немедленное обновление невозможно):

1. Ограничить доступ к /config и /debug на уровне reverse proxy:

# nginx: ограничение доступа по IP
location ~ ^/(config|debug) {
    allow 10.0.0.0/8;  # Только внутренняя сеть
    deny all;
}

1. Усилить мониторинг обращений к этим эндпоинтам
2. Провести аудит логов - возможно, эксплуатация уже состоялась

Поиск аналогичных багов: чеклист для пентестера​

CVE-2026-32914 - не уникальный случай. Broken access control стабильно сидит на первом месте в

Ссылка скрыта от гостей

. Вот чеклист для поиска аналогичных дыр в других проектах:

1. Определите уровни привилегий - сколько ролей в системе? Какие эндпоинты привязаны к каждой?
2. Составьте матрицу доступа - для каждого эндпоинта зафиксируйте ожидаемый уровень
3. Проверьте каждую комбинацию - с токеном каждой роли стучитесь в эндпоинты более высокого уровня
4. Особое внимание - служебным маршрутам: /debug, /config, /admin, /metrics, /health - их чаще всего забывают закрыть
5. Проверьте HTTP-методы отдельно - GET к /config может быть закрыт, а PUT - нет (или наоборот)
6. Ищите несогласованность middleware - если 9 из 10 эндпоинтов одной группы защищены, десятый с высокой вероятностью пропущен

В bug bounty именно такие системные проверки дают стабильный поток находок. Одиночный CVE-2026-32914 - симптом архитектурной проблемы. Если /config и /debug не были покрыты owner-check, проверьте и остальные служебные эндпоинты - с большой вероятностью там тоже что-нибудь торчит наружу.

Выводы​

CVE-2026-32914 - CVSS 8.7 (HIGH), вертикальная эскалация привилегий в OpenClaw через некорректную авторизацию (CWE-863) в обработчиках /config и /debug. Эксплуатация тривиальна: command-authorized аккаунт и один запрос. Обновляйтесь до 2026.3.12, прогоните логи через grep из раздела про детекцию, и используйте этот кейс как напоминание: debug-эндпоинт без owner-level проверки - не техдолг, а критическая уязвимость с готовым вектором эксплуатации.