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 及 content length 在内的 HTTP 元数据的控制。获得相关发布路径或发布流程访问权限的行为者可以替换原生代码,Kimi 会通过其普通的更新机制安装该替换文件。RuntimeWire 未发现活动妥协的证据。
The hidden second executable
Kimi Desktop 3.1.10(截至 8 月 18 日,通过 Kimi 的官方下载页面 提供的 Windows 构建)在成功部署 Kimi Claw 后,会对一个独立的 Group Chat 命令行可执行文件执行冷启动检查。
该可执行文件不会保留在 Kimi Desktop 的主应用程序目录或签名应用包内。更新程序将其安装在用户配置文件中,并永久将 ~/.local/bin 添加到 Windows 用户的 PATH,使该组件对 Kimi Claw 以及在该账户下运行的其他进程可用。
该可执行文件支持 Moonshot 在其 Kimi Claw 文档 中描述的群聊系统,其中一位指挥者在设备和权限边界之间协调代理。下载的替换文件不一定会立即执行。它可能在调用 Group Chat CLI 时以登录用户身份执行。
HTTP metadata decides when native code is replaced
更新程序检查的是一个可变的最新发布位置,而不是请求固定版本或查阅经过认证的发布清单。它发送一个 HEAD 请求,并将响应与本地存储的 HTTP 元数据进行比较。
ETag、Last-Modified 值或 content length 的变化就足以触发替换下载。这些字段可以表明对象已更改,但它们并不认证是谁生成了新对象,也不表明是否为经批准的发布。
获得对 CDN 对象、其发布凭据或相关发布流程的写权限的行为者可以替换该可变存档并更改其 HTTP 指纹。RuntimeWire 检查的更新程序代码会接受该替换,而不会在安装前检查 Windows 校验和或强制预期的 Authenticode 签名者。
加密的网络连接可以保护传输中的下载内容,但它们无法对通过服务器端发布路径所做的更改提供完整性界限。
Windows skips the checksum routine
更新程序在 verifyChecksum(...) 周围包含了一个操作系统守卫。在 Windows 上,该守卫会跳过校验和步骤,而不是尝试验证并在失败时报错。
Windows ZIP 存档也不包含校验和文件。因此,更新程序在安装下载的 Group Chat 可执行文件之前不会将其与预期的摘要进行比较。
包含版本和摘要的已签名发布清单可以为客户端提供 Moonshot 意图分发哪个工件的稳定声明。RuntimeWire 检查的更新程序代码则接受来自可变 CDN 位置及其 HTTP 响应头的更新状态。
The current binary is signed, but the updater does not enforce that signer
抽样的 Windows 可执行文件不是未签名的。它具有有效的 Moonshot Authenticode 签名,这表明当前文件由发布者签名并在签名后保持未被修改。
Kimi Desktop 并未调用 Windows 签名验证、也未要求 Moonshot 为预期发布者,或在签名验证不可用时采取拒绝策略。因此该签名并不是安装的强制条件。
Windows 提供了用于应用程序验证文件签名和信任链的 WinVerifyTrust API。Kimi 的更新程序并未对 Group Chat 可执行文件使用该边界。
这一差别对威胁模型很重要。对发布路径的控制就足以在预期位置放置不同的存档,而无需同时获取 Moonshot 的代码签名证书。更新程序可能安装一个由不同签名者签名或未签名的替换文件,从而在稍后调用 CLI 时创建本地代码执行的供应链路径。
The same distribution tree can rewrite agent behavior
相同的更新机制还提供了三个可变的 SKILL.md 文件。这些文件可以更改本地代理检查对话、处理文件和调用 Group Chat 可执行文件的方式,即使原生二进制文件保持不变。
Moonshot 的 desktop deployment guide 表示 Kimi Claw 会自动在本地部署 OpenClaw、配置一个 Kimi 模型,并通过技能和计划任务支持自定义。因此,可变的技能指令在同一更新程序内造成了第二种完整性担忧:发布路径的更改可能在不替换可执行代码的情况下修改代理行为。
macOS has a checksum, but not an independent trust source
macOS 分支与 Windows 不同。其存档包含校验和,且更新程序会执行校验和例程。
然而,该校验和与二进制文件一同出现在同一可变存档中。它并不是一个独立认证的信任来源。能够通过发布路径替换存档的行为者可以同时替换工件和用于验证它的校验和。
更强的设计应使用不可变的版本化工件和经过认证的清单,在 Windows 上强制执行预期的 Moonshot 签名者,并通过与可变载荷存档分离的信任源来认证代理技能文件。
RuntimeWire 于 8 月 14 日向 Moonshot AI 披露了该问题,设定了 8 月 15 日的响应截止日期,并在修复正在进行时提供了短期的发布延迟。Moonshot 在出版前未确认该披露或作出回应。