Kimi Desktop incluye un actualizador de chat grupal que puede instalar código no verificado
El actualizador de Windows descarga un ejecutable separado y las instrucciones del agente desde ubicaciones “latest” mutables. El binario actual está firmado por Moonshot, pero Kimi nunca verifica esa firma antes de la instalación.
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 instala automáticamente un ejecutable separado de Group Chat desde una ubicación mutable en un CDN y, en Windows, reemplaza ese ejecutable sin verificar un checksum ni exigir la firma del editor, encontró RuntimeWire.
El ejecutable actual de 19.7MB lleva una firma Authenticode válida de Moonshot. El actualizador de Kimi Desktop nunca verifica esa firma. Su rama de Windows explícitamente omite la rutina de checksum, y el archivo ZIP entregado por Moonshot no contiene ningún archivo de checksum.
Eso deja la ruta de actualización dependiente del control de un archivo "latest" mutable y de metadatos HTTP como ETag, Last-Modified y la longitud del contenido. Un actor que obtuviera acceso a la ruta de publicación asociada o al proceso de lanzamiento podría sustituir código nativo que Kimi instalaría mediante su mecanismo ordinario de actualización. RuntimeWire no encontró evidencia de una compromisión activa.
The hidden second executable
Kimi Desktop 3.1.10, la compilación de Windows servida a través de la página oficial de descargas de Kimi al 18 de agosto, realiza una comprobación de arranque en frío para un ejecutable de línea de comandos separado de Group Chat tras un despliegue exitoso de Kimi Claw.
Ese ejecutable no permanece dentro del directorio principal de la aplicación de Kimi Desktop ni en el paquete de aplicación firmado. El actualizador lo instala en el perfil del usuario y añade permanentemente ~/.local/bin al PATH del usuario de Windows, haciendo el componente disponible para Kimi Claw y otros procesos que se ejecuten bajo esa cuenta.
El ejecutable soporta el sistema de group-chat descrito en la documentación de Kimi Claw de Moonshot, donde un conductor coordina agentes a través de dispositivos y límites de permisos. Un reemplazo descargado no necesariamente se ejecutaría de inmediato. Podría ejecutarse como el usuario conectado cuando se invoque la CLI de Group Chat.
HTTP metadata decides when native code is replaced
El actualizador comprueba una ubicación mutable de última versión en lugar de solicitar una versión fijada o consultar un manifiesto de lanzamiento autenticado. Envía una petición HEAD y compara la respuesta con metadatos HTTP almacenados localmente.
Un cambio en ETag, en el valor Last-Modified o en la longitud del contenido es suficiente para disparar una descarga de reemplazo. Esos campos pueden indicar que un objeto cambió, pero no autentican quién produjo el nuevo objeto ni si es una versión aprobada.
Un actor que obtuviera acceso de escritura al objeto del CDN, a sus credenciales de publicación o al proceso de lanzamiento asociado podría reemplazar el archivo mutable y cambiar su huella HTTP. El código del actualizador que examinó RuntimeWire aceptaría el reemplazo sin comprobar un checksum de Windows ni exigir un firmante Authenticode esperado.
Las conexiones web cifradas pueden proteger la descarga en tránsito. No proporcionan un límite de integridad frente a cambios realizados a través de la ruta de publicación del servidor.
Windows skips the checksum routine
El actualizador contiene una salvaguarda por sistema operativo alrededor de verifyChecksum(...). En Windows, esa salvaguarda omite el paso de checksum en vez de intentar la verificación y fallarla.
El archivo ZIP de Windows tampoco contiene un archivo de checksum. Como resultado, el actualizador no compara el ejecutable de Group Chat descargado con un digest esperado antes de instalarlo.
Un manifiesto de lanzamiento firmado que contuviera una versión y un digest podría dar al cliente una declaración estable de qué artefacto Moonshot tenía la intención de distribuir. El código del actualizador examinado por RuntimeWire en su lugar acepta el estado de actualización desde la ubicación mutable del CDN y sus encabezados de respuesta HTTP.
The current binary is signed, but the updater does not enforce that signer
El ejecutable de Windows muestreado no está sin firmar. Tiene una firma Authenticode válida de Moonshot, lo que proporciona evidencia de que el archivo actual fue firmado por el editor y no fue alterado después de la firma.
Kimi Desktop no invoca la verificación de firmas de Windows, no requiere a Moonshot como el editor esperado ni bloquea la instalación cuando la validación del firmante no está disponible. Por tanto, la firma no es una condición exigida para la instalación.
Windows proporciona la WinVerifyTrust API para que las aplicaciones validen la firma de un archivo y la cadena de confianza. El actualizador de Kimi no usa ese límite para el ejecutable de Group Chat.
La distinción importa para el modelo de amenazas. El control de la ruta de publicación sería suficiente para colocar un archivo diferente en la ubicación esperada sin obtener además el certificado de firma de código de Moonshot. El actualizador podría instalar un reemplazo con un firmante distinto o sin firma, creando una vía en la cadena de suministro hacia la ejecución de código nativo cuando la CLI sea invocada más adelante.
The same distribution tree can rewrite agent behavior
El mismo mecanismo de actualización suministra tres archivos mutables SKILL.md. Esos archivos pueden alterar cómo los agentes locales inspeccionan conversaciones, gestionan archivos e invocan el ejecutable de Group Chat incluso cuando el binario nativo permanece sin cambios.
La guía de despliegue de escritorio de Moonshot dice que Kimi Claw despliega automáticamente OpenClaw localmente, configura un modelo Kimi y soporta personalización mediante skills y tareas programadas. Por lo tanto, las instrucciones mutables de skills crean una segunda preocupación de integridad dentro del mismo actualizador: un cambio en la ruta de publicación podría modificar el comportamiento del agente sin reemplazar el código ejecutable.
macOS has a checksum, but not an independent trust source
La rama de macOS es diferente de la de Windows. Su archivo contiene un checksum, y el actualizador realiza la rutina de checksum.
Ese checksum llega junto al binario en el mismo archivo mutable, sin embargo. No es una fuente de confianza autenticada de forma independiente. Un actor capaz de reemplazar el archivo mediante la ruta de publicación podría reemplazar tanto el artefacto como el checksum destinado a validarlo.
Un diseño más robusto usaría artefactos inmutables versionados y un manifiesto autenticado, exigiría el firmante esperado de Moonshot en Windows y autenticaría los archivos de skill del agente mediante una fuente de confianza separada del archivo de carga útil mutable.
RuntimeWire divulgó el problema a Moonshot AI el 14 de agosto, fijó como fecha límite de respuesta el 15 de agosto y ofreció un breve retraso en la publicación si la remediación estaba en curso. Moonshot no reconoció la divulgación ni respondió antes de la publicación.