Grok Build subió repositorios Git completos al almacenamiento de xAI (sin autorización)

La interfaz de línea de comandos (CLI) de codificación Grok Build de xAI estaba subiendo repositorios Git completos, con todo el historial de confirmaciones incluido, a un bucket de Google Cloud Storage administrado por xAI, y no solo los archivos necesarios para una tarea de codificación.

Un investigador que publica bajo el seudónimo de cereblab, probando la versión 0.2.93, capturó una de estas cargas, clonó el paquete Git de la solicitud interceptada y recuperó un archivo que el agente tenía instrucciones explícitas de no abrir.

La carga utiliza un canal independiente del modelo, y la distribución de bytes es difícil de refutar. En un repositorio de 12 GB con archivos que el modelo nunca leyó, el tráfico de la función `model-turn` hacia `/v1/responses` alcanzó aproximadamente 192 KB, mientras que el canal de almacenamiento hacia `/v1/storage` movió 5,10 GiB, una diferencia de aproximadamente 27.800 veces entre lo que el modelo necesitaba y lo que salía de la máquina.

La carga del almacenamiento se realizó en 73 fragmentos de aproximadamente 75 MB, cada uno devolviendo un código HTTP 200. Durante el análisis del tamaño del repositorio, el volumen rastreado representó el tamaño total del repositorio. El bucket de destino, grok-code-session-traces, se nombra en el binario y en un archivo metadata.json preparado, cuyas rutas de archivo apuntan a gs://grok-code-session-traces/.

El archivo no leído era src/_probe/never_read_canary.txt, al que se le añadió un marcador único. La clonación del paquete capturado lo recuperó tal cual, junto con el historial completo de confirmaciones del repositorio, y la misma prueba se replicó en un segundo repositorio independiente. Lo que establecen las capturas es la transmisión, la aceptación y el almacenamiento, no el entrenamiento.

El análisis de limpieza no afirma que xAI se haya entrenado con el código, que el personal lo haya leído ni que los archivos ignorados por Git se incluyan siempre. Lo que muestra la red son los archivos rastreados y el historial.

La ruta secreta es independiente y sencilla. Cuando Grok lee un archivo, su contenido pasa al modelo y un archivo .env rastreado se envía con él sin censurar, con los valores API_KEY y DB_PASSWORD incluidos. El mismo contenido también se guarda en un archivo session_state destinado al almacenamiento. Los secretos introducidos eran falsos, por lo que no se filtró información real en la prueba. El problema persiste: un archivo de credenciales que el agente leyó durante una tarea se envió y se almacenó sin censurar.

Un repositorio puede contener código propietario, URL internas, datos de clientes y credenciales que se eliminaron del árbol de trabajo, pero que aún permanecen en el historial de confirmaciones. En la comparación entre herramientas realizada por Cereblab, Claude Code y Codex se encuentran en el paquete del repositorio; Gemini no envió nada en una prueba inactiva, aunque su ejecución de tarea realista se bloqueó por cuota antes de finalizar.

Respuesta de xAI: El 13 de julio, el mismo binario 0.2.93 dejó de realizar solicitudes de almacenamiento. Cereblab realizó seis pruebas y no detectó ninguna carga en /v1/storage, y el servidor ahora devolvía disable_codebase_upload: true y trace_upload_enabled: false.

El desarrollador Peter Dedene informó que se devolvió el mismo indicador para su cuenta, por lo que el cierre no fue solo una observación de Cereblab en una sola máquina. El cliente probado permaneció en la versión 0.2.93 mientras se modificaban los ajustes de su servidor, por lo que se trató de un cambio del lado del servidor, no de una corrección incluida en una actualización. xAI no ha confirmado si afecta a todas las cuentas o si es permanente.

Fuente: THN

Suscríbete a nuestro Boletín