ZCodeが1スナップショットに42,411ファイルを梱包、復号できるのはZ.aiだけだった

GLM開発元のコーディングアプリがGit履歴ごとアリババクラウドへ送信、鍵はサーバー側が保持——リバースエンジニアリング報告

|5分で読める0
Source code on a developer's screen — ZCode's snapshot routine packaged entire repositories, including the .git object store, before every prompt.
Source code on a developer's screen — ZCode's snapshot routine packaged entire repositories, including the .git object store, before every prompt.

9月18日に公開されたリバースエンジニアリング報告によれば、中国のモデル開発企業Z.aiのデスクトップ向けコーディングアプリ「ZCode」は、開発者のワークスペース全体を——Gitのオブジェクトストアも含めて——一括で梱包し、Z.ai自身のサーバーでしか解けない暗号をかけたうえでアリババクラウドのオブジェクトストレージへ送信していた。

異例なのはアップロードそのものではなく、鍵を誰が持っていたかだ。アーカイブは開発者には開けない暗号文としてアリババのOSSに置かれ、それを生成する処理はアプリの設定画面に一切現れない。

要点

  • 捕捉されたスナップショットの一つには42,411ファイル・313MBが含まれ、.gitディレクトリだけでペイロードの86.6%を占めていた。
  • ZCodeは各アーカイブのAES-256-CTR鍵を、サーバーがその都度発行するRSA公開鍵で包んでいた。対応する秘密鍵はZ.aiのクラウド内にのみ存在する。
  • Z.aiは謝罪してクライアントを修正し、ZCode利用者に週次利用上限の一度きりのリセットを付与したうえで、コードベースの公開と外部監査の受け入れを表明した。

Gitディレクトリを渡すことが最悪である理由

報告を書いたのはferstar名義で発信する研究者だ。クライアントのElectronバンドルを展開し、送信経路を一段ずつ再構成した。345MBの商用プロジェクトで生成されたアーカイブは42,411ファイル・313MBに達し、その圧倒的大半をリポジトリのオブジェクトストアが占めていた。

この比率こそが本質だ。ワーキングツリーはプロジェクトの現在の姿しか映さないが、オブジェクトストアはそれが通過したすべての状態を保存する。一度コミットして次のコミットで削除した認証情報も履歴に残る。未公開機能を示唆する放棄されたブランチ名も、リポジトリ設定に記録された内部ホスト名やリモートパスも同様だ。

Z.aiが公開するプライバシー規約は、テキストとコードを収集すると記している。リポジトリの全系譜を収集するとは書かれていない。

オフスイッチに見えたトグル

報告を読めば誰でも設定画面を開きたくなるが、厄介なのはまさにその部分だ。ferstarがインターフェースとコードを突き合わせたところ、「Optimize Experience」のスイッチは収集データをモデル学習に使うかどうかだけを、「Repo Snapshot Indexing」は届いたデータをサーバーが索引化するかどうかだけを制御していた。どちらも梱包と送信には触れていない。

報告によれば、キャプチャを担うコンポーネントはホストプロセスが起動時に生成し、ユーザー設定には依存しない。唯一の前提条件は有効なセッショントークンだ。ある作業セッションでは62回のキャプチャが記録された。プロンプト送信のたびに発火し、タスク完了時にも再び動いていた。

もう一つの痕跡がこの構図を補強する。公開されているハーネスプロンプト集に出回る131KBのZCodeシステムプロンプトには、エージェントが使える31のツールが列挙されている。そのどれもアップロードやスナップショット、送信を行うものではなく、文書全体を通じてアリババ、OSS、アップロードという語は一度も出てこない。送出経路はエージェン���のループの外側にあり、だからこそ権限確認のダイアログは一度も出なかった。

オープンな重みはオープンなハーネスではない

この件が大きく燃えた背景には、議論スレッドに見えた分類の誤りもある。GLMがオープンソースなのだからZCodeもそうだろうと考えた開発者が少なくなかった。Z.aiが公開しているのはダウンロード可能な重みであり、それを動かすデスクトップクライアントはプロプライエタリだ。そして梱包を行っているのはクライアントのほうである。

反響は両言語圏で大きく、ferstarの記事は27万6000ビューを超え、中国語の注意喚起スレッドがさらに6万3800ビューを集めた。最も引用された反応は開発者のペトリ・クイッティネン氏のもので、クローズドソースのAIハーネスはそもそも信用すべきでないと述べた。

Z.aiの対応は速かった。同社は謝罪し、収集したデータは保持せず処理直後に破棄したと説明。パッチを配布し、利用上限のリセットで利用者に補償したうえで、ZCodeのコードベース公開と第三者レビューの導入を約束した。

開発者にとって何が変わるか

モデルのローカル運用とベンダー提供のデスクトップクライアントを比較検討するチームにとって、両者の線引きはこれまでより鮮明になった。オープンウェイトの公開はモデルが何であるかを語るが、それを包む外殻がファイルシステムに何をするかは何も語らない。チェックポイントや巻き戻し機能を持つAIコーディングアシスタントは、構造上どこかで何かをスナップショットしている。問うべきはそのスナップショットがどこに落ち着くかだ。今年は他のエージェントハーネスにも同種の検証が及んでおり、主要な4つのCLIエージェントで公表されたゼロクリック脆弱性もその一例だ。

よくある質問

ZCodeはオープンソースなのか。

違う。Z.aiはGLMのモデル重みを公開しているが、ZCodeのデスクトップクライアントはクローズドソースだ。誰かが逆コンパイルするまでこのスナップショット挙動が気づかれなかったのはそのためである。同社はその後、コードベースを公開する意向を示している。

利用者は自分がアップロードしたアーカイブを復号できるか。

できない。ペイロードの鍵はZ.aiのサーバーが提供したRSA公開鍵で包まれており、研究者は端末上のどの秘密鍵でも解けなかった。対応する秘密鍵はZ.aiのインフラ内にしか存在しない。

プライバシー設定を切ればアップロードは止まったのか。

報告によれば止まらなかった。関係する二つのトグルは収集後の利用とサーバー側の索引化を制御するだけで、ワークスペースを梱包して送信するコンポーネントは設定と無関係にホストレベルで動作していた。

この記事への反応を残してください!

SJ

ディスカッション

ログインして投稿
読み込み中...

関連記事

Vercel、1年前に修正済みの不具合でプラットフォーム全体の AVIF を停止
Developer Tools

Vercel、1年前に修正済みの不具合でプラットフォーム全体の AVIF を停止

Vercel は報告された Next.js の RCE を libheif まで追跡し、8月13日にプラットフォーム全体で AVIF を無効化、8月25日までに sharp・libvips・libheif の修正を調整した。

Seung Jung9 時間前
ShopifyがTailwind Labsを買収、AIコーディングツールが崩したフレームワーク事業
Developer Tools

ShopifyがTailwind Labsを買収、AIコーディングツールが崩したフレームワーク事業

ShopifyがTailwind CSSの開発元Tailwind Labsを買収した。フレームワークはMITライセンスを維持する一方、Tailwind Plusとui.shは新規申し込みを停止する。

Seung Jung7 日前
Meta、エージェントが直接照会できるReactデザインシステム「Astryx」をオープンソース公開
Developer Tools

Meta、エージェントが直接照会できるReactデザインシステム「Astryx」をオープンソース公開

Metaは社内モノレポで8年かけて成熟させたReactデザインシステムAstryxを、6月にMITライセンスのパブリックベータとして公開しました。

Seung Jung5 日前
OpenAI「自社モデルがJalapeñoの設計を9か月に短縮した」
Tech & Business

OpenAI「自社モデルがJalapeñoの設計を9か月に短縮した」

AIが書いたカーネルがOpenAIの専門家による実装を最大1.8倍上回った。JalapeñoのInferenceXベンチマーク結果が初公開された。

Seung Jung24 日前
AIエージェントがRubyGemsに2000超のパッケージを投下、新規登録は4日間停止
Developer Tools

AIエージェントがRubyGemsに2000超のパッケージを投下、新規登録は4日間停止

フォレンジック報告が5月のGemStufferキャンペーンを再構成した。AIエージェントが2000超のgemを投下し、RubyGemsは新規登録を4日間凍結した。

Seung Jung7 日前
LLMのバグ修正は、直した数の10倍も動くコードを壊していた
Developer Tools

LLMのバグ修正は、直した数の10倍も動くコードを壊していた

arXivの研究で、LLM修復ループが正しいプログラムを壊す率は0.261、バグを直す率は0.023だった。著者らはその挙動を駆動する内部方向まで突き止めた。

Seung Jung6 日前