OpenCodeで認証なしのリモートコード実行脆弱性が発見

 (cy.md)
3 ポイント 投稿者 GN⁺ 2026-01-13 | 1件のコメント | WhatsAppで共有
  • OpenCode の旧バージョンで、認証なしに任意のコードを実行できる深刻なリモートコード実行脆弱性が発見された
  • v1.1.10 より前のバージョンは自動的に HTTP サーバーを起動し、このサーバーは認証手順なしで任意コマンド実行・ファイル読み取り・ターミナルセッション生成を許可していた
  • v1.0.216 より前では、Web サイトを訪問するだけでユーザーのローカル環境でコードが実行される可能性があった
  • 最新バージョン (v1.1.10) ではサーバーはデフォルトで無効化されたが、有効化した場合でも依然として認証がない
  • この脆弱性は CVE-2026-22812 として登録されており、開発者とユーザーは直ちにアップデートと設定確認を行う必要がある

脆弱性の概要

  • OpenCode はオープンソースの AI コーディングアシスタントで、v1.1.10 より前は起動時に自動で HTTP サーバー (デフォルトポート 4096+) を開始していた
    • サーバーは POST /session/:id/shell, POST /pty, GET /file/content などのエンドポイントを提供
    • 認証手順がないため、接続可能なすべてのクライアントがユーザー権限でコード実行可能
  • サーバー起動時にユーザーへの視覚的な表示がなく、公開状態であることを認識しにくい
  • CORS ポリシーが *.opencode.ai にハードコードされており、opencode.ai またはそのサブドメインで配信されるページがサーバー API にアクセス可能
    • 当該ドメインが侵害されたり XSS 脆弱性が存在した場合、サーバー有効化状態のすべてのユーザーが攻撃対象になりうる

攻撃ベクトル

  • v1.0.216 より前: 任意の Web サイトが OpenCode 実行中のユーザーのローカルマシンでコードを実行可能
  • v1.1.10 より前: ローカルプロセスや localhost ページが認証なしでコード実行可能
  • すべてのバージョンでサーバーが有効な場合:
    • ローカルプロセスおよび localhost ページが認証なしでコード実行可能
    • --mdns フラグ使用時はローカルネットワーク内のすべてのデバイスがアクセス可能
    • サーバー稼働の表示がなく、ユーザーが公開状態を認識できない
    • opencode.ai ドメインまたはそのサブドメインからコード実行可能

攻撃例 (Proof of Concept)

  • ローカル攻撃: サーバーが稼働中のとき、ローカルプロセスが curl コマンドでセッションを作成した後、id > /tmp/pwned.txt コマンドを実行可能
  • ブラウザベースの攻撃 (v1.0.216 より前): Web ページから fetch リクエストでローカルサーバーにコマンドを渡し、リモートスクリプトをダウンロード・実行可能
    • Firefox で動作を確認、Chrome はローカルネットワークアクセス保護によりユーザー確認ダイアログを表示する可能性がある

ユーザー向け対応策

  • opencode --version でバージョンを確認し、v1.1.10 以上へアップデート
  • 設定ファイルで server.port または server.hostname 項目が有効になっていないか確認
  • --mdns フラグを使用しない (0.0.0.0 にバインドされ、ネットワーク全体に公開される)
  • サーバーをどうしても使用する必要がある場合は、opencode.ai およびそのサブドメインへのアクセスを避ける
  • サーバー有効化時は、ローカルプロセスが認証なしでアクセス可能であることを認識しておく必要がある

公開スケジュール

  • 2025-11-17: メールで初回報告、応答なし
  • 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: 全面公開

推奨措置

  • CORS を最小限のドメインに制限 (v1.0.216 で適用)
  • サーバーをデフォルトで無効化 (v1.1.10 で適用)
  • すべてのサーバーリクエストに認証手順を追加
  • サーバー起動時にユーザーへ明確な表示を提供
  • --mdns オプションが 0.0.0.0 にバインドされることをドキュメントに明記
  • ネットワーク通信時に TLS を適用
  • GitHub Security Advisory および CVE-2026-22812 を正式公開
  • セキュリティ報告用メールおよび GHSA 通知の監視を強化
  • OpenCode メンテナー、opencode.ai、ユーザー間の信頼関係を明確化

参考

  • CVE: CVE-2026-22812
  • 影響を受けるパッケージ: npm opencode-ai
  • 最新情報および問い合わせ: cy.md

関連記事

1件のコメント

 
GN⁺ 2026-01-13
Hacker Newsの反応

  • メンテナとして、今回のセキュリティレポート対応をきちんとできなかったことを認める。
    利用量が急増して問題が殺到しており、今週中に専門家と会ってバグバウンティプログラムとセキュリティ監査を進める予定とのこと。

    • バグバウンティや監査にお金を使うより、組織の立て直しと社員教育に投資すべき。
      チーム全員がOWASP Insecure Designガイドを理解し実践することのほうが重要。
    • 最初は前向きに見ていたが、脆弱性の報告者が何度も連絡したのに返答がなかった点が気になる。
      OpenCodeは有名なオープンソースのコーディングエージェントだけに、すでに悪用されていた可能性もある。
      今からでもgVisorのようなサンドボックス環境でモデルを動かすべきだと思う。
      迅速に対応しなければ、さらに多くのRCE脆弱性を狙う攻撃者が現れかねない。
    • プロジェクトの成長が速すぎて、組織運営がコード開発より重要な段階に来たように見える。
      アナキズム的な組織運営原則のようなものも参考にしているのか気になる。
    • ただClaudeにセキュリティ問題を直させればいいのでは？
    • 状況を率直に共有し、責任を取ろうとする姿勢は好感が持てる。簡単なことではなく、ありがたい。

  • 多くの人がOpenCodeのようなツールをローカル環境で権限分離なしに実行している。
    プラグインも基本的に無制限アクセスを前提に設計されており、リソース消費も大きい。
    少なくともdev-containerやVMの中で実行し、SSHFSやSambaで必要なファイルだけ接続するのがよい。
    面倒なら月5ドルのVPSでもよい。

    • dev-containerやVMの設定方法を具体的に教えてほしい。
    • Claudeは実行のたびに権限要求を出すので、その点ではやや安全。
    • AIサンドボックスとしてはfly.ioのsprites.devがかなり良い。
      サーバーをqemuで動かすならquickemuがおすすめ。
      zedのSSH remote機能も便利で、Claude CodeやOpenCodeと併用できる。

  • CORS修正で外部ウェブサイトからの悪用は防げたが、根本的にはlocalhostでコード実行が可能な構造そのものが問題。
    Neovimはデフォルトでドメインソケットを使い、VS CodeのSSHデーモンには認証手順がある。
    認証なしでクライアント入力を実行するローカルサーバーは**LCE(Local Code Execution)脆弱性であり、
    ブラウザー経由のリクエストでアクセス可能になると    RCE(Remote Code Execution)**へ拡大する。

  • 認証なしでRCE可能なHTTPエンドポイントをCLIツールに入れ、しかもCORSバイパスまで加えていたとは衝撃的。

    • AI研究所はチュートリアルコードでモデルを学習させるのをやめるべきかもしれない。
    • サーバーがここまで開いているのに、CORSポリシーが「*」でなかったことのほうがむしろ驚き。
    • 「ただ雰囲気で作ったコードみたいだ」という反応もある。

  • 脆弱性公開のスケジュールが問題。
    2025-11-17に報告されたが、何度連絡しても応答がなかった。

    • 今は開発者たちも真剣に対応しようとしているようだ。
      GitHub issueコメントを参照。
    • 「最近はみんなvibe coding中だから、セキュリティ問題はbad vibes」という冗談交じりの反応も。

  • サーバーがデフォルトで無効でも、起動すれば依然として深刻。
    localhost上でどんなウェブページからでもコード実行が可能で、認証なしでローカルプロセスまで実行できる。
    ユーザーにサーバーの起動状態を知らせる表示もない。
    TUIアプリは普通こうしたことをしないから信頼されているのに、今回の件はその信頼を大きく損なった。

    • なぜよりによってTUIアプリが問題なのか、という質問もあった。
    • 代替としてはFactoryのDroidが良いという意見も。

  • OpenCodeが**YC(Y Combinator)**の支援を受けている点に驚く。
    YCならもっと良いセキュリティ文化を促すと思っていた。

    • YCは結局金がすべてだという冷めた反応もあった。
    • 以前、YC出身のFlockがパスワードを53回ハードコードしていた事例もある。
      詳しくはこのコメントを参照。
    • しかもOpenCodeがAuth provider製品も作っているという点が皮肉。

  • OpenCodeはボランティアプロジェクトだと思っていたが、実際には大手投資家の支援を受ける企業型プロジェクトだった。

    • 公式GitHubリポジトリのほかに、charm.shチームが作った競合プロジェクトもあった。
    • おそらくcrush、roocode、kiloのようなプロジェクトを思い浮かべていたのだろう。これらにはまだ大口スポンサーはいない。

  • 機能ばかり追加してコアメンテナンスをおろそかにしていたので、使うのをやめた。
    複数モデルを同時に使うのが目的だったが、コンテキスト共有が非効率で実用性に欠けた。
    今はClaude CodeとCodexを併用している。
    それでも複数モデルを統合するオープンプラットフォームの必要性は依然として大きい。

    • ampcode(リンク)とCrush(リンク) + z.ai GLMの組み合わせを勧める声がある。
      ampcodeは無料で簡単なスクリプトを作れ、Crush+GLMはClaudeやCodexの計画によく従う。
    • 新機能を追加することより、レビューと品質管理の規律を守るほうが難しいという意見も。

  • 最初はAiderが気に入っていたが、ほとんどメンテナンスされておらず問題が頻発した。
    OpenCodeをインストールしようとしていたが、今回の件を見てためらうようになった。
    モデルに依存しないオープンソースのCLI LLMアシスタントがこれほど少ないのは驚きだ。