Kimi Desktop、未検証コードをインストールできるグループチャットアップデーターを同梱
Windowsのアップデーターは、変更可能な“latest”ロケーションから別の実行可能ファイルとエージェントの指示を取得します。現在のバイナリはMoonshotによって署名されていますが、Kimiはインストール前にその署名を決して検証しません。
By Ryan Merket · Published
RUNTIMEWIRE INVESTIGATION — Scoop
Original reporting by RuntimeWire, based on reverse engineering, data analysis, documents.
Why it matters
Kimi Desktop's updater trusts control of a mutable download location as authority to install code. A release-system compromise could therefore reach local agents without Moonshot's signing key.
Reporting record
Finding
Kimi Desktop 3.1.5 and 3.1.10 automatically install and update a separate Group Chat executable and three agent skills from mutable Moonshot CDN locations, while the Windows updater skips checksum verification and does not enforce the executable’s Authenticode signer before installation.
How we verified
Methods: reverse engineering, data analysis, documents.
RuntimeWire traced Kimi Desktop’s packaged updater from triggerKimiimColdStartCheck() through its download, fingerprinting, verification and installation logic. The updater sets its release version to latest and downloads kimiim-cli from a mutable Moonshot CDN tree under: https://kimi-img.moonshot.cn/pub/claw/tmp/lihuaru/skills/kimiim It determines whether to update using an HTTP HEAD request and compares ETag, Last-Modified or content length with a locally stored fingerprint. The code does not pin a release version or require an authenticated release manifest. Checksum verification is guarded by an operating-system condition equivalent to: if (os !== "windows") { verifyChecksum(...) } The live Windows ZIP contains kimiim-cli.exe without a checksum file. The installer does not call Get-AuthenticodeSignature, validate a certificate identity or otherwise enforce an expected signer before moving the executable into ~/.local/bin. The installed executable is currently signed with a valid Moonshot Authenticode certificate. That signature is an important qualification: the artifact RuntimeWire examined was signed, while the updater code does not require future replacements to carry that signature. The installer removes the previous target, renames the downloaded executable into ~/.local/bin/kimiim-cli.exe and permanently adds ~/.local/bin to the Windows user PATH. Three agent skills are updated from mutable paths through the same ETag/Last-Modified mechanism: kimiim/SKILL.md worker-safety/SKILL.md time-awareness/SKILL.md The macOS archive includes a checksum beside its binary, although the checksum and binary arrive together through the same mutable download. The archive also retains developer packaging metadata, including AppleDouble files, quarantine and provenance attributes, and ownership metadata identifying houzhendong/staff. The native executable identifies the Go module kimi.darkmatter/tools/kimiim-cli, commit 231e0b9d475dcc0d99db0da712477014d97f575c, and build time 2026-04-25T04:57:57Z. RuntimeWire found no evidence that Moonshot’s CDN, publishing credentials or distributed artifacts have been compromised.
RuntimeWire extracted and examined the packaged JavaScript from Kimi Desktop 3.1.5 for Windows. We located the Group Chat cold-start function and followed its control flow through URL construction, update detection, checksum handling, installation and PATH modification. We inspected the live Windows archive delivered by Moonshot, recorded its HTTP metadata, listed its contents and calculated SHA-256 hashes for the archive and executable. We used Windows Authenticode inspection to verify the executable’s current signature status and inspected Go build metadata and embedded strings without altering the binary. We separately inspected the macOS archive structure, included checksum and retained packaging metadata. We compared the relevant packaged updater code with Kimi Desktop 3.1.10 and confirmed that the mutable Group Chat update mechanism and Windows checksum exception remained present in that release. For limited behavioral testing of the Group Chat CLI, we used a Linux build with a dummy token and a reporter-controlled loopback capture server. We did not connect a real Group Chat account, replace any Moonshot artifact or attempt to execute code on another user’s installation. RuntimeWire disclosed the finding to Moonshot Security on Aug. 14, 2026. Moonshot was asked to acknowledge the disclosure by 6 p.m. CDT on Aug. 15 and was offered a short publication delay if remediation was underway. Moonshot did not reply before publication.
Tested versions: Kimi Desktop 3.1.5, release identifier 3.1.5+c88420152, Windows x64 Kimi Desktop 3.1.10, release identifier 3.1.10+e0c4c9980, Windows x64.
Reproduction
RuntimeWire independently reproduced the core finding.
Requirements: Kimi Desktop 3.1.5 or 3.1.10 for Windows x64 A disposable Windows test environment An ASAR extraction tool PowerShell No Group Chat token is required for static verification Steps: Obtain the official Kimi Desktop Windows release and extract its packaged app.asar. Search the extracted application for triggerKimiimColdStartCheck. Follow the call into the kimiim-cli installer and updater. Confirm that the configured version string is latest. Locate the Windows archive name kimiim-cli_windows_amd64.zip. Trace the HEAD request and confirm that update decisions use ETag, Last-Modified or content length. Locate the checksum branch and confirm that verifyChecksum(...) runs only when the operating system is not Windows. Download the publicly delivered Windows archive without executing its contents. List the archive and confirm that it contains kimiim-cli.exe without a checksum file. Calculate the archive and executable SHA-256 hashes. Run Get-AuthenticodeSignature against the extracted executable and record the signer and signature status. Confirm that the installer itself does not enforce that signer before placing the file in ~/.local/bin. Trace the Windows PATH modification and confirm that ~/.local/bin is added to the user PATH. Locate the three skill-download URLs and confirm that their update checks also rely on mutable resources and HTTP metadata. Repeat the static code check against Kimi Desktop 3.1.10 to confirm that the mechanism remains present. Do not modify the remote archive, upload a replacement, use production credentials or attempt to affect another installation.
File hashes
runtime reproduction.File hashessha256:4ecfdc4ff9ad57707f050888056babeac79eb85b61c3e0a369b612d809f80122 Kimi Desktop 3.1.5 app.asarsha256:bc6a8c43ae3bff49c86cb91201cb36e618c6db4677c62379c6480c5fbc8ceab3 Kimi Desktop 3.1.10 app.asarsha256:a3e3620814e7bb095a20eb555c4c1a26a97e4954791f8f1225f7fc6a6f6e0fe6 kimiim-cli_windows_amd64.zipsha256:04ffb2bedc7a6a31b9805dbad070d27dc7220cec94931a6159ebad45800a49e6 kimiim-cli.exe
Company response
The company did not respond to requests for comment.
Yang Zhilin's Moonshot AI は、可変の CDN ロケーションから別個の Group Chat 実行ファイルを自動的にインストールし、Windows ではその実行ファイルをチェックサムを確認したり発行者の署名を強制したりすることなく置き換えると RuntimeWire が発見した。
現在の 19.7MB 実行ファイルには有効な Moonshot Authenticode 署名が付与されている。Kimi Desktop のアップデータはその署名を検証しない。Windows ブランチは明示的にチェックサム処理をスキップしており、Moonshot が配布する ZIP アーカイブにはチェックサムファイルが含まれていない。
これにより、更新経路は「latest」可変アーカイブと ETag、Last-Modified、コンテンツ長などの HTTP メタデータの制御に依存することになる。関連する公開パスやリリースプロセスへのアクセスを得た攻撃者は、Kimi が通常の更新機構を通じてインストールするネイティブコードを差し替えることができる可能性がある。RuntimeWire は能動的な改竄の証拠は見つけなかった。
隠された2番目の実行ファイル
Kimi Desktop 3.1.10 — 8月18日時点で Kimi の公式ダウンロードページ を通じて配布されている Windows ビルド — は、Kimi Claw のデプロイに成功した後、別個の Group Chat コマンドライン実行ファイルのコールドスタート確認を行う。
その実行ファイルは Kimi Desktop のメインアプリケーションディレクトリや署名されたアプリケーションバンドル内には残らない。アップデータはそれをユーザーのプロファイルにインストールし、恒久的に ~/.local/bin を Windows ユーザーの PATH に追加して、そのコンポーネントを Kimi Claw や当該アカウント下で動作する他のプロセスから利用可能にする。
その実行ファイルは、conductor がデバイスや権限境界を越えてエージェントを調整するという Moonshot の Kimi Claw のドキュメント に記載されたグループチャットシステムをサポートする。ダウンロードされた差し替えファイルは必ずしも即時に実行されるわけではない。Group Chat CLI が呼び出された際にログイン中のユーザーとして実行される可能性がある。
HTTPメタデータがネイティブコードの置き換えタイミングを決める
アップデータは、固定バージョンを要求したり認証済みのリリースマニフェストを参照したりするのではなく、可変の latest-release ロケーションをチェックする。HEAD リクエストを送り、レスポンスをローカルに保存された HTTP メタデータと比較する。
ETag、Last-Modified 値、またはコンテンツ長のいずれかが変わるだけで置き換えダウンロードがトリガーされる。これらのフィールドはオブジェクトが変更されたことを示す場合があるが、新しいオブジェクトを作成した主体が誰であるかやそれが承認済みのリリースかどうかを認証するものではない。
CDN オブジェクト、その公開資格情報、または関連するリリースプロセスへの書き込みアクセスを得た攻撃者は、可変アーカイブを置き換え、その HTTP フィンガープリントを変更することができる。RuntimeWire が解析したアップデータのコードは、Windows のチェックサムを確認したり期待される Authenticode の署名者を強制したりすることなく、その置き換えを受け入れてしまう。
暗号化されたウェブ接続は転送中のダウンロードを保護できるが、サーバー側の公開経路を通じて行われる変更に対する整合性境界を提供するものではない。
Windows はチェックサム手順をスキップする
アップデータは verifyChecksum(...) の周りに OS ガードを含んでいる。Windows では、そのガードは検証を試みて失敗させるのではなく、チェックサム手順をスキップする。
Windows 用 ZIP アーカイブにもチェックサムファイルは含まれていない。その結果、アップデータはインストール前にダウンロードした Group Chat 実行ファイルを期待されるダイジェストと照合しない。
バージョンとダイジェストを含む署名付きのリリースマニフェストがあれば、クライアントに対して Moonshot が配布する意図のあるアーティファクトを安定的に示すことができる。RuntimeWire が調べたアップデータのコードは代わりに、可変の CDN ロケーションとその HTTP レスポンスヘッダから更新状態を受け入れている。
現在のバイナリは署名されているが、アップデータは署名者を強制しない
サンプルとして入手した Windows 実行ファイルは無署名ではない。現在のファイルには有効な Moonshot Authenticode 署名があり、発行者によって署名され、署名後に変更されていないことの証拠を提供する。
Kimi Desktop は Windows の署名検証を呼び出さず、期待される発行者を Moonshot に設定したり、署名者の検証が利用できない場合に失敗して停止したりしない。したがって署名はインストールの強制条件にはなっていない。
Windows はファイルの署名と信頼チェーンを検証するための WinVerifyTrust API を提供している。Kimi のアップデータは Group Chat 実行ファイルに対してその境界を使用していない。
この区別は脅威モデルにとって重要である。公開経路の制御だけで、Moonshot のコード署名証明書を入手しなくとも期待される場所に別のアーカイブを置くことが可能だ。アップデータは異なる署名者または署名なしの置き換えをインストールし得るため、その CLI が後で呼び出されたときにネイティブコード実行へのサプライチェーン経路を作り出す可能性がある。
同じ配布ツリーがエージェントの挙動を書き換え得る
同じ更新メカニズムは三つの可変 SKILL.md ファイルを供給する。これらのファイルは、ネイティブバイナリが変更されていない場合でも、ローカルエージェントが会話を検査する方法、ファイルを扱う方法、Group Chat 実行ファイルを呼び出す方法を変更できる。
Moonshot の desktop deployment guide は、Kimi Claw が OpenClaw を自動でローカルにデプロイし、Kimi model を構成し、skills やスケジュールタスクによるカスタマイズをサポートすると説明している。したがって可変のスキル指示は同じアップデータ内に第二の整合性上の懸念を生む：公開経路の変更により実行可能コードを置き換えなくともエージェントの挙動を変更できる。
macOS にはチェックサムがあるが、独立した信頼源ではない
macOS ブランチは Windows と異なる。アーカイブにはチェックサムが含まれ、アップデータはチェックサム手順を実行する。
しかしそのチェックサムはバイナリと同じ可変アーカイブの隣に配置されている。独立して認証された信頼源ではない。公開経路を通じてアーカイブを置き換えられる攻撃者は、検証用のアーティファクトとそれを検証するためのチェックサムの両方を置き換えることができる。
より強固な設計は、不変のバージョン化されたアーティファクトと認証されたマニフェストを使用し、Windows 上で期待される Moonshot の署名者を強制し、エージェントスキルファイルを可変ペイロードアーカイブとは別の信頼源で認証することだ。
RuntimeWire はこの問題を 8月14日に Moonshot AI に開示し、8月15日の応答期限を設定し、修正が進行中であれば公開の短い遅延を提案した。Moonshot は開示を確認せず、公開前に応答しなかった。