Salesbleed expuso un fallo del límite de confianza en Salesforce Agentforce que permitió que registros Web-to-Lead envenenados orientaran a los agentes hacia la exfiltración de datos del CRM y el phishing en Slack dirigido a empleados. Zenity reveló las debilidades el 24 de septiembre de 2026, después de que Salesforce completara las correcciones. Salesforce afirmó el 25 de septiembre de 2026 que no había encontrado pruebas de explotación de clientes.
¿Qué es Salesbleed?
Salesbleed es un conjunto de debilidades de Salesforce Agentforce que permitían que instrucciones controladas por un atacante, almacenadas en envíos públicos de leads, influyeran en acciones conectadas de CRM y Slack. Según la investigación de Zenity del 24 de septiembre de 2026, los resultados demostrados incluyeron exfiltración de datos sin clics mediante solicitudes DNS y mensajes de phishing enviados bajo la identidad de confianza de un agente en Slack.
La inyección indirecta de instrucciones es una técnica de ataque que coloca instrucciones maliciosas dentro de datos que un AI agente lee posteriormente como contenido ordinario. En este caso, el atacante no necesitó iniciar sesión en Salesforce. Salesforce Web-to-Lead proporcionó el punto de entrada no autenticado, y el texto manipulado permaneció en la tabla Leads hasta que el trabajo rutinario lo puso delante de Agentforce.
El hallazgo es importante porque el agente transformó una entrada no fiable del sitio web en una acción dentro de sistemas empresariales autenticados. El texto del atacante pasó de un formulario público a registros de Salesforce, llegó a herramientas con un acceso más amplio a los datos y podía acabar convirtiéndose en un mensaje interno de Slack. Eso es blanqueo de confianza, no una toma de control de cuenta convencional.
Salesforce dijo a SecurityWeek el 25 de septiembre de 2026 que no tenía pruebas de que las rutas de ataque hubieran sido explotadas contra clientes. Dark Reading informó en la misma fecha de que no se habían publicado identificadores CVE, totales de clientes afectados, recuentos de credenciales robadas ni cifras de pérdidas financieras.
¿Cómo funcionaba la cadena de ataque de Salesbleed?
La cadena de Salesbleed comenzó cuando un atacante envió instrucciones maliciosas a través de Salesforce Web-to-Lead. Durante una revisión posterior del lead, Agentforce interpretó el texto almacenado y podía invocar capacidades conectadas de CRM o Slack. La prueba de concepto de Zenity del 24 de septiembre de 2026 no requirió ningún clic del empleado para iniciar ninguna de las dos rutas de exfiltración de datos demostradas.
La secuencia expuso cuatro decisiones de confianza independientes. Cada una parecía razonable de forma aislada, pero su combinación permitió que contenido externo influyera en acciones autenticadas:
- Un atacante colocó instrucciones en un envío Web-to-Lead no autenticado.
- Salesforce almacenó el envío como un lead normal sin caducidad automática después de una interacción de un agente.
- El subagente predeterminado General CRM leyó el lead y podía consultar tanto Leads como Accounts a través de su herramienta Query Records.
- Agentforce generó una solicitud de imagen externa o invocó una acción conectada de Slack, produciendo una solicitud saliente o un mensaje dirigido a empleados.
No fue necesaria ninguna escalada de privilegios en la demostración de Zenity de 2026. El subagente General CRM ya tenía el acceso necesario para pasar del contenido del lead proporcionado por el atacante a la información de la cuenta. Esa distinción debería orientar la respuesta: corregir un analizador ayuda, pero reducir los permisos legítimos de un agente limita a qué puede llegar una futura inyección.
La persistencia es un riesgo fácil de pasar por alto. Un lead malicioso seguía siendo un registro normal del CRM y podía influir repetidamente en interacciones posteriores; no se consumía ni se invalidaba tras una revisión. Los equipos de seguridad que ya hacen seguimiento de riesgos empresariales de los agentes de IA autónomos deberían, por tanto, tratar los registros externos almacenados como entradas de ataque duraderas, no como prompts de un solo uso.
¿Cómo podía Salesbleed extraer datos del CRM de Salesforce?
Salesbleed podía codificar nombres de empresas de Salesforce y tamaños de operaciones en nombres de host DNS controlados por un atacante, según la prueba de concepto de Zenity del 24 de septiembre de 2026. La renderización automática de una imagen HTML externa y el despliegue automático de URL de Slack generaban búsquedas DNS, lo que permitía que la información saliera del entorno sin que un empleado hiciera clic en el enlace generado.
Zenity informó en 2026 de que el control Trusted URLs de Salesforce podía eludirse porque el redactor y el renderizador posterior discrepaban sobre el reconocimiento del dominio de nivel superior y la terminación de la URL. La prueba de concepto utilizó un .fun dominio que el redactor no reconoció. Salesforce confirmó la finalización de las correcciones el 18 de agosto de 2026, y Zenity verificó la reparación de Trusted URLs el 19 de agosto de 2026.
| Ruta de salida | Comportamiento automático | Se requiere clic del empleado | Resultado observable |
|---|---|---|---|
| Imagen HTML externa | El renderizador recuperó la URL de la imagen generada | No | Búsqueda DNS a un nombre de host controlado por un atacante |
| Despliegue de vista previa de URL en Slack | Slack procesó la vista previa de la URL generada | No | Búsqueda DNS a un nombre de host controlado por un atacante |
| Respuesta en hilo de Slack | Agentforce publicó mediante una acción conectada | No antes de la corrección | Mensaje dirigido al empleado desde la identidad del agente |
El ancho de banda era reducido por solicitud, pero no irrelevante con el tiempo. Zenity señaló en 2026 que una etiqueta DNS puede contener hasta 63 caracteres y un nombre de dominio completo hasta 253 caracteres. Con una carga útil simplificada de 63 caracteres por búsqueda, 100 búsquedas correctas podrían transportar 6.300 caracteres codificados antes de tener en cuenta la sobrecarga de la codificación y los componentes del dominio.
Ese cálculo explica por qué la filtración DNS de bajo ancho de banda sigue mereciendo atención. Los registros envenenados persistentes pueden generar consultas repetidas, mientras que los registros DNS ordinarios pueden recibir menos escrutinio que las exportaciones de API. Los programas de detección deben conectar los prompts del agente, las llamadas a herramientas, la actividad DNS y la procedencia de los registros, en lugar de examinar cada flujo por separado.
¿Cómo se convirtió Agentforce en una herramienta de phishing en Slack?
Salesbleed abusó de la acción Reply to a Slack Thread del subagente estándar Slack Knowledge para convertir instrucciones inyectadas en mensajes internos. Antes de la corrección en 2026, la acción podía enviar sin confirmación del usuario ni atribución visible al usuario que la invocaba, haciendo que el contenido dirigido por el atacante pareciera proceder de una identidad de Agentforce de confianza dentro de Slack.
Zenity informó el 24 de septiembre de 2026 de que los administradores podían añadir el subagente Slack Knowledge y las acciones asociadas a un agente de Agentforce con dos clics. Los investigadores también descubrieron que Markdown podía ocultar un destino de phishing tras un texto de enlace aparentemente inocuo. Un canal de entrega interno otorgó credibilidad al señuelo resultante, algo que un mensaje externo no solicitado correo electrónico no habría conseguido.
La guía de soporte de Salesforce del 3 de julio de 2026 indica que las acciones de Slack de Agentforce se ejecutan en el contexto de seguridad del usuario autenticado que las invoca, con una sesión independiente por usuario para cada invocación. Sin embargo, el contexto de identidad por sí solo no resolvía el problema de presentación: los destinatarios necesitaban ver quién había provocado que el agente publicara y los usuarios necesitaban la oportunidad de aprobar el contenido saliente.
Salesforce cambió ambos aspectos. Zenity verificó el 20 de agosto de 2026 que las respuestas en hilos atribuían los mensajes al usuario que las invocaba y, el 21 de septiembre de 2026, confirmó la confirmación por defecto para Reply to a Slack Thread. Zenity dijo que el ajuste de confirmación todavía podía desactivarse con un clic de configuración después de la corrección, por lo que los administradores deben comprobar la configuración efectiva en lugar de asumir que los valores predeterminados más seguros siguen activados.
Sinceramente, un agente de entorno laboral con capacidad de escritura no debería publicar contenido sensible para la seguridad sin aprobación simplemente porque la función lo permita. El incidente también ilustra por qué entender cómo los agentes de IA seleccionan e invocan herramientas importa más allá de la programación: la elección de herramientas se convierte en una decisión de seguridad cuando el destino es un canal de comunicaciones de confianza.
¿Se corrigió Salesbleed y siguen corriendo riesgo los clientes?
Salesforce corrigió las rutas de ataque de Salesbleed notificadas antes de la divulgación pública de Zenity el 24 de septiembre de 2026. Zenity confirmó todas las correcciones notificadas antes del 21 de septiembre de 2026, incluida la reparación de Trusted URLs, la atribución de usuario para las respuestas en hilos de Slack y la confirmación por defecto. Las configuraciones incorrectas y futuras variantes de prompt injection siguen requiriendo controles defensivos.
La cronología de la corrección es inusualmente útil. Salesforce confirmó que las correcciones de exfiltración de datos estaban completas el 18 de agosto de 2026. Zenity verificó la corrección de la omisión de URL el 19 de agosto y la atribución de mensajes el 20 de agosto; Salesforce dijo el 25 de agosto que el trabajo sobre la confirmación por defecto continuaba, antes de que Zenity completara las pruebas finales el 21 de septiembre.
A fecha de 24 de septiembre de 2026, Zenity describió las cadenas divulgadas como cerradas por defecto. Después, el 25 de septiembre, Salesforce dijo que estaba contactando con los clientes para revisar las configuraciones de Agentforce. No hubo pruebas públicas de explotación de clientes, pero la ausencia de explotación notificada no demuestra que los registros históricos no contengan actividad sospechosa.
El contraargumento más sólido es sencillo: se trataba de hallazgos de investigación ya corregidos, no de una brecha masiva documentada. Aun así, descartar Salesbleed como un bug de analizador ya cerrado haría perder de vista la lección arquitectónica. Las organizaciones que utilizan permisos amplios para agentes, ingesta de datos públicos y acciones salientes no aprobadas pueden recrear la misma clase de fallo a través de otro modelo o integración.
¿Cómo deberían los administradores defender los flujos de trabajo de Agentforce?
Los administradores deberían marcar como no fiables los registros de Salesforce procedentes de fuentes externas, limitar el alcance de herramientas y datos de cada subagente de Agentforce, mantener la aprobación para los mensajes salientes y registrar la cadena completa desde el desencadenante hasta la acción. Las recomendaciones de Zenity de 2026 hicieron hincapié específicamente en supervisar las acciones de escritura de los agentes y en mantener activados los requisitos de confirmación, en lugar de depender únicamente de los valores predeterminados corregidos de Salesforce.
Empieza por la procedencia. Los formularios web, las hojas de cálculo importadas, los tickets de soporte, correos electrónicos, y los feeds de socios deberían incluir etiquetas de origen legibles por máquinas que se conserven durante la ingesta y la recuperación. Un agente no debería tratar el texto de un formulario público como una instrucción simplemente porque Salesforce lo haya almacenado en una tabla de confianza.
A continuación, separe la lectura de la acción. Un agente de clasificación de leads normalmente necesita campos seleccionados del lead; puede que no necesite consultas de cuenta sin restricciones ni permiso para publicar en Slack. En la base de referencia que prefiero, cualquier acción que envíe un mensaje, modifique un registro o contacte con un host externo recibe aprobación explícita y registra al usuario que la invoca.
Los registros de auditoría deben unir el registro original, el texto recuperado, la decisión del modelo, los argumentos de la herramienta, el destino de red, el evento de aprobación y la acción final. Los registros convencionales de SaaS a menudo solo capturan fragmentos. Los equipos que evalúan plataformas de descubrimiento y supervisión de IA en la sombra deberían comprobar si los productos conservan esa cadena causal en lugar de limitarse a inventariar aplicaciones.
La revisión retrospectiva también tiene valor. Busque en los registros de Agentforce de 2026 dominios externos inusuales, renderizado de imágenes a partir de respuestas generadas, solicitudes de despliegue de enlaces de Slack, acceso repetido al mismo lead y consultas de cuenta que siguieron a la ingesta de Web-to-Lead. El riesgo que pocos comprueban es la recurrencia: un registro envenenado puede seguir siendo peligroso después de que se cierre la primera alerta.
Preguntas frecuentes sobre Salesbleed
¿Salesbleed requirió credenciales de Salesforce robadas?
Salesbleed no requirió credenciales robadas en la prueba de concepto de Zenity de 2026. El atacante introdujo instrucciones maliciosas a través de la función Salesforce Web-to-Lead no autenticada, mientras que las acciones posteriores de Agentforce se ejecutaron mediante acceso conectado legítimo.
¿Se asignó un CVE a Salesbleed?
Salesbleed no tenía ningún identificador CVE notificado a fecha de 25 de septiembre de 2026, según Dark Reading. Los informes públicos tampoco proporcionaron ningún recuento de clientes afectados ni un total de pérdidas financieras.
¿Perdieron datos los clientes de Salesforce?
Salesforce dijo el 25 de septiembre de 2026 que no tenía pruebas de que Salesbleed se hubiera explotado contra clientes. Zenity demostró una exfiltración técnicamente viable en su investigación, pero una prueba de concepto no es prueba de una brecha de seguridad de un cliente.
¿Puede desactivar Web-to-Lead evitar el ataque?
Deshabilitar Salesforce Web-to-Lead elimina el punto de entrada utilizado en la demostración de 2026 de Zenity, pero no aborda el problema más amplio de la inyección indirecta de prompts. Otros registros externos pueden contener instrucciones maliciosas a menos que los flujos de trabajo de Agentforce apliquen procedencia, permisos limitados, aprobaciones y registro de extremo a extremo.