В подсистеме подключения устройств OpenClaw за шесть недель выявили шесть серьезных уязвимостей класса CWE-863, связанных с некорректной авторизацией. Речь идет об одном и том же модуле device pairing, который отвечает за одобрение подключения новых устройств к системе. Все найденные проблемы опираются на один архитектурный изъян: система доверяет факту одобрения подключения, но не проверяет, какими реальными правами обладает одобряющий.
OpenClaw - популярный ИИ-агент с 348 000 звезд на GitHub, широко используемый для автоматизации, интеграций и работы с внешними устройствами. Именно поэтому любые сбои в системе контроля доступа здесь превращаются не в абстрактную "багу в коде", а в прямую возможность для злоумышленника получить расширенные права в инфраструктуре, где задействован агент.
Последней из шести на данный момент стала уязвимость CVE-2026-33579 с оценкой 8.6 по шкале CVSS. Ее закрыли 29 марта в версии 2026.3.28. Проблема заключалась в том, что команда `/pair approve` не передавала в модуль авторизации реальные права пользователя, инициирующего одобрение. В результате любой аккаунт с минимальной ролью `operator.pairing` мог зарегистрировать новое устройство, запросив для него привилегию `operator.admin`, а затем тут же самостоятельно одобрить этот запрос. Фактически это означало эскалацию прав через процедуру подключения устройств.
Предыдущая уязвимость в том же модуле, CVE-2026-32922 (CVSS 9.9), еще более показательно демонстрировала глубину архитектурной проблемы. Эксплуатируя ошибку в эндпоинте ротации токенов, злоумышленник мог обойти проверку прав и получить доступ к действиям, которые изначально ему не полагались. Этот баг был исправлен в версии 2026.3.11, однако пользователи, ограничившиеся установкой того патча и не обновившиеся до более свежих версий, остались уязвимыми для новой атакующей техники, реализованной через CVE-2026-33579.
Общим знаменателем всех шести CVE стало именно отсутствие полноценной, сквозной модели авторизации в подсистеме pairing. Патчи каждый раз "затыкали" конкретную дыру - исправляли отдельный маршрут выполнения кода, отдельный эндпоинт или конкретный сценарий работы. Но базовый принцип проверки прав - кто и на основании каких полномочий может регистрировать и одобрять новые устройства - архитектурно не менялся. Таким образом, разработчики и исследователи фактически играли в "кошки-мышки" с уязвимостями, устраняя симптомы, но не первопричину.
Ситуацию делает особенно опасной масштабная распространенность небезопасных инсталляций OpenClaw. По данным SecurityScorecard, в феврале в открытом доступе было обнаружено более 135 000 экземпляров этого ИИ-агента. Причем примерно 63% из них работали без какой-либо аутентификации - то есть к их интерфейсу можно было подключиться анонимно. К концу марта, по данным Censys, количество доступных извне экземпляров снизилось примерно до 63 000. Это заметное сокращение, но все равно достаточно большое число, чтобы говорить о реальном поле для массовой эксплуатации.
Отсутствие аутентификации означает, что любой, кто может достучаться до интерфейса OpenClaw, способен получить права на подключение устройств. А именно через этот механизм и реализуются описанные уязвимости с некорректной авторизацией. В такой конфигурации атаку можно проводить удаленно, без предварительного проникновения в сеть компании: достаточно найти доступный инстанс и использовать известный эксплойт.
Исследователи подчеркивают, что пока в модуле подключения устройств не будет проведен полноценный архитектурный аудит и не будет переработана сама модель авторизации, появление новых CVE - лишь вопрос времени. Текущие исправления выглядят как локальные заплатки, минимально затрагивающие общий дизайн системы. При этом каждая новая комбинация ролей, эндпоинтов и маршрутов вызовов в модуле pairing потенциально может порождать еще одну уязвимость класса CWE-863.
Разработчики OpenClaw рекомендуют пользователям немедленно обновиться как минимум до версии 2026.3.28, где закрыта CVE-2026-33579, а также включить аутентификацию во всех доступных инстансах. Отдельно подчеркивается важность постоянного мониторинга канала безопасности проекта и установки всех последующих обновлений, так как подсистема pairing остается под пристальным вниманием исследователей и, вероятно, атакующих.
Для администраторов и DevOps-команд это означает, что простая установка одного патча "по случаю громкой CVE" недостаточна. Необходимо выстроить полноценный процесс управления уязвимостями: отслеживание новых версий, регламентное обновление, тестирование после апдейтов и обязательное включение всех доступных механизмов аутентификации и авторизации. Особенно это критично для публично доступных экземпляров, которые торчат в интернет без дополнительного слоя защиты, вроде VPN или прокси с жесткими ACL.
С точки зрения архитектуры безопасных систем происшествие с OpenClaw хорошо иллюстрирует типичную ловушку: разработчики сосредотачиваются на логике бизнес-функций, но откладывают продуманную модель прав "на потом". На первых этапах это позволяет быстрее выпускать фичи, однако в момент, когда продукт становится массовым и критичным, накопленные компромиссы в области безопасности вылезают наружу серией уязвимостей. В случае OpenClaw популярность и обилие интеграций делают любые огрехи в авторизации особенно болезненными.
Еще один важный вывод - недопустимость установки систем по умолчанию "с открытыми дверями". Статистика, по которой более половины экземпляров OpenClaw работали без аутентификации, демонстрирует не только проблемы кода, но и проблемы практики внедрения. Даже идеальная модель авторизации бесполезна, если администратор оставляет сервис анонимно доступным в интернет. Поэтому помимо обновлений кода необходимо ужесточать стартовую конфигурацию: требовать обязательную настройку аутентификации при первом запуске, выводить предупреждения и блокировать работу без базовой защиты.
Для компаний, уже использующих OpenClaw в продакшене, имеет смысл провести собственный мини-аудит:
- проверить, не доступен ли агент напрямую из интернета;
- оценить, настроена ли аутентификация и какие механизмы используются;
- проанализировать, какие роли выданы техническим и сервисным учетным записям;
- убедиться, что все инстансы обновлены как минимум до версии 2026.3.28 или выше.
Организациям с повышенными требованиями к безопасности стоит рассмотреть дополнительное сегментирование сетей и ограничение доступа к OpenClaw только из доверенных подсетей. При наличии SIEM или систем логирования имеет смысл завести отдельные алерты на подозрительные операции с подключением устройств: массовые запросы pairing, неожиданные регистрации администраторских устройств, аномальное поведение аккаунтов с минимальными правами.
Разработчикам OpenClaw, в свою очередь, неизбежно придется выходить за рамки точечных патчей. Пересмотр модели авторизации в модуле pairing, внедрение четкого разграничения ролей, принципа наименьших привилегий и детализированного логирования действий - это шаги, без которых серия CVE рискует продолжиться. В долгосрочной перспективе куда эффективнее один раз реформировать архитектуру контроля доступа, чем бесконечно закрывать новые дыры, возникающие на старом фундаменте.
История с шестью уязвимостями за полтора месяца показывает, что для современных ИИ-агентов и автоматизационных платформ безопасность уже не может быть второстепенной задачей. Они становятся связующей тканью между сервисами, устройствами и данными, и любая ошибка в авторизации в таком узле превращается в удобный трамплин для атак. В случае OpenClaw у пользователей пока есть время отреагировать - обновиться, включить аутентификацию и пересмотреть настройки. Но откладывать эти шаги - значит сознательно оставлять дверь открытой.
