Build1 publisher3 min readPublished
Kimi Desktop's second binary: mutable CDN path, no Windows checksum, no signer check
RuntimeWire says Kimi Desktop 3.1.5 and 3.1.10 fetch a Group Chat executable from a mutable Moonshot path, skip checksum verification on Windows, and never enforce an Authenticode signer.
The Engineer · Build desk
Drafted by a language model from the sources cited here and checked against its claim ledger before publication. How we use AISend a correction
What happened
- 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.
- 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
- The updater 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(...) }
Compiled by The EngineerSomething wrong?How this is made
Why it matters
Kimi Desktop 3.1.5 and 3.1.10 automatically install and update a separate Group Chat executable plus three agent skill files from mutable Moonshot CDN locations, and on Windows the updater skips checksum verification and does not enforce the executable's Authenticode signer before installation, according to RuntimeWire [1]. For anyone who approved Kimi Desktop through a software review, that is a second code-delivery path into the endpoint fleet that the review almost certainly did not cover.
RuntimeWire says it traced the packaged updater from a function named triggerKimiimColdStartCheck() through its download, fingerprinting, verification and installation logic [2]. The updater sets its release version to "latest" and pulls kimiim-cli from a mutable tree at https://kimi-img.moonshot.cn/pub/claw/tmp/lihuaru/skills/kimiim [3]. Whether to update is decided by an HTTP HEAD request comparing ETag, Last-Modified or content length against a locally stored fingerprint, with no pinned release version and no authenticated release manifest [4]. In other words, the client trusts whatever currently sits at that path, and notices a change only as a change of bytes.
The integrity check is conditional on the operating system. RuntimeWire describes a guard equivalent to if (os !== "windows") { verifyChecksum(...) } [5], and reports that the live Windows ZIP contains kimiim-cli.exe with no checksum file beside it [6]. The installer does not call Get-AuthenticodeSignature, validate a certificate identity, or otherwise require an expected signer before moving the executable into place [7]. The macOS archive does ship a checksum next to its binary, though checksum and binary arrive together over the same mutable download [8]. On the tested platforms, Windows is therefore the only one with neither a checksum file nor a checksum call at install time [1].
The important qualification: the executable RuntimeWire examined is currently signed with a valid Moonshot Authenticode certificate, and nothing in the updater code requires a future replacement to carry that signature [9]. RuntimeWire also says it found no evidence that Moonshot's CDN, publishing credentials or distributed artifacts have been compromised [10]. The finding is about the absence of enforcement, not an incident.
The installation step is durable. The installer removes the previous target, renames the download to ~/.local/bin/kimiim-cli.exe, and permanently adds ~/.local/bin to the Windows user PATH [11]. Three skills, kimiim/SKILL.md, worker-safety/SKILL.md and time-awareness/SKILL.md, update from mutable paths through the same ETag and Last-Modified mechanism [12], making four artifacts fetched from mutable locations per install [2]. The macOS archive retains developer packaging metadata, including AppleDouble files, quarantine and provenance attributes, and ownership metadata identifying houzhendong/staff [13]. The native binary identifies the Go module kimi.darkmatter/tools/kimiim-cli, commit 231e0b9d475dcc0d99db0da712477014d97f575c, and build time 2026-04-25T04:57:57Z [14]. That is a build-and-publish pipeline, not a hardened release channel.
RuntimeWire says it disclosed to Moonshot Security on Aug. 14, 2026, asked for acknowledgement by 6 p.m. CDT on Aug. 15, offered a short publication delay if remediation was underway, and received no reply before publication [15]. It confirmed the mutable mechanism and the Windows checksum exception were still present when comparing the packaged code in 3.1.10 [16]. Behavioral testing used a Linux build with a dummy token against a reporter-controlled loopback server, with no real account, no artifact replacement and no execution against another user's install [17].
Watch for whether the next Windows release pins a version, publishes a signed manifest, or deletes the OS condition around the checksum call, and whether Moonshot acknowledges at all. Endpoint teams do not need to wait: the static check requires only the official Windows x64 build, a disposable machine, an ASAR extraction tool and PowerShell, and no Group Chat token [18].