Коротко

  • Главный риск — открытый gateway. Если он слушает не 127.0.0.1, а наружу, и токена на нём нет, любой, кто его нашёл, получает удалённое выполнение кода на твоей машине. В феврале 2026 так нашли открытыми больше сорока тысяч установок.
  • Три вещи, которые стоит проверить сегодня: на каком интерфейсе слушает gateway, есть ли на нём токен, не старше ли твоя версия, чем 2026.1.29 (в ней закрыли ClawBleed).
  • Все три проверяются одной командой. Скачай и запусти:
curl -sO https://raw.githubusercontent.com/cain66666/openclaw-hardening-check/main/openclaw-hardening-check.mjs
node openclaw-hardening-check.mjs

Один файл на Node, без зависимостей. Скачивается отдельным шагом, так что можешь прочитать его перед запуском.

  • Она только читает. Ничего не чинит, никуда не отправляет, секреты не печатает. Что найдёт — чинить тебе. Как именно, написано ниже.

Я не исследователь безопасности. Я держу OpenClaw и Hermes в проде и обычно узнаю о проблеме, когда меня будят. Почти всё, что здесь написано, — это то, на чём я сам обжигался, сведённое в список, который я прогоняю на машинах, за которые отвечаю. Это не аудит и не гарантия. Зелёный результат означает только, что перечисленные ниже проверки прошли, — и ничего больше.

Что на самом деле угрожает self-hosted OpenClaw

Давай без абстракций. В январе 2026 в OpenClaw нашли CVE-2026-25253 — уязвимость, которую назвали «ClawBleed», с оценкой CVSS 8.8. Механика простая и от этого неприятная: Control UI слепо доверял параметру gatewayUrl в адресе и автоматически подключался к нему, отдавая твой auth-токен gateway тому, кто подсунул тебе ссылку. То есть достаточно было открыть подготовленную страницу — и токен утёк, а с ним и управление агентом.

К началу февраля команды, сканировавшие интернет, сообщали о больше чем сорока тысячах открытых инстансов, большинство из них уязвимы, и больше двенадцати тысяч эксплуатируемых до RCE. Отдельно исследователи безопасности нашли в ClawHub — маркетплейсе скилов — больше восьмисот вредоносных плагинов, по мере того как реестр разрастался в начале 2026. Уязвимость закрыли в версии 2026.1.29.

Детали самой уязвимости выше (серьёзность, версия с фиксом, механика) — из NVD; цифры по открытым инстансам — от команд, сканировавших интернет, и они разнятся в зависимости от того, кто и когда сканировал. Это нижние, хорошо подтверждённые оценки, а не раздутые, что разошлись первыми. Суть от этого не меняется: автономный агент с доступом к твоей почте, файлам и подпискам, торчащий наружу, — это та цель, за которой охотятся. Дальше — по пунктам, что с этим делать.

Твой gateway торчит в интернет?

Это самый важный пункт, поэтому он первый. Gateway OpenClaw должен слушать loopback — 127.0.0.1, — а не 0.0.0.0 и не внешний интерфейс. Если он слушает наружу и на нём нет токена, любой, кто нашёл твой IP и порт, управляет твоим агентом.

Тут есть ловушка, в которую легко попасть и не заметить: в контейнере дефолт другой. Если ты гоняешь OpenClaw в Docker, Podman или Kubernetes, а Tailscale не настроен, режим bind по умолчанию становится auto, и это разворачивается в 0.0.0.0 — потому что изнутри контейнера loopback недостижим с хоста. То есть ты ничего не менял, оставил дефолт, «как в доке», — а gateway открыт наружу. На голом сервере дефолт безопасный, в контейнере — нет, и об этом молчат почти все гайды «подними за 30 минут».

Проверять надо не только конфиг, но и реальность. Конфиг может говорить loopback, а флаг в командной строке или в systemd-юните переопределяет его на лету. Смотри, что процесс gateway реально слушает, — на Linux это видно по слушающим сокетам. Конфиг — это намерение, сокет — факт.

Аутентификация — и откуда токен берётся на самом деле

Токен gateway должен существовать, быть длинным и не быть дефолтным плейсхолдером. Это очевидно. Неочевидно другое, и на этом я потерял вечер.

На версиях 2026.6.x gateway-сервис резолвит auth-токен из конфига в первую очередь: читает gateway.auth.token в ~/.openclaw/openclaw.json, и OPENCLAW_GATEWAY_TOKEN, который ты считал главным, может ему тихо проиграть (прямые локальные клиенты по-прежнему предпочитают env-токен; управляемый gateway-сервис — конфиг). У меня после обновления gateway поднялся, бот отвечал, всё выглядело живым — но панель управления показывала «gateway offline», а в логах висел token_mismatch. Я честно гонялся за окружением: проверял, что переменная выставлена, что она совпадает, перезапускал. Не помогало, потому что gateway сверял присланный токен с тем, что лежал в конфиге, а там его вообще не было — при обновлении его вычистили, полагаясь на старое поведение «берём из окружения».

Урок здесь не «вот баг OpenClaw», а более общий: «токен задан» и «gateway этот токен видит» — это разные утверждения. Прежде чем считать gateway защищённым, узнай, откуда именно твоя версия читает токен, и проверь, что он там есть. Если у тебя есть строка вроде secretref-env:НАЗВАНИЕ или $ПЕРЕМЕННАЯ — это ссылка на переменную окружения, а не сам секрет; если переменная не выставлена, токена по факту нет, и на версии с token-режимом gateway просто не стартует.

Версия и пин

Не тяни latest вслепую. Я понимаю соблазн — поставил один раз openclaw@latest, и оно всегда свежее. Ровно так я и словил многодневный разбор завалов.

Незапиненный latest в один прекрасный день притащил новую минорную версию, в которой поменялись контракты: расписания уехали из файлов в SQLite, форма конфига стала другой, часть настроек, которые раньше принимались, стала отвергаться. Ничего из этого не было в changelog как «ломающее» — просто в следующее утро установка на свежей машине перестала подниматься, и я несколько дней разбирал, что именно съехало.

Здесь два риска, и второй серьёзнее первого. Первый — чужая регрессия: свежая версия что-то сломала, и ты узнаёшь об этом в проде. Второй — цепочка поставок: если релиз когда-нибудь окажется скомпрометированным, latest затянет его прямо в автономного агента, у которого есть доступ к твоим данным и право действовать. Пин версии — это не про «отстать от прогресса». Это про то, чтобы обновление было твоим решением, принятым тогда, когда ты к нему готов, а не сюрпризом от npm install.

Как я это делаю у себя: версия зафиксирована на конкретном номере, новая проходит проверку прежде, чем я разрешаю ей раскатиться, и только потом пин двигается вперёд. Фиксы безопасности ты так всё равно получаешь — но не вместе с чужой регрессией в нагрузку. И да, проверь заодно, что твоя текущая версия не старше 2026.1.29, иначе ты всё ещё уязвим к ClawBleed, о котором шла речь выше.

Сторонние скилы и плагины

Восемьсот с лишним вредоносных скилов в ClawHub — это не абстрактная статистика. Скил — это код, который исполняется внутри твоего агента, с его правами и его доступами. Ставя сторонний скил, ты пускаешь чужой код в систему, которая ходит в твою почту и файлы.

Практика простая: знай, что у тебя установлено, и отделяй комплектное от стороннего. Комплектные плагины идут в поставке и им можно доверять примерно так же, как самому OpenClaw. Всё, что ты доставил из маркетплейса, — это отдельное решение о доверии, и его стоит принимать осознанно, а не «поставил, чтобы попробовать, и забыл».

«Настроено» не значит «применено»

Короткий, но важный пункт, потому что он превращает все предыдущие в ложное чувство безопасности. Ты можешь поменять security-настройку, файл запишется верно, а к живому агенту изменение не применится.

У меня так и было: сменил активную настройку, файл конфига обновился правильно, status показывал новое значение — а бот продолжал работать по-старому. Оказалось, у gateway сдох вотчер, который следит за конфигом: система была забита, и кончился лимит inotify-вотчеров в ядре. Вотчер молча умер, hot-reload перестал срабатывать, и каждое изменение конфига выглядело применённым, хотя не применялось. Вылечил перезапуском gateway — он пересобирает состояние из файла с нуля.

Мораль: сменив что-то, что влияет на безопасность, проверяй по живому runtime, а не по тому, что файл записался. «Записано» и «действует» — снова два разных утверждения, и разница между ними — это как раз то окно, в котором ты думаешь, что защищён, а на деле нет.

Проверить всё это одной командой

Я вынес эти проверки в маленькую утилиту — openclaw-hardening-check. Это один файл на Node без единой зависимости. Она читает твой конфиг и говорит, что не так: на каком интерфейсе слушает gateway, есть ли токен и не слабый ли он, не старше ли версия, чем фикс ClawBleed, какие плагины у тебя не из комплекта, какие права у файлов с секретами.

Что она не делает, важно не меньше. Она ничего не чинит — только читает. Она не ходит в сеть — ни телеметрии, ни проверок онлайн, ничего. И она никогда не печатает значение секрета — только «есть/нет», источник и длину, — специально чтобы её вывод можно было безопасно вставить в issue на GitHub. Там, где она не может честно что-то определить, она пишет «не смог проверить», а не выдумывает результат. Это осознанный выбор: инструмент про безопасность, который врёт «всё хорошо», хуже, чем отсутствие инструмента.

И она скачивается файлом, который можно прочитать перед запуском. Инструмент про безопасность, который просит выполнить себя вслепую через пайп в шелл, доверия не заслуживает.

Чего этот чек-лист не может

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

Если ты держишь на этом агенте что-то серьёзное — чувствительные данные, деньги, доступы клиентов, — тебе нужен настоящий специалист по безопасности и настоящая проверка, а не чек-лист от практика. Я говорю это не чтобы прикрыться, а потому что видеть границы своего инструмента — часть того, чтобы им можно было пользоваться.

Если не хочешь делать это сам

Всё вышеописанное — работа, и она не заканчивается: OpenClaw обновляется, контракты меняются, и каждое обновление — это снова свериться, что ничего не съехало. Этим я и занимаюсь. Если держать и защищать этот стек самому не хочется, Cain держит OpenClaw и Hermes вместе, на зафиксированной версии, которая проходит проверку прежде, чем ей разрешат раскатиться, и на выделенном под тебя сервере. Фиксы безопасности до тебя доезжают, чужие регрессии — нет. Это одна из опций, а не единственный правильный ответ: если ты готов держать всё сам, этот чек-лист и утилита выше — то, с чего я бы начал.

Частые вопросы

Безопасно ли держать OpenClaw у себя? Да, если настроить. OpenClaw даёт тебе полный контроль, но и полную ответственность: дефолты не всегда безопасны (особенно в контейнере), а между версиями меняется поведение. Пройди пункты выше — начиная с того, торчит ли gateway наружу.

Мой gateway открыт в интернет? Проверь, на каком интерфейсе он реально слушает, а не только что написано в конфиге. Должен быть 127.0.0.1. В контейнере дефолт разворачивается в 0.0.0.0 — это надо явно закрывать.

Что такое ClawBleed и затронут ли я? CVE-2026-25253 — утечка auth-токена gateway через доверенный параметр gatewayUrl, CVSS 8.8, закрыта в 2026.1.29. Если твоя версия старше — ты уязвим, обновляйся.

Откуда OpenClaw читает токен gateway? На 2026.6.x gateway-сервис резолвит его из конфига в первую очередь (gateway.auth.token), так что env-токен может проиграть конфигу. Проверь, что токен реально лежит там, откуда его читает твоя версия.

Пинить версию или тянуть latest? Пинить. latest однажды затянет ломающую или скомпрометированную версию в автономного агента с доступом к твоим данным. Обновляйся осознанно.

Безопасны ли скилы из ClawHub? Сторонний скил — это чужой код в твоём агенте. В маркетплейсе находили больше восьмисот вредоносных. Ставь осознанно и знай, что у тебя установлено.

Как проверить, что мой OpenClaw защищён? Пройди чек-лист выше или прогони openclaw-hardening-check — она проверит эти пункты и ничего при этом не сломает и не отправит.

Илья Прудников держит приватные развёртывания OpenClaw и Hermes. Утилита из статьи — тот самый чек-лист, вынесенный в код и сделанный безопасным для публикации. Автор не специалист по безопасности; это чек-лист оператора, и README утилиты так же прямо говорит о её ограничениях.