SalesBleed permitió extraer datos de Agentforce sin clics y suplantar agentes en Slack
SalesBleed permitió extraer datos de Agentforce sin clics y suplantar agentes en Slack
Tres fallas ya corregidas en Salesforce Agentforce permitían convertir un registro Web-to-Lead malicioso en extracción de datos CRM sin clics y mensajes de phishing emitidos por un agente confiable dentro de Slack.
Una entrada pública podía secuestrar al agente
Zenity Labs divulgó SalesBleed, un conjunto de tres fallas en Salesforce Agentforce. La cadena comenzaba con instrucciones maliciosas insertadas en un formulario público Web-to-Lead; el contenido quedaba almacenado como un registro aparentemente normal hasta que un empleado pedía al agente revisar los prospectos.
Al procesar el registro contaminado, el agente podía obedecer la inyección indirecta, consultar otros objetos CRM disponibles bajo sus permisos y devolver una respuesta que aparentaba ser legítima. El atacante no necesitaba una cuenta en el tenant ni interacción directa con la víctima.
Extracción sin clics pese a Trusted URLs
Dos de las fallas permitían sacar información mediante solicitudes de imágenes y la generación automática de vistas previas de enlaces en Slack. Debilidades en el reconocimiento de dominios y en el análisis de caracteres permitían evadir Trusted URLs, el control diseñado para impedir que Agentforce enviara datos a destinos no aprobados.
La información consultada podía codificarse dentro de una URL controlada por el atacante. El navegador o Slack iniciaban la solicitud al renderizar la respuesta, por lo que los datos podían salir aunque la interfaz indicara que el contenido había sido bloqueado y sin que el empleado pulsara un enlace.
La identidad confiable del agente como señuelo
La tercera falla afectaba la integración con Slack. Agentforce podía publicar en distintos canales sin identificar de forma fiable al usuario que había iniciado la acción. Una persona interna podía ocultar su autoría, y una inyección indirecta externa podía inducir al agente a distribuir enlaces de phishing bajo su identidad corporativa.
El impacto no era solo reputacional: un mensaje procedente de un agente ya autorizado dentro del espacio de trabajo tenía más posibilidades de obtener credenciales y abrir acceso posterior a correo, repositorios de código y otras aplicaciones empresariales.
Corrección y controles recomendados
Zenity notificó los hallazgos el 1 de junio de 2026. Salesforce corrigió los bypasses de Trusted URLs y el problema de atribución; la empresa confirmó que las tres fallas estaban resueltas el 19 de agosto. No se ha informado explotación maliciosa en entornos reales.
- Confirmar con Salesforce que el tenant dispone de las mitigaciones y revisar cambios recientes en Trusted URLs y acciones de Slack.
- Reducir los objetos, campos y herramientas accesibles para cada agente según el principio de mínimo privilegio.
- Tratar entradas Web-to-Lead y otros datos externos como contenido hostil antes de que ingresen en el contexto del modelo.
- Aplicar controles de salida y DLP independientes de la respuesta del modelo, con listas de destinos explícitas y registro de solicitudes DNS y HTTP.
- Exigir confirmación y atribución humana para mensajes en canales, y alertar sobre publicaciones automatizadas que incluyan enlaces o soliciten credenciales.
Fuentes y referencias
Esta publicación es una síntesis original. Consulte las fuentes primarias para información técnica completa y actualizaciones.
- 1SecurityWeek ↗prensa especializada
- 2The Register ↗prensa especializada
- 3
- 4
¿Esta amenaza puede afectar a su empresa?
ENERIT puede ayudarle a evaluar exposición, priorizar remediaciones y fortalecer su operación de ciberseguridad.
Hablar con un especialista