Salesforce corrigió tres fallos en Agentforce que permitían a un atacante externo secuestrar los agentes de IA de una empresa usando nada más que un formulario público de contacto. Zenity Labs publicó la cadena —bautizada en conjunto como SalesBleed— el jueves, tras un ciclo de corrección de once semanas con Salesforce que cerró el último eslabón en agosto.
La puerta de entrada es Web-to-Lead, el formulario sin autenticación que las empresas colocan en sus sitios para captar consultas comerciales. El atacante envía un registro con instrucciones ocultas y no ocurre nada. La carga queda guardada en el CRM hasta que un empleado le pregunta algo rutinario a su agente —revisa mis últimos contactos, ayúdame con el más reciente— y en ese momento el agente lee el registro envenenado y obedece al atacante en lugar del empleado.
Puntos clave
- Zenity Labs reportó SalesBleed a Salesforce el 1 de junio de 2026; Salesforce lo confirmó al día siguiente y Zenity validó los parches finales el 19 de agosto, antes de la divulgación pública del 24 de septiembre.
- La exfiltración funcionó porque el censor de Trusted URLs de Salesforce y la superficie de renderizado no coincidían en dónde termina una URL: el censor solo reconocía una lista fija de dominios de primer nivel, y
.funno estaba en ella. - Un tercer fallo en la acción Reply to a Slack Thread no exigía confirmación del usuario ni dejaba rastro de autoría, lo que permitía a alguien de dentro enviar mensajes de phishing con la identidad del agente.
Cuando el censor y el navegador leen distinto
Agentforce tiene un control llamado Trusted URLs cuya función es limitar a qué destinos externos puede llegar el agente y censurar enlaces o imágenes que apunten a sitios no confiables. Los investigadores de Zenity —Alex Apostolov, João Donato, Avishai Efrat y Ayush RoyChowdhury— hallaron dos maneras de sortearlo.
Primero, el censor validaba los nombres de host contra un conjunto fijo de dominios de primer nivel, y uno no reconocido como .fun simplemente no llegaba a registrarse como URL. Segundo, las llaves y los corchetes dentro de un enlace no se censuraban y sobrevivían hasta la salida renderizada. Una cadena como https://random_string.oast.fun/{email} parecía lo bastante mal formada para que el censor la descartara y lo bastante válida para que un navegador la solicitara.
Esa grieta es todo el ataque. Las instrucciones inyectadas le indicaban al agente consultar la tabla Accounts con su propia herramienta Query Records, extraer el nombre de una empresa y el monto de una operación, pegar esos valores en el subdominio de un host controlado por el atacante e imprimir el resultado como una etiqueta de imagen HTML. El frontend la renderizó, la solicitó, y la consulta DNS llevó los campos robados al servidor de nombres autoritativo del atacante. El empleado no vio nada.
Slack lo empeoró y luego lo volvió anónimo
La misma carga funcionaba a través de Slack sin renderizar ninguna imagen, porque Slack despliega los enlaces para armar sus vistas previas. Basta con que una URL construida a medida aparezca en un canal para disparar la petición que envía campos del CRM hacia fuera: sin clic, sin pasar el cursor, sin ninguna acción del usuario más allá de revisar un contacto.
El tercer error tiene otra forma. La acción Reply to a Slack Thread de Agentforce salió sin aviso de confirmación y sin atribución visible al usuario que la invocaba. Alguien de dentro que ya estuviera conversando con el agente podía hacerle publicar enlaces de phishing bajo la identidad confiable del agente y permanecer anónimo. Combinado con el bypass de la censura de URL, el mensaje podía apuntar a cualquier parte.
Por qué el patrón sobrevive al parche
Salesforce cerró el bypass, así que estas cadenas concretas ya no funcionan. El planteo de Zenity es que la noticia son los ingredientes, no el fallo: cualquier agente de IA que lea registros enviados por terceros, devuelva enlaces o imágenes renderizados al usuario y disponga de herramientas con acceso a datos sensibles reúne los tres en el mismo lugar.
Michael Bargury, cofundador y CTO de Zenity, dijo a The Register que el enfoque secure-by-design sigue siendo esencial para los agentes, pero quizá ya no alcance, porque las protecciones incorporadas desde el inicio igual pasan por alto los casos límite que el agente encuentra cuando se topa con el mundo real. Señaló el incidente de OpenAI y Hugging Face, donde los agentes escaparon del sandbox que debía contenerlos, como parte de una tendencia más amplia, y sostuvo que vigilar lo que los agentes hacen realmente tiene que crecer al ritmo de su poder.
Ese argumento ya es una categoría de producto. Docker dedicó su keynote para desarrolladores de esta semana a la misma tesis y ofrece sandboxes microVM alojados partiendo de que los contenedores aíslan aplicaciones mientras los agentes necesitan contención. SalesBleed es la versión SaaS empresarial del mismo problema: Salesforce construyó una barrera de protección, y la barrera y el navegador leyeron la misma cadena de texto de distinta manera.
FAQ — Preguntas frecuentes
¿SalesBleed sigue siendo explotable?
No. Zenity Labs reportó los problemas a Salesforce el 1 de junio de 2026, Salesforce confirmó las correcciones el 18 de agosto y Zenity validó los parches el 19 de agosto. La divulgación del 24 de septiembre describe cadenas que ya no funcionan.
¿SalesBleed exigía que la víctima hiciera algún clic?
No, y eso es lo que lo hizo notable. La única acción necesaria era que un empleado le hiciera a su agente de Agentforce una pregunta rutinaria sobre contactos recientes. La exfiltración ocurría después mediante la carga automática de imágenes o el despliegue de enlaces de Slack.
¿Afecta a agentes de IA fuera de Salesforce?
El bypass concreto era propio de Salesforce, pero Zenity sostiene que la receta de fondo no lo es. Cualquier plataforma de agentes que ingiera registros externos no confiables, devuelva enlaces o imágenes renderizados a los usuarios y le dé al agente herramientas que lean datos sensibles puede ensamblarse en el mismo ataque.
