OpenHands SDKに認証不要RCE｜1.52.0更新と公開ポートの点検

AIエージェントの実行環境を作るOpenHands Software Agent SDKに、認証なしでサンドボックス内のコマンドを実行される脆弱性CVE-2026-112346が公表されました。影響するのは1.52.0未満です。DockerWorkspaceまたはApptainerのワークスペース起動機能を利用し、そのエージェントサーバーの公開ポートへ第三者が到達できる構成では、1.52.0以降への更新と稼働中ワークスペースの再作成を優先してください。

CVE公式レコードは、エージェントサーバーが全ネットワークインターフェースを表す0.0.0.0で待ち受け、session_api_keysが空のため認証が既定で無効になると説明しています。攻撃者が公開ポートへ到達すると、HTTPまたはWebSocket経由でサンドボックス内のシェルコマンドをrootとして実行し、マウントしたワークスペースや平文のシークレットストアを読めるおそれがあります。CVSS v4.0は9.3で深刻度はCriticalです。

ただし、ここでいうrootはサンドボックス内のrootです。ホストOSのroot権限やコンテナ脱出が確認されたという意味ではありません。ホスト側への影響は、コンテナへ渡したボリューム、ソケット、環境変数、クラウド資格情報などで変わります。本稿は2026年10月29日にCVEレコード、開発元の修正PR・コミット・リリースを確認したニュース解説であり、攻撃を再現した実測結果ではありません。

隔離した実行環境でも管理ポートが入口になる

AIエージェント用サンドボックスは、生成されたコードやコマンドを本体のアプリケーションから分離するために使います。しかし、サンドボックスを操作するエージェントサーバーは、ファイル操作やシェル実行を受け付ける管理面です。コンテナ境界が保たれていても、この管理面を認証なしでネットワークへ公開すれば、到達した相手に本来の管理機能を使われます。

成立条件は「1.52.0未満を使う」「影響するワークスペース起動機能を使う」「公開されたポートへ攻撃者が到達できる」の組み合わせです。クラウドVMでセキュリティグループが広い、共有開発ネットワークでホストのポートが他端末から見える、CIランナーが同一ネットワークの別ジョブと通信できる、といった構成は優先して確認します。インターネットに直接公開していなくても、社内LANや同じVPCから到達できれば条件を満たし得ます。

一方、該当SDKを依存関係に含むだけで直ちに外部から実行されるわけではありません。DockerWorkspaceやApptainerを使っているか、稼働時にどのアドレスとポートへ公開されるかを構成と実行状態の両方から調べます。CVEレコードは両ランチャーを対象に挙げていますが、今回確認できた開発元の修正差分はDockerWorkspaceのホスト側ポート公開を中心とする内容です。利用方式にかかわらず、修正版パッケージへ更新し、実際の待受状態を確認する判断が安全です。

修正はホスト側の公開先をループバックへ限定

開発元のPR #5209は、DockerWorkspaceのAPIポートと任意のVS Codeポートがホストの全インターフェースへ公開されていた点を修正しました。コンテナ内部のエージェントサーバーはDockerのポート転送を受けるため0.0.0.0で待ち受けたままですが、ホスト側の公開は127.0.0.1へ限定されます。修正コミットでは、例えばAPIポートが-p 127.0.0.1:{host_port}:8000になることを確認できます。

同じPRでは、ワークスペースクライアントが転送済みのセッションAPIキーを使うようになりました。新しいOH_SESSION_API_KEYS_0を優先し、旧SESSION_API_KEYをフォールバックとして扱います。ポートをループバックへ限定することと、認証キーを正しく伝えることは別の防御です。更新後も運用者が明示的に全インターフェースへ公開する構成へ戻せば、ネットワーク制御と認証が再び重要になります。

修正は1.52.0に収録されています。開発元リリースには「publish Docker ports on loopback」としてPR #5209が記載されています。バージョン確認はパッケージ管理ファイルだけでなく、実際に起動する仮想環境やコンテナイメージに対して行います。ロックファイルを更新しても、古いイメージや常駐プロセスを再作成していなければ旧コードが動き続けます。

最初に版数と公開ポートを棚卸しする

Python環境では、SDKを導入した同じ環境でパッケージ情報を確認します。パッケージ名や導入方法は構成により異なるため、次の例だけで存在しないと判断せず、uv.lock、poetry.lock、requirements.txt、コンテナのSBOMも照合してください。

python -m pip list | grep -i openhands
docker ps --format 'table {{.ID}}\t{{.Image}}\t{{.Ports}}\t{{.Names}}'
ss -lntp

docker psのPORTS欄で、管理ポートが0.0.0.0:...または[::]:...と表示される場合は、ホストの外部インターフェースでも待ち受ける可能性があります。127.0.0.1:...ならIPv4ループバックに限定されています。Dockerの表示だけで判断しにくい場合は、対象コンテナをdocker inspectし、NetworkSettings.PortsのHostIpとHostPortを確認します。IPv4とIPv6の両方を点検してください。

Apptainer利用時は、起動コマンド、サービス定義、ジョブスケジューラー、ファイアウォールの順にたどり、エージェントサーバーの待受アドレスと到達経路を確認します。Dockerと同じ表示やオプションを前提にしません。Kubernetesやホストのリバースプロキシを組み合わせている場合は、Service、Ingress、ポート転送、サイドカーも別の公開経路になり得ます。

更新は再作成と拒否確認まで行う

1.52.0以降へ更新したら、既存のワークスペース、コンテナ、常駐エージェントサーバーを停止して再作成します。その後、ホスト自身から正規クライアントが接続できることと、別ホストから同じポートへ接続できないことを比較します。認証キーを設定する構成では、正しいキーの要求は成功し、キーなしまたは誤ったキーの要求は拒否されることも確認します。

1. 実行環境の版が1.52.0以上であることを確認する
2. 古いコンテナとワークスペースを停止し、新しい依存関係で再作成する
3. ホスト側の公開先が127.0.0.1で、不要なIPv6公開がないことを確認する
4. 正規クライアントのHTTP・WebSocket操作が成功することを確認する
5. 別ホストとキーなし要求が拒否されることを確認する

ループバック限定は、同じホスト上の別プロセスからの接続までは防ぎません。複数利用者が共有する開発サーバー、侵害されたローカルプロセス、SSRFでローカル接続を代理できるサービスがある場合は、セッションAPIキー、実行ユーザーの分離、ホストのファイアウォールも併用します。Dockerソケットの管理権限を点検する実践解説も、同じホストへ強い管理経路を集めないための参考になります。

公開していた可能性がある環境は侵害調査を分けて行う

更新は今後の到達を防ぎますが、過去に実行されたコマンドや読み取られた秘密情報を元に戻しません。旧版の管理ポートが外部または共有ネットワークへ公開されていた場合は、稼働期間、公開元アドレス、コンテナログ、エージェントサーバーログ、シェル履歴、ワークスペース内の変更を保全して確認します。ログがないことを未侵害の証拠にせず、保持期間や出力設定も記録します。

マウントしたリポジトリに不審なコミット、ビルドスクリプト、依存関係、起動設定がないかを調べます。シークレットストアや環境変数にAPIキー、クラウド資格情報、GitHubトークン、SSH鍵を置いていた場合は、露出期間と権限を基に失効・再発行を判断します。単に値を置き換えるだけでなく、旧資格情報の利用ログ、作成された追加キー、変更された権限も追跡してください。

AIエージェントに渡した権限の範囲を確認する際は、MCPツールのコマンド注入後に確認する実行境界も参照できます。今回の入口はプロンプトインジェクションではなく、認証されていない管理ポートへのネットワーク到達です。原因を混同すると、プロンプト対策だけを強化して公開ポートを残す判断につながります。

複数環境がある場合は、まずインターネットや共有ネットワークから到達でき、書き込み可能なソースコードや本番用資格情報をマウントする環境を最優先にします。次に、到達範囲がVPC内や社内LANに限られる環境、最後に単独利用の端末でループバック限定を確認できる環境を処理します。資産台帳にはホスト名だけでなく、SDK版、起動方式、公開アドレス、マウント先、渡した資格情報、再作成日時、拒否試験の結果を残すと、後から更新漏れと影響範囲を追いやすくなります。

確認できていないことと判断の限界

CVEレコードの発見方法はUNKNOWNで、公開資料から実環境での悪用は確認できません。CISA KEVへの非掲載も「悪用がない」ことの証明には使えません。また、CVSSの高い値だけで全環境を同じ優先度にせず、実際の版、ランチャー、ポート到達性、マウントした資産、資格情報の権限で優先順位を決めます。

公式CVEレコードのdatePublicは2026年9月21日、CVEレコードの公開日時は10月26日です。この記事では後者をCVE公表日として扱い、修正PRがマージされた時期や1.52.0の公開日と区別しています。日付の違いを、攻撃開始日や一般への告知日と推測しません。