Todos los artículos
Noticias del sector15 sept 2026Fuente: Check Point Research

Un fallo de aislamiento de ChatGPT abrió un canal oculto entre cuentas

Sesiones separadas de agentes de IA se conectan por un servicio compartido imprevisto mientras un equipo de seguridad rastrea los datos

Check Point Research ha documentado un fallo de aislamiento entre cuentas en el entorno de ejecución de código de ChatGPT que podía convertir una conversación ordinaria en un canal oculto de tareas. En la prueba de concepto, la sesión de una víctima recuperó datos de una cuenta de Gmail conectada y los transmitió a otra cuenta de ChatGPT mientras la respuesta visible parecía normal.

El hallazgo se publicó el 8 de septiembre de 2026. Su relevancia depende del mecanismo exacto: el modelo no necesitó acceso directo a Internet, credenciales robadas ni una fuga convencional del contenedor. Los contenedores separados de ejecución podían llegar al mismo servicio interno de paquetes. Los metadatos modificables de ese servicio no estaban aislados por cuenta y podían transportar instrucciones y resultados entre sesiones.

La ruta afectada ya no está disponible. Check Point afirma que el canal había desaparecido cuando terminó su informe, y OpenAI confirmó que la instancia interna de Artifactory identificada había sido retirada. La publicación no demuestra una explotación generalizada ni identifica clientes afectados. Describe una investigación controlada realizada en junio y una prueba de concepto concreta.

Cómo funcionaba el canal oculto

ChatGPT creaba contenedores aislados para las tareas que requerían ejecutar código. Según Check Point, esos contenedores no podían comunicarse directamente entre sí ni acceder a Internet. Sin embargo, podían usar un servicio interno compartido de JFrog Artifactory para recuperar paquetes de software.

La recuperación de paquetes no era el problema. El servicio exponía operaciones que permitían a un contenedor añadir propiedades a un elemento del repositorio y leer esas propiedades después. Las credenciales disponibles dentro del contenedor tenían permisos suficientes para realizar ambas operaciones. Check Point escribió un valor de prueba desde una cuenta y recuperó el mismo valor desde otra. Los datos más grandes se podían dividir entre varias propiedades y recomponer.

Ese comportamiento creó lo que los investigadores describieron como un portapapeles compartido. Un atacante podía dejar una instrucción oculta en el canal. Una indicación maliciosa, una conversación compartida o un GPT personalizado podía ordenar a la sesión de la víctima que consultara esa instrucción en un turno posterior. La solicitud visible seguía recibiendo una respuesta ordinaria mientras una segunda tarea usaba las herramientas y permisos de la sesión de la víctima.

La demostración con Gmail muestra por qué una lectura puede tener consecuencias graves. Check Point dice que la víctima veía un pequeño aviso de que se había usado Gmail, pero aparecía después de la lectura y no revelaba la solicitud oculta ni los datos devueltos. La prueba conectó así tres límites que suelen revisarse por separado: aislamiento entre clientes, confianza en las instrucciones y autorización de aplicaciones conectadas.

Qué muestran las evidencias y qué no

La evidencia técnica principal procede del investigador de seguridad, no de un informe público de incidente de OpenAI. Los artículos independientes de TechRadar y The Register corroboran el mecanismo descrito, la demostración con Gmail y el cierre del canal identificado. Sin embargo, sus detalles técnicos dependen de la investigación de Check Point.

La investigación demuestra que la ruta funcionaba en el entorno probado. No demuestra que un atacante la utilizara contra clientes reales. Tampoco prueba que todas las funciones de ChatGPT, todos los tipos de cuenta o todas las aplicaciones conectadas estuvieran expuestos. El impacto dependía de las herramientas, los datos y los permisos disponibles en la sesión de la víctima.

La distinción es importante para responder a incidentes. Los equipos no deben tratar cada lectura anterior de Gmail o cada conversación compartida como evidencia de una intrusión. Deben usar el informe para comprobar si sus plataformas de agentes tienen estado interno compartido, credenciales de ejecución excesivas o lecturas sin un límite de autorización adecuado.

La lección de control supera un solo servicio

El aislamiento de contenedores es solo una capa del modelo de seguridad de un agente. Toda API interna, caché, proxy de paquetes, almacén de metadatos e interfaz de gestión accesible desde la ejecución debe formar parte del modelo de amenazas. Si un cliente puede modificar un estado que otro puede leer, el servicio puede convertirse en un canal encubierto aunque el aislamiento de red funcione según lo previsto.

Las aplicaciones conectadas amplían la posible consecuencia. Un entorno que pueda leer correo, código fuente, archivos o datos de colaboración debe recibir los permisos mínimos para la tarea vigente. Las lecturas sensibles deben evaluarse según el tipo de datos, solicitante, propósito y destino. No son de bajo riesgo solo porque no modifican un registro externo.

También importa la procedencia de las instrucciones. El texto heredado de una conversación compartida, una configuración de agente, un documento recuperado o un mensaje externo no debe obtener automáticamente la misma autoridad que la solicitud actual del usuario. La plataforma necesita separar instrucciones confiables de contenido no confiable e impedir que un texto oculto amplíe el alcance sin indicarlo.

Los equipos pueden probar estos límites con el entorno de Maetra Secure. La guía de registros de auditoría de IA ayuda a conectar indicaciones, llamadas a herramientas, acceso a datos y resultados sin recopilar contenido innecesario.

Preguntas para una revisión empresarial

Los equipos de seguridad y plataforma deberían inventariar todos los servicios compartidos que puede alcanzar un agente e identificar qué valores se pueden escribir o leer entre sesiones. Las credenciales de ejecución deben revisarse para encontrar permisos que excedan la recuperación de paquetes, en especial operaciones de metadatos y gestión.

También deben revisar las lecturas de aplicaciones conectadas. ¿Puede el usuario ver qué recurso se consultará antes de la acción? ¿La autorización está ligada a la tarea y a la identidad actuales? ¿Puede una instrucción heredada u oculta activar la lectura? ¿Los registros conservan el origen de la instrucción, la llamada a la herramienta, la categoría de datos devueltos y su destino?

Por último, deben probar la ruta completa de fallo. El equipo tiene que poder aislar una sesión, revocar o rotar credenciales, buscar identificadores inesperados entre sesiones y distinguir en una investigación un intento bloqueado de un acceso a datos ya completado.

Análisis de Maetra

La lección central de gobernanza es que la autorización debe seguir toda la ruta de la acción. Un entorno aislado de red puede funcionar correctamente mientras un estado compartido abre otro camino. Un permiso de herramienta puede ser válido para el usuario aunque la instrucción que lo invoca proceda de una fuente no autorizada.

La unidad práctica de control no es solo el contenedor o el conector. Combina cliente, sesión, fuente de la instrucción, herramienta, recurso, propósito y destino. Registrar y aplicar esa envolvente dificulta las tareas ocultas y ofrece evidencia útil cuando falla un límite.

El informe justifica volver a probar la infraestructura compartida y los permisos de aplicaciones conectadas. No demuestra que el canal cerrado siga siendo explotable ni que las cuentas de clientes fueran comprometidas de forma generalizada.

Fuentes

seguridad de ChatGPTaislamiento entre clientesaplicaciones conectadasacceso a datos de agentes