Análisis editorial original de OrbTrail ampliado con investigación complementaria, contexto práctico y referencias verificadas.
Zenity Labs divulgó el 24 de septiembre de 2026 tres fallos agrupados bajo el nombre SalesBleed. Dos cadenas comenzaban en un formulario público Web-to-Lead y terminaban en extracción de datos de CRM sin clic mediante una imagen renderizada en la conversación o el despliegue automático de una URL en Slack. La tercera utilizaba la acción Reply to a Slack Thread para publicar mensajes bajo la identidad del agente sin confirmación previa y sin atribuir visiblemente a quien activó la acción. La investigación se reportó a Salesforce el 1 de junio; Zenity afirma que el bypass de URL quedó validado como corregido el 19 de agosto y que todas las correcciones estaban probadas el 21 de septiembre. Por tanto, las cadenas descritas no deben presentarse como explotables por defecto hoy.
La pregunta central es qué debe demostrar una organización después del parche: ¿cómo garantizar que el contenido recibido desde fuera siga siendo un dato, sin adquirir autoridad para dirigir a un agente que también puede leer registros sensibles o escribir en un canal confiable? En el experimento, el atacante no tuvo que autenticarse ni elevar privilegios. Insertó instrucciones ocultas en un Lead; más tarde, una solicitud legítima de un empleado hizo que el agente leyera ese registro. El mismo subagente tenía una herramienta Query Records con alcance sobre Leads y Accounts, y la respuesta encontró una ruta automática hacia un dominio controlado por los investigadores.
El análisis de OrbTrail es que el incidente no cabe dentro de un solo control. La corrección del redactor de URLs cierra el bypass conocido; los permisos limitan qué registros alcanza una herramienta; la detección de prompt injection intenta reconocer instrucciones hostiles; la confirmación y la atribución contienen las acciones de escritura; y el canal decide si una URL se renderiza o se despliega automáticamente. Un programa de seguridad debe probar esas fronteras en conjunto. Si cada equipo valida únicamente su componente, la transición entre entrada pública, razonamiento, herramienta e interfaz puede quedarse sin responsable.
El lead público recibe contenido no confiable
Web-to-Lead es público por diseño. El registro debe seguir siendo dato aunque su texto parezca una instrucción para el modelo.
Una pregunta legítima lee el registro contaminado
El empleado no abre un enlace ni un adjunto; la ejecución comienza cuando pide ayuda sobre los leads recientes.
La herramienta define los datos expuestos
En la prueba, Query Records alcanzaba Leads y Accounts dentro del mismo subagente. El permiso existente fijó el radio sin escalada.
Render y unfurl convierten texto en tráfico
Una imagen HTML o una vista previa producía una consulta DNS. El dato salía al resolver el nombre antes de requerir una respuesta HTTP útil.
El parche debe resistir todo el recorrido
Valida redacción en cada canal, alcance mínimo, detección activa, confirmación de escritura y atribución del invocador.
El lead no invadió la org: cruzó la frontera como un registro válido
El primer punto complementario es entender por qué el ataque era zero-click sin confundirlo con acceso anónimo directo a la base. Web-to-Lead acepta envíos externos precisamente para crear Leads. La carga maliciosa quedaba guardada en un campo y permanecía inactiva. Cuando un empleado pedía a Agentforce revisar el lead más reciente, el modelo recibía el texto del registro junto con la tarea legítima e interpretaba parte de ese contenido como instrucciones. Es una inyección indirecta: la orden no viene del usuario autenticado, sino de un dato que entró por otra superficie.
Según Zenity, esas instrucciones hacían que Query Records buscara campos de Accounts y colocara sus valores en un subdominio. El redactor de URLs y el componente que renderizaba la respuesta discrepaban sobre qué era una URL válida cuando el hostname usaba un dominio de nivel superior no reconocido y ciertos caracteres finales. El redactor dejaba pasar la cadena, mientras el navegador todavía intentaba cargarla como origen de una imagen. El despliegue automático de Slack cumplía una función parecida. Como los valores estaban dentro del nombre consultado, el servidor DNS autoritativo de los investigadores podía recibirlos aunque la solicitud HTTP posterior fallara.
Una prueba útil no debe copiar datos reales ni convertir la demostración en receta de ataque. En un sandbox, crea registros externos sintéticos con marcadores inocuos, ejecuta los mismos recorridos del equipo comercial y observa cuatro resultados: el texto externo no cambia el objetivo del agente; una consulta no atraviesa objetos o campos fuera del caso; todo destino no aprobado se redacta de forma coherente en web y Slack; y ningún marcador aparece en DNS ni en una solicitud externa. Repite con cada canal habilitado, porque el bypass dependía de interpretaciones distintas de una misma salida.
El radio de exposición es el conjunto de herramientas, no la intención escrita en el topic
El segundo punto pregunta por qué una solicitud sobre Leads llegó a Accounts. La documentación actual de Salesforce indica que los agentes respetan licencias, permisos, seguridad de campos y reglas de acceso, y que las acciones personalizadas heredan el contexto configurado en Flow, Apex o prompt template. Eso mantiene al agente dentro de su identidad de ejecución. SalesBleed mostró otra dimensión: dentro de esa identidad, una herramienta amplia puede alcanzar más información de la necesaria para la tarea inmediata. La inyección no concedió un privilegio nuevo; reutilizó el que ya estaba disponible en el subagente General CRM.
La revisión posterior al parche debe comenzar con una matriz de capacidad efectiva. Para cada subagente, enumera herramientas, objetos, campos, operaciones de lectura o escritura, identidad de ejecución y canales donde aparece la salida. Después vincula cada capacidad con una tarea justificada. Si revisar un lead solo necesita campos de calificación, el caso negativo debe solicitar Accounts, Contacts y valores comerciales y confirmar la denegación. Cuando un agente realmente necesita contextos amplios, separa subagentes y acciones para que leer una entrada pública no comparta automáticamente la misma superficie con datos sensibles o mensajería saliente.
La detección de prompt injection añade una señal, no certeza. Salesforce documenta que la función, todavía beta, reconoce intentos directos e indirectos, registra puntuaciones en el audit trail y almacena esas señales en Data 360; también afirma expresamente que ningún modelo garantiza 100% de precisión. Se activa a nivel de org y depende de las ediciones y add-ons documentados. Actívala cuando corresponda, supervisa sus informes y prueba falsos negativos y positivos, pero conserva mínimo privilegio y salidas controladas como límites deterministas cuando falle el clasificador.
En Slack, confirmación y autoría forman parte de la autorización
El tercer punto aborda el efecto operativo. Zenity comparó acciones de escritura en Slack y encontró protecciones distintas: Send a Slack Direct Message pedía confirmación y mostraba quién la invocó, mientras Reply to a Slack Thread no exigía ninguna. Eso permitía a un usuario interno publicar phishing bajo la apariencia del agente y, combinado con un lead contaminado, que una entrada externa activara el mensaje cuando un empleado procesaba el registro. El contexto del thread y la identidad conocida del agente aumentaban la credibilidad sin comprometer la cuenta del destinatario.
Salesforce cambió el valor reportado: la atribución quedó confirmada el 20 de agosto y la confirmación obligatoria, el 21 de septiembre. Zenity señala que un administrador todavía puede desactivar la confirmación mediante una configuración. Por eso, la aceptación no termina en 'parche aplicado'. Para cada acción que envía mensajes o emails, modifica registros o inicia una integración, ejecuta una tarea de prueba y registra si hubo pausa para aprobación, qué detalles se mostraron antes de aceptar, cómo apareció el invocador para los destinatarios y qué evento quedó disponible para auditoría. Una confirmación vaga después del envío no cumple su función.
El plan inmediato es concreto: confirmar la configuración actual de las acciones de escritura; revisar agentes que combinan datos externos, herramientas de consulta y canales de comunicación; buscar registros creados por formularios públicos durante la ventana relevante según el proceso de incidentes de la organización; y añadir regresiones que atraviesen web y Slack. Las fuentes consultadas no permiten afirmar que todas las orgs fueron comprometidas ni que la corrección conocida elimina toda futura inyección indirecta. La conclusión de OrbTrail es más limitada y accionable: SalesBleed está corregido, pero el control duradero es demostrar que un dato no confiable nunca obtiene, por sí solo, el poder combinado de instruir, consultar y publicar.
