sistema: OPERATIVO
← volver a todos los hacks
INDIRECT INJECTION MEDIUM NEW

SalesBleed: exfiltración de datos CRM sin clics desde Salesforce Agentforce

El 24 de septiembre de 2026, Zenity Labs divulgó tres fallos de redacción de URL que permitían filtrar datos CRM por DNS mediante una inyección vía Web-to-Lead. Corregidos el 18 de agosto.

2026-10-01 // 6 min affects: salesforce-agentforce

¿Qué es?

El 24 de septiembre de 2026, Zenity Labs publicó SalesBleed, un conjunto de tres fallos en la forma en que Salesforce Agentforce filtraba las URL en las respuestas del agente. Combinados con una inyección de prompt indirecta colocada a través de un formulario público Web-to-Lead, permitían exfiltrar datos del CRM sin ningún clic: bastaba con que la víctima hiciera una consulta rutinaria al agente. Infosecurity Magazine y Salesforce Ben lo cubrieron el 25 de septiembre.

Según la cronología de Zenity, el problema se notificó a Salesforce el 1 de junio de 2026, se trató con su equipo de seguridad el 16 de junio, se confirmó corregido el 18 de agosto y se divulgó el 24 de septiembre. Las fuentes consultadas no citan ningún identificador CVE.

Cómo funciona

El mecanismo «Trusted URLs» de Agentforce oculta los enlaces a destinos no confiables en la salida del agente. Zenity encontró tres discrepancias entre lo que el filtro considera una URL y lo que el navegador interpreta realmente:

  • El filtro solo reconocía un conjunto fijo de dominios de nivel superior, por lo que los nombres de host bajo TLD no reconocidos no se marcaban.
  • El filtro y la superficie de renderizado discrepaban sobre dónde termina una URL: ciertos corchetes y llaves no se ocultaban pero seguían funcionando al renderizar.
  • Las URL malformadas que incumplían la RFC 3986 pasaban el filtro y aun así los navegadores las cargaban como fuentes de imagen.

La cadena de ataque, a nivel conceptual: un tercero envía un lead cuyo campo de texto libre contiene instrucciones. Más tarde, un empleado consulta al agente sobre los leads y este lee ese registro en su contexto. El texto inyectado dirige al agente a consultar cuentas mediante su herramienta Query Records, incrustar el resultado en un nombre de host y emitirlo como referencia de imagen. Cuando el navegador intenta cargar la imagen, la resolución DNS lleva los datos a un servidor controlado por el atacante. La prueba de concepto de Zenity extrajo nombres de empresas e importes de operaciones, y señala que la inyección «podría haber pedido cualquier cosa a la que llegue la herramienta Query Records del subagente». Este artículo omite deliberadamente cargas útiles y formas exactas de URL.

Por qué importa

El patrón va más allá de un proveedor. Cualquier agente que (1) ingiera registros creados por terceros no autenticados, (2) disponga de una herramienta de lectura de datos y (3) renderice enlaces o imágenes tiene la misma estructura. La redacción de salida es un analizador, y un analizador que discrepa del renderizador genera evasiones. Como el canal de exfiltración es una consulta DNS provocada por el renderizado, no requiere clics y deja poco rastro en los registros de la aplicación.

Defensas

  • Acotar las herramientas a la tarea. Un agente que clasifica leads entrantes no debería tener acceso amplio a la tabla de cuentas; aplique mínimo privilegio por agente y subagente.
  • Tratar las entradas no autenticadas como no confiables. Los campos de captación públicos (Web-to-Lead, etc.) deben marcarse, sanearse o mantenerse fuera del contexto del agente cuando sea posible.
  • No depender solo de la redacción. Prefiera listas de permitidos de destinos exactos frente a listas de bloqueo de patrones, y desactive el renderizado automático de imágenes o enlaces cuando no sea necesario.
  • Un único analizador de URL. El filtro y el renderizador deben compartir la misma lógica de análisis y normalización.
  • Vigilar el tráfico de salida. Alerte ante patrones DNS inusuales, como subdominios largos o de alta entropía desde clientes de usuario.
  • Confirmar el estado del parche. Salesforce indica que el problema está corregido en el servidor; aun así, los administradores deben revisar a qué fuentes de datos acceden sus agentes.

Estado

ElementoDetalle
ProductoSalesforce Agentforce
DescubridorZenity Labs
Notificación1 de junio de 2026
Corrección confirmada18 de agosto de 2026
Divulgación pública24 de septiembre de 2026
Estado del parcheCorregido por el proveedor (Trusted URLs reforzado)
CVENinguno citado en las fuentes

Sources