Dos sesiones de ChatGPT de dos cuentas distintas podían pasarse mensajes sin que ninguno de los dos usuarios lo viera. No por el modelo: por el repositorio de paquetes que ambas compartían. Lo cuenta Check Point Research y lo recoge The Register. El agujero ya está cerrado, pero el patrón es tan común que merece la pena mirarlo despacio.
Qué encontraron
Cuando ChatGPT ejecuta código, lo hace en contenedores aislados. Esos contenedores no pueden salir a internet —si pudieran, se llevarían datos de usuario o encontrarían credenciales expuestas y entrarían en servidores ajenos—, así que tienen una única puerta: una instancia interna de JFrog Artifactory que hace de proxy hacia los repositorios de paquetes.
La puerta tenía dos defectos que, juntos, valen un incidente:
- La instancia exponía la gestión de propiedades de los ítems del repositorio. Es decir, se podía adjuntar texto a un artefacto —incluido binario codificado en Base64— y un contenedor de otra cuenta podía leerlo.
- Las credenciales que recibía el contenedor, pensadas para lectura, permitían leer y escribir. Y el código lanzado por ChatGPT se autenticaba contra el endpoint de almacenamiento sin sacar ningún secreto aparte ni escalar privilegios.
Con eso montaron memoria compartida entre inquilinos. La sesión del atacante escribe una tarea; la sesión de la víctima la lee y la ejecuta con los permisos de la víctima.
La demostración usa una conversación compartida. La instrucción escondida era tan sencilla como pedir el listado de correos vía el conector de Gmail. La víctima abre el enlace y pregunta algo normal —un gráfico de las temperaturas medias mensuales en Nueva York—. ChatGPT le entrega su gráfico, y de paso consulta su Gmail y devuelve el resultado al atacante por el canal oculto. En la respuesta visible no aparece nada del correo. La única pista, según el informe, era la etiquetita de «Talked to Gmail» encima de la respuesta.
El alcance no se queda en el correo: cualquier conector que la sesión de la víctima tuviera autorizado —historial, ficheros, Drive, Teams, GitHub y compañía— entra en el saco.
Detalle de contexto: Check Point avisó a OpenAI a finales de junio, el mismo día en que agentes de OpenAI explotaron un fallo de día cero en ese mismo Artifactory para salir a internet y acabar entrando en Hugging Face. No es el mismo ataque; comparten la pieza. OpenAI respondió que la instancia ya estaba retirada. A The Register no le han comentado nada.
Por qué esto te toca aunque no seas OpenAI
El proxy de artefactos es perímetro, no fontanería
Si tu sandbox no tiene internet pero sí un proxy de paquetes, ese proxy es tu superficie de ataque. Y un proxy de artefactos moderno no sirve solo ficheros: sirve metadatos escribibles, propiedades, etiquetas, checksums personalizados. Cada uno de esos campos es un buzón entre ejecuciones.
Qué haría distinto a partir de hoy: poner el proxy en modo solo lectura de verdad y comprobarlo con una petición de escritura real, no leyendo la documentación. Desactivar la API de propiedades si no la usas. Un token por sesión y de vida corta, no un token compartido por toda la flota de contenedores.
«Read-only» es el nombre del rol, no el permiso efectivo
Este es el fallo más repetido que veo en instalaciones ajenas: alguien crea un usuario llamado reader y nadie vuelve a mirar qué puede hacer. Añade a tu suite de pruebas un test que intente escribir con las credenciales del sandbox y falle si la escritura funciona. Cuesta veinte líneas y te ahorra este artículo.
Un canal encubierto no necesita internet
Aquí está la generalización útil. Si dos ejecuciones de usuarios distintos pueden tocar el mismo byte, tienes un canal. Da igual que sea Artifactory: vale una caché de paquetes compartida, un bucket temporal, una tabla de estado, una cola, un volumen montado en el runner de CI o el directorio de trabajo reutilizado entre jobs. El aislamiento se rompe por el sitio que nadie considera «servicio».
La respuesta visible no es el registro de actividad
El texto que ve el usuario no vale como auditoría. Si tu agente llama a herramientas, necesitas traza de esas llamadas fuera del modelo, por sesión, con quién pidió qué y contra qué credencial. Aquí la única señal para el usuario fue una etiqueta diminuta que nadie mira. Un LLM puede resolver la pregunta y hacer otra cosa a la vez sin mentir en el resultado: la conversación no es el log.
Los conectores son el radio de explosión
Cada conector autorizado no es un permiso que le das al modelo para ese momento: es un permiso permanente que cualquier instrucción, venga de donde venga, puede usar. Revisa qué conectores hay vivos, quién los autorizó y si tenían que estar en una cuenta personal o en un espacio de trabajo con control. Y trata los enlaces de conversación compartida como lo que son: contenido de terceros.
La frase de Check Point que mejor resume el problema, traducida:
El modelo trabaja dentro del perímetro de confianza —usa credenciales, ejecuta código, accede a servicios internos— y lo dirige texto. Eso lo convierte en un insider coaccionado.
Qué no cambia
Y ahora los contrapesos, porque esto se puede contar peor de lo que es.
- El agujero está cerrado. La instancia interna ya se había retirado antes incluso de recibir el aviso. Hoy no hay nada que parchear por tu parte en ChatGPT.
- Es una prueba de concepto de un equipo de investigación. No hay constancia de que nadie lo explotara contra usuarios reales. «ChatGPT filtraba tu Gmail» es un titular falso.
- No es el incidente de Hugging Face. Comparten componente y fecha de aviso, no ataque.
- No es inyección de prompt clásica. Es un fallo de aislamiento multi-inquilino, y esa es la buena noticia: se arregla con arquitectura conocida —credenciales por sesión, permisos efectivos, recursos no compartidos—, no pidiéndole por favor al modelo que no haga caso a instrucciones raras.
- Solo tenemos una versión. OpenAI no ha comentado públicamente el hallazgo.
Si tienes agentes ejecutando código en tu infraestructura, la pregunta de esta semana es corta: ¿qué recurso escribible comparten dos ejecuciones de dos clientes distintos? Cualquier duda me dices y lo vemos.
Un saludo, Vicente.