Inyección por objetos de mensajería: la brecha de serialización en los asistentes de IA

¿Qué es esto?

El 10 de junio de 2026, Imperva Threat Research (Yohann Sillam) publicó un análisis de un vector de inyección de prompts que no reside en un documento ni en una página web, sino en los objetos de mensajería estructurados que un asistente de IA personal maneja a diario: contactos compartidos, vCards (.vcf) y pines de geolocalización. El trabajo se centró en OpenClaw, un agente autoalojado muy difundido que conecta un LLM con sistemas de archivos, shells y plataformas de mensajería como WhatsApp o Telegram. The Hacker News lo difundió al día siguiente, junto a hallazgos paralelos de Varonis.

La instrucción inyectada era invisible para la víctima, cruzaba la frontera de confianza hasta el contexto de usuario autenticado y —en el laboratorio de Imperva, frente a Gemini 3.1 Pro (versión preliminar)— logró que el agente descargara y ejecutara un script desde un servidor controlado por los investigadores. Imperva realizó una divulgación responsable; OpenClaw publicó una corrección en la versión 2026.4.23.

Cómo funciona

El fallo está en la fontanería, no en el modelo. Cuando OpenClaw pasa contenido web al LLM, lo envuelve en un marcador de contenido no confiable. Cuando pasa un objeto de mensajería —un contacto, una vCard, una etiqueta de ubicación— lo aplana directamente en el texto del prompt, sin ninguna frontera que lo señale como no confiable.

Solo algunos campos llegan al modelo, y eso es lo que la técnica aprovecha. Un contacto compartido envía únicamente su campo nombre, serializado con una forma del tipo <contact: nombre, número>. Los corchetes angulares son caracteres perfectamente legales dentro de un nombre, de modo que el modelo no tiene forma fiable de saber dónde termina el nombre real y dónde empieza el texto inyectado. En pantalla, el nombre del contacto aparece truncado: la víctima tampoco ve la carga útil al final de la cadena. La misma lógica se aplica al campo de nombre completo (FN) de una vCard, soportado de forma nativa por WhatsApp, y a la etiqueta de un pin de ubicación compartido.

Resulta revelador que Imperva informe de que una simple imagen con instrucciones ocultas fracasó — ese ataque se ha publicitado tanto que los modelos ya están entrenados para resistirlo. La vía de los objetos de mensajería funcionó precisamente porque los modelos han visto muchos menos ejemplos de ella. Aquí no se reproduce ninguna carga útil; el punto estructural es suficiente.

El problema de fondo: no existe ningún estándar sobre cómo se serializan los objetos de mensajería antes de llegar a un LLM. La integración de herramientas dispone de MCP; las recuperaciones web tienen sus marcadores de contenido no confiable; los objetos de mensajería ricos no tienen ninguno. Cada asistente los aplana a su manera, de forma ad hoc, e Imperva observó el mismo patrón de aplanamiento en otros asistentes personales — por lo que no es exclusivo de OpenClaw.

Por qué importa

Los asistentes de IA personales no son chatbots: son ejecutores autenticados con acceso a archivos, shells y cuentas conectadas. Una inyección que alcanza a uno hereda ese acceso. Dos propiedades hacen que el vector de los objetos de mensajería sea peor que una inyección indirecta clásica. Primero, la invisibilidad en ambos extremos — ni el modelo ni el humano perciben la carga como anómala. Segundo, viralidad y persistencia: un único contenido compartido (una tarjeta de contacto reenviada miles de veces), combinado con la memoria activada por defecto del agente, puede sembrar discretamente un compromiso en cada asistente que lo ingiera, allí donde la ejecución no está aislada.

Es la tríada letal en forma concreta — acceso a datos privados, exposición a contenido no confiable y un canal de salida — entregada a través de una costura de serialización que la mayoría de los defensores nunca modeló. Pertenece a la misma familia que la inyección indirecta observada en el mundo real, pero por un canal que las reglas de saneamiento pensadas para documentos y URL sencillamente no cubren.

Defensas

• Marque como no confiable todo campo no confiable. La corrección de OpenClaw sirve de plantilla: sacar los nombres de contacto, los campos de vCard y las etiquetas de ubicación del cuerpo inline del prompt hacia un canal estructurado de metadatos no confiables, para que el modelo los reciba etiquetados y no fundidos en las instrucciones. Aplíquelo a todos los campos de objetos de mensajería, no solo a los de un aviso concreto.
• Inventaríe cada costura de serialización. Audite cada ruta por la que un objeto estructurado (contacto, invitación de calendario, vCard, ubicación, enlace enriquecido) se aplana en el prompt. Cada una es un canal de inyección hasta que se demuestre lo contrario.
• Mantenga la ejecución aislada y con mínimo privilegio. La ejecución de código debe estar desactivada o en sandbox por defecto; limite las habilidades y conectores a lo mínimo que la tarea necesite. El radio de acción de la inyección es exactamente la autoridad permanente del agente.
• Controle las acciones salientes y de alto riesgo. Exija aprobación humana para cualquier primer envío a un destino desconocido y para acciones que afecten a credenciales o pagos, de modo que un agente secuestrado no pueda completar por sí solo una etapa de exfiltración.
• Trate la memoria como superficie de ataque. Con la persistencia activada por defecto, un único objeto envenenado puede dejar instrucciones duraderas. Limite lo que el contenido no confiable puede escribir en la memoria a largo plazo.

Estado

Elemento	Detalle
Divulgado	2026-06-10 (Imperva Threat Research)
Vector	Inyección vía campos de objetos de mensajería (nombre de contacto, FN de vCard, etiqueta de ubicación) aplanados inline
Probado contra	OpenClaw + Gemini 3.1 Pro (versión preliminar)
Corrección	OpenClaw 2026.4.23 — campos no confiables movidos a un canal de metadatos estructurado
Alcance	Imperva observó el mismo patrón de aplanamiento en otros asistentes personales

La corrección cierra la instancia de OpenClaw. La clase — objetos de mensajería ricos serializados en los prompts sin frontera de no confianza — permanece abierta hasta que los asistentes adopten una forma coherente de transportar campos estructurados y no confiables hasta el modelo. Hasta entonces, cada nuevo tipo de objeto que un asistente aprende a ingerir es un nuevo canal de inyección que auditar.