La CLI de Grok Build subió todo tu repositorio en silencio — archivos .env incluidos
Un investigador que firma como cereblab descubrió que la CLI de Grok Build de xAI, versión 0.2.93, copiaba repositorios git enteros — secretos, historial completo, todo — a un bucket de Google Cloud Storage sin avisar al usuario.
Qué ocurrió
La herramienta hacía dos tipos de peticiones salientes. Las interacciones con el modelo iban a POST /v1/responses. Pero una llamada aparte POST /v1/storage empaquetaba todo el árbol de trabajo junto con el historial completo de .git y lo enviaba a gs://grok-code-session-traces.
Ese bucket pertenece a xAI. La subida se ejecutaba como un simple efecto secundario de usar la CLI — sin botón de “exportar”, sin aviso, sin advertencia.
Las cifras son abrumadoras. Con un repositorio de prueba de 12 GB y sin que el modelo leyera ningún archivo, /v1/responses transmitió ~192 KB. /v1/storage envió 5,10 GiB en 73 fragmentos. Una diferencia de 27.800×. El modelo usó 192 KB de contexto; los servidores de xAI recibieron tu repositorio entero.
La prueba canaria
cereblab colocó un archivo llamado never_read_canary.txt con una cadena única. El prompt fue literalmente “Reply with exactly: OK. Do not read or open any files.” El modelo cumplió con el texto. La cadena canaria apareció en el paquete subido.
Así que la exfiltración no la provocaba el modelo leyendo archivos bajo demanda. Era una pipeline incorporada que se ejecutaba sin importar lo que pidieras.
Por qué la exclusión voluntaria no funcionó
Hay una configuración llamada “Improve the model”. Desactivarla debería impedir que tus datos se usen para entrenamiento. La captura de cereblab mostró que el servidor seguía devolviendo trace_upload_enabled: true y upload_enabled: true. La subida continuaba.
La CLI tiene una bandera --deny que restringe qué archivos puede leer el modelo. Eso solo bloquea lecturas. No hace nada contra el tráfico de salida — el paquete ya iba de camino.
El gist lo resume sin rodeos: “Darse de baja no impide que tu repositorio salga de tu máquina.”
La fuga entre herramientas
La captura mostró que la herramienta también recogía archivos de ~/.claude/. Ese es el directorio de configuración de otro producto completamente distinto. Claves de servicios sin relación alguna — cereblab menciona una clave de API de Baidu Miaoda — abandonaban la máquina junto con tu repositorio.
Otro investigador que reprodujo los hallazgos descubrió 339 subidas automáticas en sus registros. Una de esas subidas contenía su directorio personal completo — potencialmente exponiendo claves SSH, datos del gestor de contraseñas, perfiles de navegador, absolutamente todo.
El interruptor de apagado remoto
El 12 de julio, mientras la historia se volvía viral, ocurrió algo que xAI nunca anunció: el mismo binario del cliente, con el mismo hash SHA-256, empezó de repente a recibir respuestas distintas del servidor.
disable_codebase_upload: true. trace_upload_enabled: false.
Las subidas se detuvieron. Sin actualización del cliente. Sin changelog. Sin notificación.
Esto significa que xAI siempre tuvo la capacidad de activar o desactivar remotamente la recolección de datos en cualquier instalación de la CLI de Grok, en cualquier momento, sin que el usuario lo supiera. Simplemente decidieron dejarlo activado por defecto y no mencionarlo nunca.
Musk responde
El 14 de julio, Elon Musk respondió a la polémica con una sola palabra: “True.” Y añadió:
“Como medida de precaución, todos los datos de usuarios subidos a SpaceXAI hasta ahora serán eliminados por completo y en su totalidad. No quedará absolutamente nada.”
xAI anunció simultáneamente un comando /privacy para la CLI de Grok:
/privacy— muestra tu estado actual de retención de datos/privacy opt-out— desactiva la retención y activa la eliminación retroactiva de los datos ya sincronizados
Andrew Milich, responsable de Grok Build, confirmó que cambiar la configuración de privacidad activa la eliminación de los datos en la nube previamente sincronizados. Los clientes enterprise reciben el modo “Zero Data Retention” (ZDR).
Pero esto es lo que no ha cambiado: no se emitió ningún aviso de seguridad. No hubo explicación de por qué se recopilaron repositorios enteros sin consentimiento. No hubo auditoría independiente de la eliminación. El changelog de la v0.2.98 omitió por completo cualquier mención a las subidas de repositorios.
Cómo comprobar si te afectó
- Ejecuta la CLI tras un proxy MITM:
HTTPS_PROXY=http://127.0.0.1:8080. Busca llamadasPOST /v1/storageal bucketgrok-code-session-traces. - Busca en el binario / cadenas el nombre del bucket hardcodeado
grok-code-session-traces. - El repositorio de reproducción de cereblab incluye un
verify.shque vuelve a descargar y desempaqueta los paquetes devueltos para que veas exactamente qué salió. - Revisa los registros de tráfico saliente hacia Google Cloud Storage durante cualquier sesión de la CLI de Grok.
- Ejecuta
/privacyen la CLI de Grok para ver tu estado actual de retención de datos. - Otro investigador encontró 339 subidas con solo revisar sus propios registros — si has usado la herramienta en algún momento, asume que tus repositorios salieron de tu máquina.
Qué hacer
- Ejecuta
/privacy opt-outinmediatamente para desactivar la retención futura y solicitar la eliminación de los datos ya subidos. - Desinstala por completo la versión afectada (0.2.93).
- Bloquea el tráfico saliente a Google Cloud Storage a nivel de red — una regla de firewall o una regla de rechazo de Clash:
(PROCESS-NAME,grok.exe) && (DOMAIN-SUFFIX,storage.googleapis.com). - Si no te queda más remedio que seguir usándolo, añade a
~/.grok/config.toml:[harness] disable_codebase_upload = true[features] telemetry = false[telemetry] trace_upload = false - Rota toda credencial que alguna vez haya estado en un repositorio abierto con esta versión. Los archivos
.envsuelen estar versionados o residir en el árbol de trabajo, y.gitignoreno te protege — el paquete incluía los archivos versionados de todas formas. Trátalo todo como comprometido.
Los datos se pueden borrar. La confianza no es tan fácil.
Referencias
- Borrador del informe: grokprivacy-draft
- Investigador: github.com/cereblab
- Repositorio de reproducción: cereblab/grok-build-exfil-repro
- Gist técnico: gist de cereblab