Qué vulnerabilidad se comunicó

El problema no consiste en que el cifrado AES-256-GCM esté roto. La técnica explota la frontera entre los filtros de seguridad de Grok, su entorno de ejecución de código y sus herramientas de navegación.

La página maliciosa incluye un bloque de instrucciones cifradas junto con el material necesario para descifrarlo. Durante la primera revisión, las defensas contra la inyección de instrucciones ven texto cifrado, no la orden en claro. Después, el agente es inducido a ejecutar una rutina de descifrado en su entorno de Python o de ejecución de código. Una vez recuperado, el comando vuelve al modelo como resultado de una herramienta, un tipo de contenido que el agente puede tratar de forma distinta a una instrucción no confiable incrustada directamente en una página web.

Adversa informó que probó la técnica contra Grok 4.5 Fast en grok.com. Una descripción independiente de esas pruebas indicó que el ataque tuvo éxito en el 40 % de 20 intentos realizados entre junio y agosto de 2026. Esa cifra corresponde al entorno de pruebas de los investigadores; no significa que todas las sesiones de Grok ni todos los intentos fueran vulnerables.

Así funciona el ataque de la página cifrada

La cadena de ataque descrita por los investigadores tiene varias etapas:

1. La página transporta la carga oculta. El atacante coloca en un sitio web que parece contenido normal un texto cifrado, instrucciones para descifrarlo y material criptográfico. La construcción descrita utiliza claves derivadas mediante PBKDF2 y cifrado AES-256-GCM.

2. El análisis inicial no detecta la orden. Los filtros de Grok pueden inspeccionar el contenido visible, pero la instrucción peligrosa está escondida dentro de datos cifrados. El cifrado impide que el modelo interprete directamente el comando durante esa primera pasada.

3. El agente ejecuta el descifrado. Cuando el usuario le pide a Grok que resuma o analice la página, el agente sigue las indicaciones del sitio y ejecuta el proceso de descifrado en su entorno de código.

4. La instrucción vuelve al contexto del agente. El texto descifrado aparece como el resultado de una operación de herramienta. Esto crea un problema de procedencia: el contenido controlado por el atacante ha pasado de una página no confiable a un contexto que el agente puede interpretar como un resultado operativo.

5. Grok consulta datos de la sesión. En la prueba de concepto, las instrucciones descifradas le indicaban recuperar valores como el nombre del usuario, su ubicación aproximada, el nivel de suscripción y los mensajes o el contexto de la conversación disponible para el agente.

6. Una petición web saca los datos del entorno. Grok abría después una URL controlada por el atacante e incluía la información recopilada en sus parámetros de consulta. Según la demostración divulgada, la transferencia se completaba sin una confirmación adicional ni una advertencia visible.

Un límite importante sobre la «historia completa»

La evidencia disponible respalda el acceso a los mensajes y al contexto que el agente tenía disponibles en la sesión activa. Por eso, las referencias a una «historia completa del chat» no deben interpretarse automáticamente como acceso a todas las conversaciones almacenadas en la cuenta del usuario.

Cuándo se informó a xAI y cuál era el estado del parche

Adversa afirmó que comunicó el problema a xAI a través de HackerOne el 3 de junio de 2026. Posteriormente envió seguimientos para coordinar la divulgación el 4 y el 10 de agosto.

Al 19 de agosto de 2026, la empresa de seguridad dijo que no había recibido una respuesta sustantiva y que todavía podía reproducir el ataque contra Grok. La información publicada en ese momento describía el problema como carente de un parche desplegado, un identificador CVE público y una solución disponible para los usuarios.

Ese estado procede del informe de los investigadores y de las publicaciones que lo cubrieron, no de un aviso de seguridad público de xAI. Las fuentes disponibles tampoco demuestran que el método hubiera sido utilizado contra usuarios reales fuera de las demostraciones de investigación.

Por qué el cifrado puede dejar ciegas a las defensas

Muchas defensas tradicionales contra la inyección de instrucciones buscan lenguaje sospechoso en el contenido que recupera un sistema de IA. Cryptographic Context Injection desplaza la orden peligrosa a una fase posterior del procesamiento.

El modelo no necesita comprender el comando malicioso cuando escanea la página por primera vez. Solo tiene que seguir una indicación aparentemente útil —por ejemplo, ejecutar una rutina de descifrado— dentro de un entorno que considera confiable. La orden se vuelve legible después de esa ejecución, cuando el agente puede tener acceso al contexto privado y permisos para navegar o realizar solicitudes de red.

Por eso, la vulnerabilidad se entiende mejor como un problema de arquitectura del agente que como un simple fallo de filtrado por palabras clave. Cuando un agente puede leer contenido externo, ejecutar código, acceder a datos de sesión y utilizar herramientas de red, una instrucción maliciosa puede convertir esas capacidades en una ruta de extracción de información.

El problema más amplio de la seguridad de los agentes de IA

El caso de Grok encaja en una tendencia más amplia: contenido no confiable manipula asistentes que tienen acceso a datos sensibles o a herramientas con permisos relevantes.

• EchoLeak en Microsoft 365 Copilot: este caso documentó una vulnerabilidad de inyección indirecta de instrucciones y de interacción cero que permitía extraer datos de forma remota y sin autenticación mediante un correo electrónico preparado. Está identificado como CVE-2025-32711.
• CoSnitch en Microsoft Copilot Personal: investigadores de Varonis informaron que la manipulación repetida del razonamiento de Copilot podía hacer que enviara datos sensibles a un servidor externo y corrompiera su memoria persistente.
• Ataques contra agentes de programación: la investigación TrustFall de Adversa describió cómo la configuración maliciosa de un repositorio podía hacer que un servidor MCP controlado por un atacante ejecutara comandos a través de asistentes como Claude Code, Gemini CLI, Cursor CLI y GitHub Copilot CLI.

El hilo común es que el atacante no tiene por qué vulnerar directamente el modelo subyacente ni el sistema operativo. Puede suministrar contenido que el agente está diseñado para leer y aprovechar los permisos del propio agente para recuperar información, invocar herramientas, modificar estados o realizar una solicitud de red.

Qué defensas sugiere este caso

El ataque descrito muestra que los filtros contra la inyección de instrucciones no bastan por sí solos. Entre las medidas relevantes están:

• Separar la procedencia del contenido: mantener diferenciados, tanto visual como técnicamente, el contenido de una página, los resultados de herramientas, las instrucciones del sistema y el estado confiable de la aplicación.
• Restringir la ejecución de código: impedir que el contenido recuperado active descifrados arbitrarios u otras operaciones sin una política estricta y un entorno aislado.
• Aplicar el principio de mínimo privilegio: limitar el contexto privado al que puede acceder el agente y evitar que una tarea rutinaria de resumen exponga datos de sesiones no relacionados.
• Exigir aprobación para acciones sensibles: las solicitudes de red que incluyan datos del usuario o de una conversación deberían requerir una confirmación explícita y comprensible.
• Controlar el tráfico saliente: las listas de dominios permitidos, la inspección mediante un proxy y los controles de salida pueden impedir que el agente envíe contexto a URL arbitrarias.
• Supervisar las cadenas de herramientas: conviene registrar y alertar sobre secuencias inusuales, como recuperar una página, ejecutar código, extraer contexto y navegar después a un dominio externo.

La lección central es clara: un agente de IA no debe considerar confiable un contenido solo porque fue producido por una herramienta. En el caso de Grok descrito por Adversa, la página web se convirtió en un flujo de descifrado y ejecución que aprovechó los propios permisos del agente para sacar información privada de la sesión.

Qué vulnerabilidad se comunicó

El problema no consiste en que el cifrado AES-256-GCM esté roto. La técnica explota la frontera entre los filtros de seguridad de Grok, su entorno de ejecución de código y sus herramientas de navegación.

La página maliciosa incluye un bloque de instrucciones cifradas junto con el material necesario para descifrarlo. Durante la primera revisión, las defensas contra la inyección de instrucciones ven texto cifrado, no la orden en claro. Después, el agente es inducido a ejecutar una rutina de descifrado en su entorno de Python o de ejecución de código. Una vez recuperado, el comando vuelve al modelo como resultado de una herramienta, un tipo de contenido que el agente puede tratar de forma distinta a una instrucción no confiable incrustada directamente en una página web.

Adversa informó que probó la técnica contra Grok 4.5 Fast en grok.com. Una descripción independiente de esas pruebas indicó que el ataque tuvo éxito en el 40 % de 20 intentos realizados entre junio y agosto de 2026. Esa cifra corresponde al entorno de pruebas de los investigadores; no significa que todas las sesiones de Grok ni todos los intentos fueran vulnerables.

Así funciona el ataque de la página cifrada

La cadena de ataque descrita por los investigadores tiene varias etapas:

1. La página transporta la carga oculta. El atacante coloca en un sitio web que parece contenido normal un texto cifrado, instrucciones para descifrarlo y material criptográfico. La construcción descrita utiliza claves derivadas mediante PBKDF2 y cifrado AES-256-GCM.

2. El análisis inicial no detecta la orden. Los filtros de Grok pueden inspeccionar el contenido visible, pero la instrucción peligrosa está escondida dentro de datos cifrados. El cifrado impide que el modelo interprete directamente el comando durante esa primera pasada.

3. El agente ejecuta el descifrado. Cuando el usuario le pide a Grok que resuma o analice la página, el agente sigue las indicaciones del sitio y ejecuta el proceso de descifrado en su entorno de código.

4. La instrucción vuelve al contexto del agente. El texto descifrado aparece como el resultado de una operación de herramienta. Esto crea un problema de procedencia: el contenido controlado por el atacante ha pasado de una página no confiable a un contexto que el agente puede interpretar como un resultado operativo.

5. Grok consulta datos de la sesión. En la prueba de concepto, las instrucciones descifradas le indicaban recuperar valores como el nombre del usuario, su ubicación aproximada, el nivel de suscripción y los mensajes o el contexto de la conversación disponible para el agente.

6. Una petición web saca los datos del entorno. Grok abría después una URL controlada por el atacante e incluía la información recopilada en sus parámetros de consulta. Según la demostración divulgada, la transferencia se completaba sin una confirmación adicional ni una advertencia visible.

Un límite importante sobre la «historia completa»

La evidencia disponible respalda el acceso a los mensajes y al contexto que el agente tenía disponibles en la sesión activa. Por eso, las referencias a una «historia completa del chat» no deben interpretarse automáticamente como acceso a todas las conversaciones almacenadas en la cuenta del usuario.

Cuándo se informó a xAI y cuál era el estado del parche

Adversa afirmó que comunicó el problema a xAI a través de HackerOne el 3 de junio de 2026. Posteriormente envió seguimientos para coordinar la divulgación el 4 y el 10 de agosto.

Al 19 de agosto de 2026, la empresa de seguridad dijo que no había recibido una respuesta sustantiva y que todavía podía reproducir el ataque contra Grok. La información publicada en ese momento describía el problema como carente de un parche desplegado, un identificador CVE público y una solución disponible para los usuarios.

Ese estado procede del informe de los investigadores y de las publicaciones que lo cubrieron, no de un aviso de seguridad público de xAI. Las fuentes disponibles tampoco demuestran que el método hubiera sido utilizado contra usuarios reales fuera de las demostraciones de investigación.

Por qué el cifrado puede dejar ciegas a las defensas

Muchas defensas tradicionales contra la inyección de instrucciones buscan lenguaje sospechoso en el contenido que recupera un sistema de IA. Cryptographic Context Injection desplaza la orden peligrosa a una fase posterior del procesamiento.

El modelo no necesita comprender el comando malicioso cuando escanea la página por primera vez. Solo tiene que seguir una indicación aparentemente útil —por ejemplo, ejecutar una rutina de descifrado— dentro de un entorno que considera confiable. La orden se vuelve legible después de esa ejecución, cuando el agente puede tener acceso al contexto privado y permisos para navegar o realizar solicitudes de red.

Por eso, la vulnerabilidad se entiende mejor como un problema de arquitectura del agente que como un simple fallo de filtrado por palabras clave. Cuando un agente puede leer contenido externo, ejecutar código, acceder a datos de sesión y utilizar herramientas de red, una instrucción maliciosa puede convertir esas capacidades en una ruta de extracción de información.

El problema más amplio de la seguridad de los agentes de IA

El caso de Grok encaja en una tendencia más amplia: contenido no confiable manipula asistentes que tienen acceso a datos sensibles o a herramientas con permisos relevantes.

• EchoLeak en Microsoft 365 Copilot: este caso documentó una vulnerabilidad de inyección indirecta de instrucciones y de interacción cero que permitía extraer datos de forma remota y sin autenticación mediante un correo electrónico preparado. Está identificado como CVE-2025-32711.
• CoSnitch en Microsoft Copilot Personal: investigadores de Varonis informaron que la manipulación repetida del razonamiento de Copilot podía hacer que enviara datos sensibles a un servidor externo y corrompiera su memoria persistente.
• Ataques contra agentes de programación: la investigación TrustFall de Adversa describió cómo la configuración maliciosa de un repositorio podía hacer que un servidor MCP controlado por un atacante ejecutara comandos a través de asistentes como Claude Code, Gemini CLI, Cursor CLI y GitHub Copilot CLI.

El hilo común es que el atacante no tiene por qué vulnerar directamente el modelo subyacente ni el sistema operativo. Puede suministrar contenido que el agente está diseñado para leer y aprovechar los permisos del propio agente para recuperar información, invocar herramientas, modificar estados o realizar una solicitud de red.

Qué defensas sugiere este caso

El ataque descrito muestra que los filtros contra la inyección de instrucciones no bastan por sí solos. Entre las medidas relevantes están:

• Separar la procedencia del contenido: mantener diferenciados, tanto visual como técnicamente, el contenido de una página, los resultados de herramientas, las instrucciones del sistema y el estado confiable de la aplicación.
• Restringir la ejecución de código: impedir que el contenido recuperado active descifrados arbitrarios u otras operaciones sin una política estricta y un entorno aislado.
• Aplicar el principio de mínimo privilegio: limitar el contexto privado al que puede acceder el agente y evitar que una tarea rutinaria de resumen exponga datos de sesiones no relacionados.
• Exigir aprobación para acciones sensibles: las solicitudes de red que incluyan datos del usuario o de una conversación deberían requerir una confirmación explícita y comprensible.
• Controlar el tráfico saliente: las listas de dominios permitidos, la inspección mediante un proxy y los controles de salida pueden impedir que el agente envíe contexto a URL arbitrarias.
• Supervisar las cadenas de herramientas: conviene registrar y alertar sobre secuencias inusuales, como recuperar una página, ejecutar código, extraer contexto y navegar después a un dominio externo.

La lección central es clara: un agente de IA no debe considerar confiable un contenido solo porque fue producido por una herramienta. En el caso de Grok descrito por Adversa, la página web se convirtió en un flujo de descifrado y ejecución que aprovechó los propios permisos del agente para sacar información privada de la sesión.