ハクソク

世界を動かす技術を、日本語で。

OpenCodeにおける認証されていないリモートコード実行

95日前原文(cy.md)

概要

  • OpenCodeの過去バージョンにおける深刻な未認証リモートコード実行脆弱性の概要
  • 自動起動するWebサーバが原因で、外部から任意のコマンド実行が可能
  • v1.1.10以降でサーバはデフォルト無効化、ただし有効化時は依然として危険
  • CORS設定やmdns利用時のリスクも指摘
  • ユーザー・開発者向けの対策と推奨事項を解説

OpenCodeの重大な脆弱性（CVE-2026-22812）

  • OpenCodeはAIコーディングアシスタントとして広く利用されるnpmパッケージ（opencode-ai）
  • v1.1.10未満では、未認証のWebサーバが自動起動し、外部からの接続で任意のコード実行が可能
  • サーバ起動時にユーザーへの通知なし、気づかずに攻撃対象となる危険
  • サーバAPIは以下のエンドポイントを公開
    • 任意シェルコマンド実行（POST /session/:id/shell）
    • インタラクティブ端末セッション生成（POST /pty）
    • 任意ファイルの読み取り（GET /file/content）
  • CORSポリシーは*.opencode.aiを許可
    • opencode.aiやサブドメインのXSSや侵害時に全ユーザーが危険に晒されるリスク

攻撃ベクトルと影響範囲

  • v1.0.216未満：任意のWebサイトからユーザーPC上でコード実行が可能
  • v1.1.10未満：ローカルマシン上のプロセスやlocalhost/127.0.0.1経由でコード実行可能
  • 全バージョン：サーバ有効時、ローカルプロセスやlocalhost経由のWebページから未認証で実行可能
    • --mdnsフラグ使用時はローカルネットワーク上の他マシンからも攻撃可能
    • サーバ稼働中の可視化手段がないため、ユーザーが危険に気づきにくい

実証コード（PoC）

  • ローカル攻撃例（サーバ有効時）
    • 任意プロセスからAPI経由でコマンド実行
    • 例（curl, jq利用）: 
      API="http://127.0.0.1:4096"
SESSION=$(curl -s -X POST "$API/session" -H "Content-Type: application/json" -d '{}' | jq -r '.id')
curl -s -X POST "$API/session/$SESSION/shell" \
  -H "Content-Type: application/json" \
  -d '{"agent":"build","command":"id > /tmp/pwned.txt"}'
  • ブラウザ経由の攻撃例（v1.0.216未満）
    • 任意Webサイトからfetchでコマンド実行
    • ChromeはLocal Network Access保護あり、Firefoxはサイレント実行

ユーザー向け緊急対策

  • opencode --versionでバージョン確認
  • v1.1.10以上へアップデート推奨
  • configファイル内のserver.port/server.hostname設定確認
  • --mdnsフラグは使用しない（0.0.0.0バインドで全ネットワークからアクセス可能）
  • サーバ有効時はopencode.aiやサブドメインへのアクセス禁止
  • サーバ有効時はローカルプロセスからも攻撃可能であることを認識

ベンダー対応・公開タイムライン

  • 2025-11-17：support@sst.devへ初報告（無反応）
  • 2025-12-27：GitHub Security Advisory提出（無反応）
  • 2025-12-29：他ユーザーが独自に公開報告
  • 2025-12-30：v1.0.216でCORS制限（サイレント修正）
  • 2026-01-09：v1.1.10でサーバデフォルト無効化
  • 2026-01-11：完全公開
  • CVE-2026-22812取得

推奨事項・今後の改善案

  • CORS許可範囲の最小化（v1.0.216で対応済み）
  • サーバデフォルト無効化（v1.1.10で対応済み）
  • 全APIリクエストで認証必須化
  • サーバ稼働時のUIやメッセージで明示的に通知
  • --mdns利用時のリスク明記
  • TLS通信の強制
  • GitHub Security AdvisoryとCVEの公開・管理
  • セキュリティ連絡先の監視体制強化
  • OpenCode運営・ユーザー間の信頼関係の明確化

まとめ・注意喚起

  • 旧バージョン利用者は即時アップデート必須
  • 詳細・最新情報は公式アドバイザリ参照
  • サーバ有効時のリスクを十分理解し、必要最小限の設定で利用すること

質問・連絡先: cy.md
最終更新日: 2026-01-12
コード分析協力: Claude AI (Opus 4.5)

追記
過去バージョンのOpenCodeは、Webブラウザ経由で任意コマンド実行を許可するサーバを自動起動していました。必ずv1.1.10以降を利用してください。

Hackerたちの意見

開示のタイムラインが心配だね。2025年11月17日に報告されて、何度も連絡を試みたのに「返事なし」って…あんまり良い印象じゃないよね。
└
オープンコードの開発者たちが真剣に取り組もうとしているみたいだね。
こんにちは、メンテナーです。セキュリティレポートの対応がうまくできていなかったです。利用が急増して、問題が山積みになってます。今週、どうやってこれを改善するかアドバイスをもらうために何人かと会う予定です。バグバウンティプログラムを資金調達して、監査も行うつもりです。
└
このプロジェクトが時間とともにどう成長するのか、すごく気になってる。最初のオープンソースのターミナルエージェントフレームワーク/ランナーとしてリードを取ってるみたいで、どんどん成長してる感じがする。組織が管理できる以上の速さで進んでいる気がする。プロジェクトの主な焦点は、コードベースの仕様や要件、開発よりも、プロジェクトの作業をどう整理するかにあるべきだと思うんだけど。開発のスピードを管理するために、チームがどんな一般的なアドバイスを受けているのか知りたいな。アナーキストの組織原則についても考えたことある？
└
オープンさに対するリスペクト。いい仕事してるし、頑張ってね。
└
元々はもっとポジティブなメッセージだったんだけど、状況を見てちょっと悲観的になっちゃった。何度も連絡を試みたのに返事がなかったっていうのは、ちょっと心配だよね。これは全然良い印象じゃないし、早く解決できることを願ってる。SSTフレームワークの頃からDaxを尊敬してるけど、これは本当に良くない状況だよ。2025年11月17日に報告されたのに、何度も「返事なし」って…確かに今はバグを報告してるけど、オープンコードが最も有名なオープンソースのコーディングエージェントだったから、もっと多くのサイバーセキュリティの人たちが見てたはずだよね。何かが実際に使われていた可能性もあると思う。だから、gvisorや適切なサンドボックス化の取り組みを行うべきだと思う。今の時点で、どれだけのバグが残っていて、RCEにつながる可能性があるのかもわからない。Dax、注意が散漫だと、敵はもっとバグやRCEの脆弱性を探し始めるから、時間が限られてると思う。できるだけ早くオープンコードをもっと安全にするための対策が進むことを願ってる。
└
これを引き受けてくれておめでとう、いい仕事だよ、リスペクト。
└
クロードにセキュリティの問題を直してもらって、二度と起こらないようにすればいいんじゃない？
└
大丈夫だよ、すぐに直せるなら問題ないはず。
└
頑張ってね！責任を持って正直にやってることを話してくれてありがとう。そういうのは簡単じゃないし、感謝してるよ！
どんどん新機能を追加するけど、肝心な部分は放置されてるよね。プランを売り始めた時に使うのやめた。Opencodeの主な目的は複数のモデルを使うことだったけど、モデル間でのコンテキスト共有が今は面倒で実用的じゃないって分かった。だから、Claude CodeとCodexを並行して使うことに戻った。とはいえ、複数のベンダーやモデルを活用できるオープンプラットフォームは絶対に必要だと思う。ただ、Anthropic、OAI、Googleの大手3社がそんなコントロールを手放すとは思えないな。
└
大手のCを使ってる私から言わせてもらうと、ampcode[0]とCrush[1]+z.ai GLMを追加でおすすめするよ。Ampは小さなユーティリティスクリプトや変更を無料でできるし（特に広告を有効にすれば）、Crush+GLMはClaudeやCodexが作ったプランに従うのが結構得意だよ。[0] https://ampcode.com/ [1] https://github.com/charmbracelet/crush
`session/:id/shell`は`session/:id/bash`でもあったし、元々は`session/:id/command`だったみたい。GitHubのコード検索の使い方が間違ってるかもしれないけど、これがプルリクエストの一部だったことは一度もないみたいだね。誰かが`dev`（デフォルトブランチ）にプッシュして、それがタグ付けされるっていうやり方も見直すべきかも。（`wip: bash`や`feat: bash commands`の下にさらにいくつかのコミットがある） https://github.com/anomalyco/opencode/commit/7505fa61b9caa17... https://github.com/anomalyco/opencode/commit/93b71477e665600...
なんじゃこれ、認証なしのRCE HTTPエンドポイントを作っただけじゃなくて、CORSバイパスまで追加してるのか… CLIツールの中で？それが静かにHTTPサーバーを立ち上げるって？
└
サーバーがあんなにオープンなのに、CORSポリシーがただの"*"じゃなかったのはちょっと驚きだね。
これはかなりひどいよ。サーバーがデフォルトで無効になってるのはいいとしても、一度動き出したらまだひどいことになる：> サーバーが有効になっていると、localhost/127.0.0.1から提供されるウェブページがコードを実行できる > サーバーが有効になっていると、認証なしで任意のローカルプロセスがコードを実行できる > サーバーが動いているときの表示がない（ユーザーは露出に気づかないかも） 申し訳ないけど、これはひどい。ちゃんとしたオープンなクロスプロバイダーのエージェントコーディングツールがあってほしいけど、これはTUIアプリへの人々の信頼を裏切るものに思える。私たちが彼らを信頼する理由の一部は、通常こういうことをしないからなんだよね。
└
Factoryのドロイドは、プロバイダーを超えたソリューションとしてはかなり良いね。
ブラウザがローカルサービスへのサイトからの呼び出しをブロックしてないなら、ブロックした方がいいよ：> ネットワーク境界シールド > ネットワーク境界シールド（NBS）は、外部ネットワーク（インターネット）から内部ネットワークへの攻撃に対する保護で、特にウェブブラウザがプロキシとして悪用される偵察攻撃に対して有効。 > NBSの主な目的は、公共のウェブサイトが内部ネットワークからリソースを要求する攻撃を防ぐこと（例：ローカルルーターの製造元のロゴなど）。NBSは、公共のインターネット上にホストされているウェブページがローカルIPアドレスに接続しようとしているのを検出する。NBSは、公共IPアドレスにホストされているウェブページからプライベートネットワークリソースへのHTTPリクエストのみをブロックする。ユーザーは特定のウェブページがローカルリソースにアクセスするのを許可できる（例：イントラネットサービスを使用する場合）。 https://jshelter.org/nbs/
今は成長が最優先で、セキュリティは二の次って感じだね。成長してる限り、ちょっとした問題があっても大した影響はないって思ってるのかな。
└
これからはセキュリティをもっと重視するようになる気がする。少なくとも、他の会社みたいにコミュニケーションが崩壊することはなかったからね。正直に言うと、AIエージェントに賭けるときは、その製品の未来にも賭けてる気がする。結局、人が作ってるから、人に賭けてるってことになるよね。こういう困難な時期にコミュニケーションがしっかりしてる人に賭けたいな。時々崩壊する人たちよりもね（Coderabbitに対して悪意はないけど、今思いついたのはこれ）。だから、こういう瞬間が製品のリトマス試験になると思うんだ。人々のコミュニケーションを見てどうなるかっていうね。
みんな、ほとんど特権分離もサンドボックスもない状態でOpenCodeや似たようなツールをノートパソコンで動かしてるみたいだね。この傾向は、プラグインの設計にも反映されてて、デフォルトではツールがIDEの隣で制限なしに動いてるって前提になってることが多い。多くの認証コールバックがローカルホストのポートに送られるし、コールバックURLから正しいパラメータを解析するのがフォールバックになってる。なんか理由は分からないけど、これらのツールはリモートプロバイダーからの返信を待ってる時でもリソースを結構使うことが多いよね。存在してくれて嬉しいけど、最近のツールに比べると粗い部分が多い気がする。少なくとも開発用コンテナやVMを使ってツールを動かしてほしいな。RDPやVNC、Spice、あるいはtmuxを使ってコンテナやマシンの中で作業できるよ。SSHFSやSamba/NFS、9pを使ってコンテナやマシンにいくつかのものをミラーリングすることもできるし、信頼できるスナップショットのために従来のツールやファイルシステムを使うこともできる。結果は別にプッシュするか、エージェントに直接制限なしのgitアクセスを与えない方がいいよ。そんなに難しくないから。もしすごく怠けたいなら、月5ドルくらいでVPSを借りてそこで作業するのもありだよ。
└
fly.ioのhttps://sprites.dev/が作った製品が、AIのサンドボックスに効果的で本当に好きだな。ここではすごく適してると思う（スポンサーじゃないけど、そうだったらいいのに笑）。あ、そういえば、誰かがqemuでサーバーを立てたいなら、quickemuを強くおすすめするよ。デフォルトでsshアクセスやsshfs、vnc、spiceなどのポートがローカルデバイスに提供されるし、quickgetを使ってDebianや他のディストリビューション（たくさんある中から）をインストールできる。直感的で、試す価値はあると思うよ。https://github.com/quickemu-project/quickemu。個人的には、sshでリモートオープンしたzedが好きだな。いつでもターミナルを開いてclaude codeやopencodeを使えるし、AIも提供してる（あんまりAIは使わないけど、自分用に簡単なスクリプトを作るから、ウェブサイトから無料でコピペしてる）。でも、zedは試す価値があると思うよ。