Kimi Desktop Ships With a Group Chat Updater That Can Install Unverified Code
The Windows updater pulls a separate executable and agent instructions from mutable “latest” locations. The current binary is signed by Moonshot, but Kimi never verifies that signature before installation.
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 automatically installs a separate Group Chat executable from a mutable CDN location and, on Windows, replaces that executable without checking a checksum or enforcing its publisher signature, RuntimeWire found.
The current 19.7MB executable carries a valid Moonshot Authenticode signature. Kimi Desktop's updater never verifies that signature. Its Windows branch explicitly skips the checksum routine, and the ZIP archive delivered by Moonshot contains no checksum file.
That leaves the update path dependent on control of a mutable "latest" archive and HTTP metadata including ETag, Last-Modified and content length. An actor who gained access to the associated publishing path or release process could substitute native code that Kimi would install through its ordinary update mechanism. RuntimeWire found no evidence of an active compromise.
The hidden second executable
Kimi Desktop 3.1.10, the Windows build served through Kimi's official download page as of Aug. 18th, performs a cold-start check for a separate Group Chat command-line executable after a successful Kimi Claw deployment.
That executable does not remain inside Kimi Desktop's main application directory or signed application bundle. The updater installs it in the user's profile and permanently adds ~/.local/bin to the Windows user's PATH, making the component available to Kimi Claw and other processes running under that account.
The executable supports the group-chat system described in Moonshot's Kimi Claw documentation, where a conductor coordinates agents across devices and permission boundaries. A downloaded replacement would not necessarily execute immediately. It could execute as the logged-in user when the Group Chat CLI is invoked.
HTTP metadata decides when native code is replaced
The updater checks a mutable latest-release location rather than requesting a pinned version or consulting an authenticated release manifest. It sends a HEAD request and compares the response with locally stored HTTP metadata.
A changed ETag, Last-Modified value or content length is sufficient to trigger a replacement download. Those fields can indicate that an object changed, but they do not authenticate who produced the new object or whether it is an approved release.
An actor who obtained write access to the CDN object, its publishing credentials or the associated release process could replace the mutable archive and change its HTTP fingerprint. The updater code RuntimeWire examined would accept the replacement without checking a Windows checksum or enforcing an expected Authenticode signer.
Encrypted web connections can protect the download in transit. They do not provide an integrity boundary against changes made through the server-side publishing path.
Windows skips the checksum routine
The updater contains an operating-system guard around verifyChecksum(...). On Windows, that guard skips the checksum step rather than attempting verification and failing it.
The Windows ZIP archive also contains no checksum file. As a result, the updater does not compare the downloaded Group Chat executable with an expected digest before installing it.
A signed release manifest containing a version and digest could give the client a stable statement of which artifact Moonshot intended to distribute. The updater code examined by RuntimeWire instead accepts update state from the mutable CDN location and its HTTP response headers.
The current binary is signed, but the updater does not enforce that signer
The sampled Windows executable is not unsigned. It has a valid Moonshot Authenticode signature, providing evidence that the current file was signed by the publisher and remained unchanged after signing.
Kimi Desktop does not invoke Windows signature verification, require Moonshot as the expected publisher or fail closed when signer validation is unavailable. The signature is therefore not an enforced condition of installation.
Windows provides the WinVerifyTrust API for applications to validate a file's signature and trust chain. Kimi's updater does not use that boundary for the Group Chat executable.
The distinction matters to the threat model. Control of the publishing path would be enough to place a different archive at the expected location without also obtaining Moonshot's code-signing certificate. The updater could install a replacement with a different signer or no signature, creating a supply-chain path to native code execution when the CLI is later invoked.
The same distribution tree can rewrite agent behavior
The same update mechanism supplies three mutable SKILL.md files. Those files can alter how local agents inspect conversations, handle files and invoke the Group Chat executable even when the native binary remains unchanged.
Moonshot's desktop deployment guide says Kimi Claw automatically deploys OpenClaw locally, configures a Kimi model and supports customization through skills and scheduled tasks. Mutable skill instructions therefore create a second integrity concern within the same updater: a publishing-path change could modify agent behavior without replacing executable code.
macOS has a checksum, but not an independent trust source
The macOS branch is different from Windows. Its archive contains a checksum, and the updater performs the checksum routine.
That checksum arrives beside the binary in the same mutable archive, however. It is not an independently authenticated trust source. An actor able to replace the archive through the publishing path could replace both the artifact and the checksum intended to validate it.
A stronger design would use immutable versioned artifacts and an authenticated manifest, enforce the expected Moonshot signer on Windows, and authenticate the agent skill files through a trust source separate from the mutable payload archive.
RuntimeWire disclosed the issue to Moonshot AI on Aug. 14, set an Aug. 15 response deadline and offered a short publication delay if remediation was underway. Moonshot did not acknowledge the disclosure or respond before publication.