ZCode empaquetó 42.411 archivos en un comprimido que solo Zhipu podía abrir

El 18 de septiembre de 2026, un desarrollador que escribe bajo el nombre de ferstar publicó un análisis técnico de ZCode, el agente de programación con IA de escritorio creado por el desarrollador chino de modelos Zhipu AI, tras advertir que una carpeta oculta en su directorio personal había superado los 700 MB. Dentro encontró un archivo cifrado de 313 MB que contenía 42.411 archivos extraídos de un espacio de trabajo de 345 MB, el 86,6 % de ellos historial de Git, empaquetado por el cliente y preparado para su carga al almacenamiento de objetos de Alibaba Cloud. El archivo estaba sellado con una clave que solo los servidores de Zhipu podían desbloquear, y el cliente no ofrecía ningún interruptor que impidiera su creación. Zhipu se disculpó esa misma noche. El registro completo, con el grado de confianza y el estado de daño del propio archivo, se encuentra en el Orca AI Incident Archive, que registra cada incidente de IA documentado junto con sus fuentes citadas.

ZCode es el agente de programación de escritorio de Zhipu: lee un proyecto, ejecuta comandos de shell y escribe código. La empresa cotiza en Hong Kong con el ticker 2513.HK y comercializa su división internacional como Z.ai, el nombre que aparece en los servidores de ZCode que inspeccionó ferstar. The Paper, el medio de noticias de Shanghái que lo entrevistó a él y a varios otros desarrolladores después, informa que su publicación se titulaba, aproximadamente, «Levantando el telón sobre la subida silenciosa del historial completo de Git por parte de ZCode», y que se difundió entre grupos de desarrolladores chinos en cuestión de horas tras su publicación.

¿Qué había dentro de la carpeta oculta?

Las propias cifras de Ferstar son la columna vertebral del caso, y The Next Web, InfoQ y la sección financiera de China National Radio las han reproducido de manera consistente. El archivo de su directorio de puntos de control de ZCode era de 313 MB. El archivo de estado junto a él registraba un espacio de trabajo de unos 345 MB y 42.411 archivos. El directorio .git representaba el 86,6 % de la carga útil: 196,1 MB de caché de almacenamiento de archivos grandes de Git, 102,2 MB de objetos de Git que contenían el historial completo de confirmaciones y una pequeña porción de reflog. El código fuente y la documentación reales representaban aproximadamente el 13,4 %.

La distinción importa porque el historial de Git es donde tiende a sobrevivir el material que se ha eliminado del árbol actual. El relato de The Paper lo deja claro directamente: un archivo de este tipo puede contener el historial de edición de un proyecto desde su primer commit, contenido eliminado, borradores no confirmados y archivos de configuración más antiguos, incluidas credenciales que se eliminaron del código hace mucho tiempo pero que permanecen en commits anteriores y en la caché de archivos grandes.

El propio archivo de 313 MB de Ferstar nunca salió de su máquina. Su registro de estado mostró 564 intentos de carga fallidos, y se había quedado estancado en un estado pendiente, por encima del límite de tamaño. Para probar si la canalización funcionaba siquiera, probó un pequeño repositorio público de 538 archivos; esa instantánea se comprimió y cifró hasta aproximadamente 15 KB y fue aceptada por el servidor. Esa transferencia es la que consta en el registro como confirmada de haberse completado de extremo a extremo, y es lo que convierte el hallazgo de un ejercicio de lectura de código en una exfiltración con un extremo receptor demostrado.

La captura no estaba vinculada a ninguna acción que un usuario reconociera como "subir mi repositorio". Según la reconstrucción de ferstar, un disparador se activaba antes de cada prompt enviado al modelo, y otro se ejecutaba como una tarea de actualización de Repo Wiki. Eliminar el archivo pendiente no lo detuvo: un artículo en la comunidad de desarrolladores de Tencent Cloud registra que el paquete se reconstruyó en un plazo de 30 minutos y que el contador de fallos avanzó de 564 a 565. La única forma fiable de detenerlo que encontró ese autor fue hacer que el directorio de checkpoints no se pudiera escribir, de modo que la captura fallara en la escritura en disco, a costa de perder la reversión a checkpoints y la interfaz de la línea de tiempo.

Una clave que solo el proveedor podría usar

El cifrado era cifrado de sobre de manual, y esa era la parte que los usuarios no podían sortear. La reconstrucción de InfoQ, basada en la ingeniería inversa de ferstar, describe que el cliente obtenía un ID de instantánea, una clave pública RSA y credenciales de carga de Alibaba Cloud OSS desde zcode.z.ai, empaquetaba y cifraba el espacio de trabajo localmente y luego enviaba el texto cifrado directamente a OSS. El contenido se cifraba con AES-256-CTR; la clave simétrica se envolvía con RSA-OAEP-SHA256 bajo la clave pública del servidor, cuya mitad privada permanecía en la nube de Zhipu.

El enrutamiento es tan importante como la criptografía. Como el cliente subió directamente a Alibaba Cloud en lugar de hacerlo a través de los propios servidores de aplicaciones de Zhipu, el tráfico no pasó por ningún servicio de Zhipu que pudiera registrarlo o filtrarlo, así que ningún servicio de Zhipu estaba en la ruta para registrar o filtrar lo que salía. Y como la clave privada nunca estuvo en el dispositivo, ferstar no pudo abrir su propio archivo: The Next Web informa que probó todas las claves privadas de su máquina y falló. En su publicación, describió el mecanismo como una clave que solo el servidor puede usar, la cual tiene un único propósito.

Dos ajustes del cliente parecían deber haber detenido esto, y ninguno lo hizo. El interruptor «optimizar la experiencia» regía si los datos podían usarse para el entrenamiento del modelo; el interruptor «indexación de instantáneas del repositorio» regía si el servidor creaba un índice sobre las instantáneas que ya habían llegado. Ambos actúan en una fase posterior a la captura. Ferstar descubrió que la captura se ejecutaba de forma incondicional, y The Next Web informa de que, según su lectura de la política de privacidad, esta describía la recopilación de texto de conversaciones y archivos, pero no decía nada sobre instantáneas automáticas del espacio de trabajo que contuvieran el historial completo de Git.

La explicación que dio Zhipu, y los cuatro días posteriores.

Zhipu respondió ese mismo día, a través del grupo oficial de usuarios de ZCode en lugar de mediante un comunicado de prensa. Según lo informado por Global Times y reproducido por Security Inside, la empresa atribuyó el comportamiento a una función llamada indexación de bases de código, que admite indexación local, restauración de puntos de control de sesión, reversión de versiones y generación de Repo Wiki, y señaló que el paso de Repo Wiki fue lo que provocó las cargas de repositorios a la nube. La función había estado activada por defecto desde su lanzamiento. Zhipu afirmó que los datos cargados se utilizaron únicamente para generar la página de Repo Wiki y se destruyeron inmediatamente después, que no se almacenaron ni se usaron para entrenamiento, y se disculpó con los usuarios afectados. Prometió publicar como código abierto el código base de ZCode, invitar a una revisión de terceros y publicar los resultados, y ofreció a cada usuario de ZCode un restablecimiento adicional de cuota semanal como compensación.

La corrección llegó al día siguiente. The Paper informa de que ZCode 3.14.0 se publicó el 19 de septiembre con una entrada en el registro de cambios que decía «corrige el problema anómalo de carga del wiki del repositorio», y que ferstar confirmó ese mismo día que la cadena de carga y su endpoint habían desaparecido. El 20 de septiembre, la plataforma MaaS de Zhipu anunció una próxima opción de retención cero según la cual las entradas y salidas no se almacenarían de forma estática; The Paper señala que se activa previa solicitud, excluye Batch API y File API, y aún permite la retención de 30 días o más cuando la ley o una investigación de abuso lo exijan. El 21 de septiembre, el código fuente del cliente se hizo público en GitHub bajo la licencia Apache 2.0, abarcando la aplicación de escritorio, el cliente web, el backend, la CLI de agente y el entorno de ejecución de agente.

Se encargaron dos auditorías y sus conclusiones se publicaron como resúmenes. La Academia China de Tecnologías de la Información y las Comunicaciones halló el bucket OSS de Alibaba Cloud zcode-prod en lo que Zhipu denomina un estado de cero datos. La empresa de seguridad NSFOCUS informó de que todos los objetos de datos y el propio bucket habían sido eliminados, y de que no encontró ninguna ruta restante en ZCode 3.14.0 que pudiera activar una instantánea del repositorio local ni enviar archivos al exterior. El informe completo de la evaluación no ha aparecido, y The Next Web informa de que Zhipu no ha dado ninguna fecha para él.

El cliente que alegó más, luego lo retiró

La afirmación más grave de pérdida real no provino de ferstar. El 19 de septiembre, según China National Radio, Taiyuan Chengming Technology envió a Zhipu una carta legal con el número Chengming [2026] Legal Letter No. 1, reproducida en detalle por ChainCatcher. La empresa dijo que seis de sus espacios de trabajo de programación se habían subido sin consentimiento —34.500 archivos y aproximadamente 425 MB en texto plano— y enumeró código fuente completo, arquitectura del sistema, historial de versiones, contraseñas de bases de datos, credenciales en la nube e información personal de empleados. Dijo que un séptimo espacio de trabajo de 1.947 archivos y unos 144 MB se había empaquetado y cifrado, pero falló en 32 reintentos de subida. También señaló que su cliente se había actualizado a la versión 3.12.3 el 16 de septiembre, pero aún se detectaron subidas a las 00:28 del 18 de septiembre, la mañana en que Zhipu se disculpó.

La carta planteaba una pregunta que las auditorías no responden: si los datos salieron del país. Chengming afirmó que las solicitudes de red de ZCode apuntaban a una entidad de Singapur, mientras que su acuerdo de servicio estaba firmado con Beijing Zhipu Huazhang, y pidió a Zhipu que identificara qué parte era responsable y si se había producido alguna transferencia o almacenamiento fuera de China continental. La carta exponía doce exigencias, entre ellas eliminar todos los datos subidos y sus derivados, cachés y copias de seguridad con un certificado por escrito, explicar a dónde fueron los datos y si se compartieron con terceros o se usaron para entrenamiento, describir cómo se custodia la clave privada y presentar registros de acceso, definir el alcance exacto de la afirmación de "destruido" y comprometerse por escrito a no volver a subir datos. Daba a Zhipu hasta el 10 de octubre para responder por escrito y se reservaba el derecho a reclamar daños y perjuicios y a presentar quejas ante los reguladores. Caixin Global informa de que Zhipu calificó las acusaciones de falsas.

Dos días después, Chengming las retiró. La sección financiera de Radio Nacional de China informa que el 21 de septiembre la empresa emitió una retractación en la que decía que sus declaraciones anteriores se basaban en pruebas erróneas, una descripción imprecisa y una redacción exagerada, que habían dañado la reputación de Zhipu y que dejaría de hablar con los medios. Reuters también informó de la retirada, según The Next Web. La entrada de archivo de este incidente está fechada el 18 de septiembre, el día del descubrimiento; la carta, su plazo del 10 de octubre y la retractación llegaron todos después de esa fecha. Según el registro público a finales de octubre, ninguna empresa identificada respalda la afirmación de que sus secretos quedaron expuestos.

Una versión de código abierto con su historial borrado

Abrir el código del cliente fue el remedio en el que Zhipu más se apoyó, y venía con una laguna. The Paper informa de que el repositorio publicado contiene dos commits: un commit inicial vacío y un único commit que añade unos 6.973 archivos y 1,03 millones de líneas, con las pull requests bloqueadas y los issues cerrados. Cómo fuera el pipeline de carga cuando se publicó, y qué versiones lo contenían, no está en el historial que cualquiera pueda leer ahora.

El propio seguimiento de Ferstar deja explícito el límite. Confirmó que el pipeline de carga ya no existía y que el mecanismo de checkpoint restante solo realiza trabajo local de Git; luego señaló qué podía y qué no podía demostrar una auditoría del bucket: vaciar y eliminar el bucket es la acción correcta para limitar pérdidas, pero una verificación de terceros realizada después del 20 de septiembre solo puede establecer que el bucket estaba vacío en ese momento. No puede reconstruir qué pasó por allí antes del 18 de septiembre, si algo se descifró, se copió o se respaldó, ni cuánto tiempo había estado funcionando el pipeline. Una afirmación de eliminación aún depende en gran medida de la palabra de la parte que eliminó.

El análisis de InfoQ enumera las preguntas que quedan abiertas en los mismos términos: cuántas instantáneas de repositorio se subieron correctamente y por cuántos usuarios, cuánto tiempo se conservaron los objetos, qué sistemas del lado del servidor o qué personal podrían descifrarlos, si existe un registro de acceso completo y si la eliminación abarcó las copias de seguridad y otras copias. También señala qué sigue siendo ZCode después de la corrección. El propio NOTICE del proyecto advierte que el entorno de ejecución compartido del agente no ofrece de forma predeterminada un sandbox a nivel de sistema operativo, y que el cliente conserva superficies de shell, terminal, Git, MCP, plugins y navegador integrado que pueden leer archivos, iniciar procesos y acceder a la red dentro de los permisos de la cuenta del usuario.

Qué está establecido y qué no responde ninguna fuente

El mecanismo no está en disputa. Las propias declaraciones de Zhipu admiten que se subieron datos de repositorios, que la función estaba activada por defecto y que los datos fueron a un bucket en la nube controlado por la empresa. Las mediciones de Ferstar, la disculpa del proveedor, dos auditorías encargadas y la publicación de código abierto describen la misma cadena. Nada en el expediente contradice que los espacios de trabajo salieran de las máquinas sin una opción de exclusión viable. El daño que registra el expediente es real, no hipotético: las transferencias ocurrieron, y las personas cuyo código estaba dentro de ellas no pudieron impedirlas ni inspeccionarlas.

Lo que está en disputa, o simplemente se desconoce, es la escala y las consecuencias. Ninguna fuente indica cuántos usuarios usaron los valores predeterminados afectados, cuánto tiempo funcionó el pipeline antes del 18 de septiembre ni si algún objeto cargado llegó a descifrarse. La garantía de Zhipu de que los datos se destruyeron después de la generación de la wiki y nunca se usaron para entrenamiento es una declaración de la propia empresa; las conclusiones de CAICT y NSFOCUS describen el estado del bucket después de la corrección, no lo que pasó por él. El archivo califica el registro con A en documentación, y la documentación es sólida en cuanto al mecanismo y escasa en cuanto al alcance.

Qué cambió y qué no

El costo comercial fue inmediato. China National Radio informa que las acciones de Zhipu cotizadas en Hong Kong cayeron un 1,79 % el 21 de septiembre, un 6,55 % el 22 de septiembre y un 12,4 % el 23 de septiembre, una caída acumulada de más del 16 % en tres sesiones de negociación, y que Zhipu no abordó cuántos usuarios se vieron afectados ni si los datos históricos habían sido descifrados o respaldados.

Lo que un usuario de ZCode recibió realmente en los cuatro días posteriores al descubrimiento:

• 18 de septiembre: una disculpa pública que señala la indexación del código base como la causa, la promesa de publicar el cliente como código abierto y encargar una revisión por terceros, y un restablecimiento adicional de la cuota semanal por usuario.

• 19 de septiembre: ZCode 3.14.0, con Repo Wiki eliminado y la ruta de generación y carga de instantáneas locales cortada. Ferstar confirmó que la cadena de carga había desaparecido al día siguiente.

• 20 de septiembre: una opción anunciada de retención cero para la plataforma MaaS de Zhipu, de adhesión voluntaria (opt-in), que excluye Batch API y File API, y que además sigue sujeta a la retención legal de 30 días o más.

• 21 de septiembre: ZCode se publicó bajo Apache 2.0 sin su historial de commits previo al incidente; los resúmenes de CAICT y NSFOCUS informaron que el bucket de almacenamiento estaba vacío y que la ruta de salida no existía.

Nada de eso tiene efecto retroactivo. Las preguntas concretas que planteó Chengming —adónde fueron los datos, quién podía descifrarlos, si salieron del país y qué abarcaba «destruido»— se pusieron por escrito con un plazo del 10 de octubre y luego se retiraron junto con la empresa que las formuló. Zhipu ha prometido un informe completo de evaluación por terceros sin fecha. Hasta que aparezca uno, el único relato público de lo que el pipeline hizo con los datos que recibió es el de la empresa que lo construyó, y el único artefacto medible de forma independiente es un archivo de 313 MB que fracasó 564 veces en su intento de salir del portátil de un desarrollador.