2 min de lectura

Grok Build envió repositorios completos a Google Cloud

Investigadores hallaron que Grok Build estaba subiendo repositorios enteros, incluidos archivos ignorados y secretos eliminados. SpaceXAI ha desactivado ese comportamiento.

Imagen: The Verge

SpaceXAI ha desactivado un comportamiento de Grok Build que estaba subiendo los repositorios de código completos de los usuarios a Google Cloud, después de que investigadores afirmaran que la herramienta estaba recopilando muchos más datos de lo esperado.

Según The Register, Cereblab publicó el lunes hallazgos que muestran que la CLI de Grok Build empaquetaba y subía bases de código completas, incluidos archivos que se le había dicho que no abriera e incluso secretos eliminados del historial. Los investigadores indicaron que esto suponía una retención de datos significativamente mayor que la de herramientas comparables como Claude Code.

A partir del lunes, Cereblab dijo que sus pruebas mostraron que los servidores de SpaceXAI devolvían una bandera 'disable_codebase_upload: true' y que el comportamiento de subida 'ya no se activa'.

Elon Musk se refirió al incidente en publicaciones en X, afirmando que todos los datos que Grok Build había subido previamente serían 'completamente y absolutamente eliminados'. En una publicación aparte, también dijo que 'siempre se respetan los ajustes de privacidad', al tiempo que pidió a los usuarios que permitan a SpaceXAI conservar datos porque son 'útiles para depurar problemas'.

El Dr. Lukasz Olejnik, investigador de seguridad independiente en King’s College London, dijo a The Verge que este nivel de retención es 'excesivo'. Añadió que los datos expuestos podrían incluir potencialmente:

Recomendado

Microsoft refuerza las defensas OAuth tras los ataques de ShinyHunters

  • código fuente propietario
  • información sobre vulnerabilidades de seguridad
  • datos personales
  • detalles de la infraestructura
  • credenciales

SpaceXAI respondió inicialmente diciendo que si la retención cero de datos está deshabilitada, los usuarios pueden ejecutar el comando /privacy en la CLI para desactivar la retención y eliminar los datos previamente sincronizados. Pero Cereblab refutó esa explicación, diciendo ' /privacy es un interruptor de retención por sesión, no el interruptor que solucionó esto, por lo que no debería señalarse como el control.'

Sophia Reynolds

Security Editor

Sophia unpacks the invisible wars happening on our networks. Covering cybersecurity, privacy legislation, and cryptography, she exposes how our data is weaponized and defended. Before joining for(geeks), she spent years as a penetration tester. She's the reason the rest of the team uses physical security keys.

vía The Verge

// Sigue leyendo