SalesBleed: un lead público, tres fallos de Agentforce, cero clics

El 24 de septiembre de 2026, Zenity Labs publicó una investigación que llama SalesBleed: tres vulnerabilidades en Salesforce Agentforce, la plataforma del proveedor de CRM para crear y desplegar agentes de IA, que permiten a un desconocido extraer registros de clientes de la organización de Salesforce de una empresa y luego usar el propio agente de esa empresa para hacer phishing a su personal. Dos de las tres no requieren ningún clic de nadie dentro de la empresa. La exposición se aplica a los inquilinos de Agentforce que aceptan envíos de Web-to-Lead, y a cualquier agente que un inquilino haya publicado en Slack. Dark Reading informa de que no se asignaron identificadores CVE, y Salesforce dijo al medio que no tiene pruebas de explotación contra ningún cliente. El registro completo, con la calificación de confianza y el estado de daño propios del archivo, se encuentra en el Orca AI Incident Archive, que registra cada incidente documentado de agentes junto con sus fuentes citadas.

Cómo un formulario público de captación de clientes potenciales se convierte en un canal de datos

Web-to-Lead es el mecanismo oficial de Salesforce para recopilar leads, y no requiere autenticación por diseño — existe para que cualquier persona en internet pueda enviar un formulario y hacer que su contenido llegue al CRM del cliente. La primera publicación de Zenity, atribuida a Alex Apostolov y sus colegas, comienza con eso como la única condición de entrada: ninguna cuenta que suspender, ninguna sesión que revocar, ningún evento de inicio de sesión que detectar. El atacante nunca toca el tenant.

La cadena que describen los investigadores se desarrolla en cinco movimientos:

• El atacante envía un lead a través de un endpoint público Web-to-Lead, con una inyección de prompt oculta en uno de sus campos. Parece una consulta normal.

• El cliente potencial permanece ahí hasta que un empleado le pregunta algo completamente común y corriente a su agente — el ejemplo de Zenity es «revisa mis clientes potenciales más recientes y ayúdame con el más nuevo».

• El agente lee el registro envenenado y sigue las instrucciones que contiene, usando la herramienta Query Records que el subagente predeterminado General CRM ya tiene para consultar la tabla Accounts. Zenity es explícito en que no se necesitó escalada de privilegios: el mismo subagente se entrega con acceso de lectura tanto a Leads como a Accounts, y esos son valores predeterminados en lugar de configuraciones incorrectas.

• Escribe los valores que recuperó —el nombre de una empresa y el tamaño de una operación, en el ejemplo de los investigadores— en el subdominio de un nombre de host controlado por el atacante, y muestra el resultado al usuario como una etiqueta de imagen HTML.

• La superficie de chat renderiza fuentes de imágenes externas sin sanitización ni un paso de confirmación, por lo que el cliente resuelve el nombre de host. Los datos salen dentro de la consulta DNS.

Ese último paso es la parte en la que merece la pena detenerse. Dado que la carga útil viaja en la consulta DNS, la solicitud HTTP que sigue es irrelevante —puede fallar, agotar el tiempo de espera o bloquearse por completo, y los datos ya se han ido. Zenity señala que esto sobrevive a los controles de salida HTTP. Una etiqueta DNS individual está limitada a 63 caracteres y un nombre completo a 253, por lo que un solo envío filtra una porción; los investigadores describen cómo vaciar toda una tabla Accounts cuenta a cuenta mediante solicitudes repetidas, de ahí lo de «bleed» en el nombre.

Hay una segunda salida que requiere aún menos: para los agentes publicados en Slack, no se necesita ninguna etiqueta de imagen. Slack convierte las URL sin formato en vistas previas y rastrea el enlace para crear una, así que imprimir la URL basta para activar la misma consulta DNS. SecurityWeek cita el resumen de Zenity del comportamiento resultante: Slack inicia solicitudes que llevan datos de CRM a infraestructura controlada por atacantes en cuanto aparecen los enlaces.

Zenity precisa con cuidado qué significa «zero-click» en este contexto, y la distinción es importante. El empleado hace exactamente una cosa: le plantea a su propio agente una pregunta normal sobre sus propios leads. No abre un archivo adjunto, no sigue un enlace ni interactúa con nada de lo que envió el atacante. Todo lo que ocurre después de esa pregunta es automático. El lead malicioso también permanece en la tabla Leads como cualquier otro registro, por lo que puede activarse de nuevo cada vez que un empleado lo revise, y un atacante que quiera un canal más amplio puede simplemente enviar más leads. SecurityWeek registra un detalle que hace el fallo aún más flagrante: Agentforce informó de que el contenido había sido bloqueado por las políticas de seguridad de la organización, aunque los datos del CRM ya habían llegado al servidor del atacante.

Por qué no se mantuvo el filtro de Trusted URLs

URLs de confianza es el control de Salesforce diseñado para detener exactamente esto: restringe los destinos externos a los que Agentforce puede llegar y elimina enlaces e imágenes que apuntan a dominios que nadie ha aprobado. Zenity encontró dos casos límite que, combinados, lo sortearon por completo.

El primero era el dominio de nivel superior. El redactor solo reconocía una lista fija de TLD, y .fun —el dominio que utiliza la plataforma de pruebas fuera de banda app.interactsh.com— no estaba en ella. Un nombre de host que terminara en un TLD no reconocido podría no registrarse como nombre de host en absoluto. El segundo era dónde termina una URL: el redactor y la superficie que mostraba la respuesta no coincidían en los caracteres de terminación, y las llaves y los corchetes quedaban en esa brecha. Una cadena como https://random_string.oast.fun/{email} no es una URI válida según la RFC 3986, pero aun así genera la consulta DNS que necesita el ataque. El redactor veía una cadena malformada que no era una URL y la dejaba intacta; el navegador estaba dispuesto a obtenerla como fuente de imagen.

Un detalle estructural hizo que el bypass fuera ajustable. La redacción se ejecuta después de que el agente ha generado su salida, como un proceso separado del que el modelo no sabe nada. Zenity descubrió que tanto la salida sin procesar del agente como la versión redactada estaban presentes en las respuestas enviadas al cliente, lo que permitió a los investigadores comparar ambas y eliminar las anomalías que el filtro estaba detectando —por ejemplo, corchetes en un subdominio— hasta que la inyección fuera estable de extremo a extremo.

Dark Reading informa de que la redacción de URL de Salesforce se había basado hasta ahora en la coincidencia de expresiones regulares para decidir si una cadena parecía una URL, lo que permitía ocultar dominios en formatos inesperados. La compañía dice que lo ha sustituido por un análisis de URL conforme a la especificación y ha consolidado la inspección de URL para que todo el tráfico de agentes relacionado con URL pase ahora por una única puerta de enlace.

El tercer fallo: phishing bajo el nombre del propio agente

El hallazgo sobre Slack, publicado el mismo día en una segunda publicación atribuida a João Donato y sus colegas, se refiere a la identidad, no a los datos. Los agentes de Agentforce pueden publicarse directamente en Slack, y sus capacidades llegan como subagentes; Zenity señala que la plantilla Slack Knowledge, incluidas todas sus acciones, se puede añadir con dos clics.

La mayoría de las acciones de escritura en Slack que examinaron los investigadores incluían dos protecciones: un paso de confirmación antes del envío y la atribución del invocador, que indica a los destinatarios qué solicitud de usuario provocó el mensaje. Enviar un mensaje directo de Slack hizo ambas cosas. Responder a un hilo de Slack no hizo ninguna de las dos. Una vez que Agentforce decidió invocar esa acción, el mensaje se envió sin aprobación y sin atribución: llevaba la identidad del agente y nada que señalara a quien lo solicitó.

Eso produjo dos rutas de ataque. Un insider malicioso que ya puede conversar con el agente puede publicar phishing en el hilo correcto e irse sin nada que lo vincule, porque los destinatarios lo leen como un mensaje del agente. Un atacante externo obtiene el mismo resultado mediante la inyección Web-to-Lead: el lead envenenado indica al agente que responda en canales de Slack, y lo hace sin preguntar al empleado que lo activó. La elusión de la redacción de URL de la primera publicación es lo que permite que el enlace de phishing sobreviva al filtrado; Zenity descubrió después que los enlaces también podían ocultarse tras texto markdown de aspecto inocuo. Zenity y Salesforce enmarcan la consecuencia en los mismos términos: los empleados reciben el mensaje de un sistema confiable que ya opera dentro de su lugar de trabajo en lugar de un remitente externo desconocido, y cualquiera que siga el enlace y entregue credenciales expone el correo electrónico, Slack, los repositorios de código fuente y todo lo demás a lo que esa identidad pueda acceder.

Qué está establecido y qué no

Cuatro cosas están claras en las fuentes revisadas aquí. Zenity demostró las cadenas de ataque y publicó una prueba de concepto en video. Salesforce reconoce el análisis y describe los cambios que realizó —en declaraciones a Dark Reading y a SecurityWeek. No se asignó ningún CVE a ninguna de las tres fallas, lo que Dark Reading atribuye a que las correcciones se hicieron del lado de Salesforce, en un servicio alojado, y no en el software que ejecutan los clientes. Y Salesforce declara que por el momento no tiene evidencia de que algo de esto se haya explotado contra un cliente.

Lo que no está resuelto es cualquier aspecto relacionado con la escala. Ninguna fuente revisada aquí indica cuántos inquilinos de Agentforce ejecutaban las configuraciones predeterminadas afectadas, si algún dato de cliente llegó a salir realmente del entorno de un cliente, ni si alguien ajeno a Zenity Labs y Salesforce lo buscó. Los medios independientes —Dark Reading, SecurityWeek, Infosecurity Magazine y The Register— informaron cada uno de los hallazgos e incluyeron la respuesta de Salesforce, pero ninguna de esas coberturas informa de su propia reproducción del ataque. No existe una segunda investigación técnica independiente sobre SalesBleed, y este artículo no implica que la haya.

Las propias fuentes del expediente también discrepan en un detalle, de una manera que merece nombrarse en lugar de pasarse por alto. El comunicado de prensa de Zenity, distribuido a través de Business Wire el 24 de septiembre, afirma que Salesforce abordó las elusiones específicas de Trusted URLs denunciadas por Zenity «en aproximadamente dos semanas». La cronología día a día del artículo técnico de Zenity va del 1 de junio, cuando se envió el informe, al 18 y 19 de agosto, cuando se confirmó la corrección; más cerca de once semanas. Ambas versiones provienen de la misma organización.

Qué cambió Salesforce, y cuándo

El proceso de divulgación se prolongó y, según Zenity, fue cordial. Los hallazgos se enviaron a Salesforce por correo electrónico el 1 de junio de 2026; Salesforce los confirmó al día siguiente y dijo que estaba trabajando en las correcciones; los dos equipos mantuvieron una llamada técnica el 16 de junio; Salesforce cerró las divulgaciones el 17 de junio señalando que el equipo de ingeniería seguía trabajando. El 18 de agosto, Salesforce confirmó las correcciones y, el 19 de agosto, Zenity verificó específicamente el bypass de Trusted URLs. La atribución en la acción de Slack se confirmó corregida el 20 de agosto. Exigir confirmación de forma predeterminada tardó más: el 25 de agosto, Salesforce dijo que seguía trabajando en ello; el 10 de septiembre, fijó el 21 de septiembre como fecha objetivo; y el 21 de septiembre, Zenity probó y confirmó las tres.

Los cambios que describe Salesforce son específicos. La configuración predeterminada de ciertas acciones de Agentforce en Slack ahora requiere la confirmación del usuario antes de enviar un mensaje, y la empresa afirma que se está poniendo en contacto directamente con los clientes para revisar sus configuraciones. En Trusted URLs, la coincidencia por expresiones regulares ha desaparecido en favor de un análisis conforme a las especificaciones, y la inspección de URL se ha consolidado en una única puerta de enlace en lugar de gestionarse en varios puntos de un flujo de trabajo.

La nota final de Zenity sobre la corrección de Slack es una salvedad más que una señal de visto bueno. El requisito de confirmación es una configuración y basta un clic para desactivarlo; una vez desactivado, la misma vía de ataque vuelve a estar disponible. El consejo de los investigadores para las organizaciones que desarrollan agentes es que vigilen cómo se configuran las acciones de escritura en lugar de dar por sentado que la configuración predeterminada se mantiene.

Por qué los investigadores dicen que se generaliza

Por muy específicos que sean los detalles de Salesforce, Zenity enmarca SalesBleed como un ejemplo de un patrón. Su propio resumen es que cualquier agente que lea registros enviados por fuentes externas, muestre enlaces o imágenes a un usuario y además tenga acceso a herramientas para datos sensibles tiene los mismos tres ingredientes en el mismo lugar. Los investigadores denominan a la combinación una versión de la trifecta letal: datos privados, contenido no confiable y un canal de salida que confluyen en una misma identidad.

El patrón tiene antecedentes locales. Dark Reading informa que un año antes de SalesBleed, investigadores de Noma Security usaron la misma ruta Web-to-lead para llegar a datos de Salesforce, y que Salesforce respondió endureciendo sus reglas de URL —la redacción basada en expresiones regulares que Zenity luego eludió—. Un portavoz de Salesforce reconoció a Dark Reading que la respuesta anterior fue una solución rápida en lugar de integral, y dijo que esta está pensada para ser más robusta.

«Hemos encontrado múltiples formas de vulnerar la barrera de seguridad diseñada para impedir que Agentforce envíe datos empresariales a destinos no autorizados», afirma Michael Bargury, cofundador y director de tecnología de Zenity, en el comunicado. «Los límites estrictos siguen siendo una de las herramientas más sólidas de las que disponemos para contener a los agentes de IA, pero no dejan de ser software. Cuando esos controles fallan, nos quedamos con un agente de acceso privilegiado, con un alto grado de autonomía y sin límites». Tamir Ishay Sharbat, director de investigación de seguridad de Zenity, planteó la cuestión más amplia a Dark Reading: cuanto más poder se le da a un agente, más peligroso es, y un agente capaz de enviar mensajes por múltiples canales por sí solo mientras además lee contratos, oportunidades de venta o cuentas por pagar es una combinación que se acabará aprovechando de forma malintencionada. Bargury añadió una segunda preocupación al mismo medio: que los agentes se están construyendo como cajas negras, con resúmenes en lugar de registros, lo que dificulta saber qué hizo un agente o por qué.

Lo que haría pasar este registro de demostración a incidente no es una nueva técnica, sino una prueba: la divulgación de un cliente, un CVE o una declaración de Salesforce o Zenity de que las cadenas se vieron en uso. Nada de eso existe en las fuentes revisadas aquí. Hasta que exista una, SalesBleed se mantiene como lo que el archivo registra que es: una vulnerabilidad de alta gravedad, documentada con un estándar de confianza A por quienes la encontraron y confirmada como corregida por el proveedor, sin daños reales registrados.