Advertencia para desarrolladores: Grok Build cargó todo el directorio de inicio en xAI; la clave SSH y el llavero de contraseñas quedaron completamente expuestos

13 de julio, el desarrollador A Green Being publicó en la plataforma X una captura de pantalla del registro unified.json, acusando a la herramienta de desarrollo Grok Build de xAI, propiedad de Elon Musk, de subir toda su carpeta de usuario al servidor de xAI; el contenido filtrado incluye sus claves SSH, bases de datos de gestores de contraseñas, documentos personales, fotos y videos — “todo ha sido filtrado”.

Evidencia de la captura de pantalla del registro de A Green Being

(Origen: A Green Being)

Según la captura de pantalla del registro unified.json compartida por A Green Being en la plataforma X, el sistema efectivamente activó numerosas solicitudes repo_state.upload.start, y la ruta de subida apunta directamente a la carpeta personal del usuario (/home/usuario); esto implica que Grok Build, sin filtrar ni excluir archivos específicos, ha enviado todos los archivos locales que contienen información extremadamente sensible (claves SSH, bases de datos de gestores de contraseñas, fotos, videos) a los endpoints en la nube de xAI.

A Green Being indica que fue por ejecutar accidentalmente la herramienta Grok Build en su carpeta personal (Home Directory), lo que provocó esta catástrofe de privacidad. CyberSatoshi respondió: “Tú estás peor que yo, ejecutaste Grok directamente en tu directorio personal.”

Recomendaciones de seguridad: evitar ejecutar en la carpeta personal, usar sandbox y monitoreo de logs

Según expertos en ciberseguridad, para los desarrolladores que ya usan o consideran usar herramientas de desarrollo asistidas por IA como Grok Build, se recomiendan las siguientes medidas de protección:

· Evitar ejecutar estas herramientas en la carpeta personal o en el directorio raíz

· Utilizar entornos aislados: en entornos virtuales (Sandbox), contenedores Docker, o creando cuentas de usuario con permisos limitados

· Monitorear activamente los logs: mediante comandos en terminal (cat ~/.grok/logs/unified.json | grep repo_state.upload) para detectar comportamientos anómalos de subida de datos

· Revisar inmediatamente los logs históricos: si se ha usado Grok Build, verificar los archivos de logs en la máquina local para confirmar si hubo filtración de datos

Preguntas frecuentes

¿Por qué Grok Build sube toda la carpeta personal y no solo el código del proyecto?

Según los informes, Grok Build, al realizar subidas en segundo plano, carece de mecanismos adecuados para excluir archivos (como ignorar automáticamente .gitignore o archivos ocultos del sistema); cuando el usuario ejecuta la herramienta en su carpeta personal, su diseño subyacente considera toda la carpeta como “contexto” y la sube en su totalidad, en lugar de solo los archivos de código. Esto es resultado de un fallo en el diseño de la herramienta y un uso inapropiado por parte del usuario.

¿Qué riesgos específicos advirtió CyberSatoshi anteriormente?

Según los informes, CyberSatoshi (@XBToshi) advirtió previamente que Grok Build, en segundo plano, sube silenciosamente todo el repositorio, incluyendo el historial de Git y archivos ocultos como .env con claves API y otros secretos, a Google Cloud Platform (GCP), y que esto podría ser utilizado para entrenamiento de modelos en el futuro; además, llamó a los desarrolladores a revisar inmediatamente los logs locales de Grok.

¿Cómo puedo verificar si mi equipo ha subido datos con Grok Build?

Según los informes, se puede consultar en la terminal con: cat ~/.grok/logs/unified.json | grep repo_state.upload. Si en los logs aparecen muchas entradas de repo_state.upload.start y las rutas de subida apuntan a la carpeta personal o raíz, significa que los datos han sido enviados a la nube; se recomienda detener el uso de Grok Build en entornos no aislados y evaluar si es necesario cambiar claves sensibles (SSH, API).