🛡 VULNERABILIDADES 🛡

Salesbleed' explota agentes de Salesforce para habilitar phishing en Slack

⏰25 de septiembre de 2026🛡CyberObservatorio

Idioma

◢ VULNERABILIDADES ◣

Salesbleed' explota agentes de Salesforce para habilitar phishing en Slack

⟫ 24/09/2026 ⟫ Nate Nelson

Fuente: Dark Reading

**Vulnerabilidades en Salesforce Agentforce: El caso "Salesbleed" y sus implicaciones para la seguridad corporativa**

En un mundo cada vez más interconectado y digital, la seguridad de las plataformas que gestionan datos empresariales es fundamental. Recientemente, investigadores de seguridad han identificado una serie de vulnerabilidades en Salesforce Agentforce, a las que han denominado colectivamente "Salesbleed". Estas debilidades no solo podrían exponer los datos internos de los clientes, sino que también facilitan a los atacantes la posibilidad de realizar ataques de phishing a empleados a través de canales de comunicación de confianza dentro de las empresas. Este desarrollo es particularmente preocupante, dado que afecta a miles de organizaciones que confían en Salesforce para gestionar sus operaciones comerciales y la información sensible de sus clientes.

Las vulnerabilidades en cuestión, según el análisis de los investigadores de Zenity, permiten a los hackers extraer datos de manera gradual a través de formularios Web-to-lead. Lo más alarmante es cómo esta vulnerabilidad aparentemente trivial puede combinarse con flujos de trabajo normales en Agentforce para llevar a cabo ataques de phishing dirigidos a empleados dentro de sus propios canales de Slack, considerados seguros y de confianza.

Un año antes, Noma Security había revelado una técnica similar para robar datos corporativos utilizando Salesforce. El método comenzaba con formularios Web-to-lead, que son uno de los pocos contextos en los que las empresas aceptan datos ingresados libremente por individuos anónimos. En esencia, los prospectos de ventas completan un formulario de registro para obtener acceso a un recurso, y esa información se importa a Salesforce. Si bien anteriormente los atacantes podían haber utilizado estos formularios para enviar código malicioso, los investigadores de Noma determinaron que podían enviar instrucciones perjudiciales en su lugar.

Si un atacante sospechaba que su objetivo estaba utilizando agentes de inteligencia artificial de Agentforce, podía introducir una instrucción AI especialmente diseñada —como una orden para exfiltrar datos a una URL controlada por el atacante— en un formulario Web-to-lead. Un agente que procesara esta instrucción podría ejecutar la solicitud dentro del entorno de la empresa víctima. En respuesta a las revelaciones de Noma, Salesforce ajustó rápidamente sus reglas sobre URLs que un atacante podría utilizar para llevar a cabo dicho ataque. Sin embargo, como señaló Dark Reading en ese momento, "las soluciones estructurales para cómo su IA procesa las instrucciones siguen siendo esquivas".

A pesar de esta solución temporal, un año después, un nuevo grupo de investigadores de Zenity ha descubierto que pueden realizar un ataque similar, utilizando simples soluciones alternativas a las reglas de filtrado de URLs implementadas por Salesforce como respuesta a las vulnerabilidades del año anterior. Los investigadores destacaron la conveniencia de su ataque; no hay forma de identificar, suspender o castigar a un atacante que use formularios Web-to-lead, y al tener un agente de IA que haga el trabajo sucio, los atacantes pueden aprovechar los permisos que los clientes de Salesforce suelen otorgar a sus bots.

No obstante, la explotación por parte de Zenity tenía una limitación: para cada instrucción, un atacante solo podía extraer la cantidad de datos que cabía en un solo subdominio. Esto no sería suficiente para causar un daño significativo, a menos que el atacante buscara datos muy específicos o automatizara cientos o miles de solicitudes maliciosas.

Sin embargo, leer y enviar datos son solo dos de los muchos poderes que los agentes de Agentforce pueden ejercer. Si los agentes pueden realizar mil y una tareas para usuarios legítimos, ¿podrían hacer lo mismo para un atacante? Por ejemplo, los usuarios pueden implementar agentes de Salesforce directamente en Slack. Estos agentes pueden tener permisos variados, en forma de "subagentes", que les permiten leer o escribir datos. Para impedir acciones no deseadas, los agentes pueden configurarse para requerir la confirmación del usuario antes de realizar acciones. También incluyen un sistema de atribución que identifica al usuario humano responsable de una acción particular.

Sin embargo, estas medidas de control eran insuficientes cuando se trataba de la capacidad de un agente para responder a un hilo de Slack. Los investigadores de Zenity razonaron que, si un atacante externo podía introducir una instrucción maliciosa en un formulario Web-to-lead, no solo podría exfiltrar datos, sino que también podría inducir a un bot de Salesforce a responder a un hilo interno de Slack de la empresa. Esto no sería detectado por ninguna medida de seguridad existente. El mensaje podría incorporar técnicas de ingeniería social, incluyendo un enlace de phishing que aproveche las brechas previamente descritas en las protecciones de URL de confianza de Salesforce. En un canal de comunicación interno y confiable, es probable que nadie sospechara de una intención maliciosa.

En una declaración a Dark Reading, Salesforce reconoció las vulnerabilidades, que no tienen números CVE asignados, y señaló que no hay evidencia de que atacantes reales las hayan explotado. La empresa ha "actualizado la configuración predeterminada de ciertas acciones de Agentforce en Slack para requerir la confirmación del usuario antes de enviar mensajes, y está comunicándose directamente con los clientes para ayudarles a revisar sus configuraciones y realizar los cambios recomendados", declaró un portavoz.

Además, la compañía admitió que su respuesta a la vulnerabilidad de Web-to-lead del año pasado fue una solución rápida, en lugar de una exhaustiva. Esta vez, ha implementado lo que considera una solución más robusta. Anteriormente, el control de redacción de URLs de Salesforce se basaba en la coincidencia de expresiones regulares (regex) para identificar URLs no confiables en las salidas de los agentes de IA. Esencialmente, se verificaba si un texto parecía ser una URL, lo que permitía a investigadores astutos ocultar sus dominios en formatos inesperados. La empresa afirma que ahora utiliza un análisis de URLs conforme a especificaciones, que descompone y interpreta de manera más significativa hacia dónde podrían llevar las cadenas de texto potencialmente URL.

Además del sistema de análisis de URLs reestructurado, Salesforce está consolidando su proceso de inspección de URLs. Anteriormente, diferentes partes de un flujo de trabajo agentic podían actuar de manera independiente sobre una URL. Ahora, todo el tráfico de IA relacionado con URLs se canaliza a través de una única puerta de enlace que aplica reglas de inspección y seguridad más coherentes.

El tiempo dirá si los investigadores podrán eludir nuevamente las soluciones implementadas por Salesforce. Como señalan los analistas de Zenity, existen más debilidades estructurales en las plataformas de agentes que las políticas de URLs no pueden abordar. "Hemos estado diciendo esto durante años: Cuanta más autoridad se da a los agentes, más peligrosos son", afirma Tamir Ishay Sharbat, director de investigación en seguridad de Zenity. "El minuto en que un agente tiene el poder de enviar mensajes por sí mismo a múltiples canales, por ejemplo, se convierte en algo que puede ser abusado. Y cuando les das acceso a información sensible —como cuentas por pagar, prospectos, contratos, etc.— y canales externos [como formularios Web-to-lead], esta combinación es muy tóxica".

A esta combinación tóxica se suma un problema de visibilidad. "Cuando compras software empresarial, asumes que tendrá registros —que habrá una comprensión clara de quién hizo qué y por qué", observa Michael Bargury, director de tecnología de Zenity. "Con los agentes, porque todos están construyendo rápidamente, todo el mercado está creando cajas negras. Eso hace que sean más difíciles de confiar".

"No puedes ver el razonamiento, no puedes observar lo que hace tras bambalinas; solo obtienes resúmenes", lamenta Bargury. "Ese no es solo un problema en Salesforce; es algo que permea toda la industria".

En este contexto, es crucial que las organizaciones adopten medidas proactivas para proteger su información y la de sus clientes. La identificación de vulnerabilidades en plataformas de gran uso como Salesforce es solo el primer paso; la implementación de políticas de seguridad robustas y la capacitación continua del personal son fundamentales para mitigar riesgos en un panorama tecnológico en constante evolución.

◢ VULNERABILIDADES ◣

'Salesbleed' Exploits Salesforce Agents to Enable Slack Phishing

⟫ 24/09/2026 ⟫ Nate Nelson

Source: Dark Reading

Vulnerabilities in Salesforce Agentforce, collectively dubbed "Salesbleed" by researchers, could expose customers' internal data and, worse, allow attackers to phish employees from within trusted company channels. As so often happens withpowerful, interconnected AI platformsthat excite customers and investors, security and visibility remain hard problems to solve. Researchers at Zenity noted that the three "Salesbleed" weaknesses in Agentforce allow hackers to slowly bleed data from victims via Web-to-lead forms. The most interesting finding, though, is how this seemingly modest Web-to-lead vulnerability can be combined with normal Agentforce workflows to ultimately phish employees from within their most trusted Slack channels. One year ago, researchers at Noma Security revealed a neat little way tosteal corporate data using Salesforce. The trick began with Web-to-lead forms: one of the few contexts on the Internet in which companies will willingly accept near-arbitrary data sent by random individuals. Essentially, sales prospects fill out a registration form to gain access to something, and that lead data is then imported to Salesforce. In the past, attackers might have used Web-to-lead forms to send malicious code. In these agentic days, the researchers figured they could send malicious prompts. If an attacker presumed that their target was running Agentforce AI agents, it turned out that they could plant a specially crafted AI instruction — for example, an instruction to exfiltrate data to an attacker-controlled URL — in a Web-to-lead form. An agent on the other end of the interaction would ingest and process the instruction, and execute the request inside of the victim company's environment. Salesforce responded to Noma's findings by quickly polishing its rules around URLs that an attacker might use to carry out such an attack. Dark Reading noted at the time that "structural fixes to how its AI processes instructions however remain elusive for now." This Band-Aid failed to treat the underlying infection, and now, a year later, a new set of researchers from Zenity found that they could perform largely the same attack, using simple workarounds to the URL filtering rules Salesforce implemented in response to last year's findings. The researchers stressed how convenient their attack was. For one thing, there's no way to identify, suspend, or in any other way punish any passing Internet miscreant using Web-to-lead forms. And by having an AI agent do their bidding for them, attackers can effortlessly piggyback on the typically healthy permissions Salesforce customers willingly grant their bots. There was just one shortcoming in Zenity's exploit: For any given prompt, an attacker could exfiltrate only as much data as would fit into one subdomain string. That's hardly enough to cause much damage, unless the attacker were looking for very precise data, or automated hundreds or thousands of malicious requests. But reading and sending data are only two among many powers afforded to Agentforce agents. If agents can do a thousand and one other things for legitimate users, could they do those same things for an attacker? For example, users can deploy Salesforce agents directly to Slack. Slack agents can be assigned various permissions, in the form of "subagents," which allow them to read or write data. To ensure that they don't perform unwanted actions, agents can be configured to require user confirmation first. They also come with built-in attribution, identifying the human user responsible for a particular agentic action. However, these controls were missing when it came to an agent's ability to reply to aSlack thread. Zenity researchers reasoned that if an external attacker could inject a malicious prompt into a Web-to-lead form, instead of just exfiltrating data, the instruction could induce a Salesforce bot to reply to an internal company Slack thread, and nothing would stop them from doing it. The message could incorporate social engineering, with a phishing link leveraging those previously described gaps in Salesforce's trusted URL protections. Without attribution, it could look as if the message was sent by a real employee or IT help desk. In a trusted, internal communications channel, it's likely that nobody would suspect malicious intent. In a statement to Dark Reading, Salesforce acknowledged the vulnerabilities, which do not have CVE numbers, and noted that there has been no evidence that real attackers have exploited them. The company has "updated the default settings for certain Agentforce actions in Slack to require user confirmation before sending messages, and [is] communicating directly with customers to help themreview their configurationsand make the recommended changes," a spokesperson wrote. The company also acknowledged that its response to last year's Web-to-lead vulnerability was a quick fix, rather than a comprehensive one. This time around, it has implemented what it believes to be a more robust solution. Previously, Salesforce's URL redaction control relied on regular expression (regex) matching to identify untrusted URLs in AI agent outputs. Essentially, it checked whether a string of text looked like a URL, allowing clever researchers to conceal their domains in unexpected formats. The company says that it now uses spec-conformant URL parsing, which more meaningfully breaks down and interprets where potential URL strings lead. Besides the overhauled URL parsing system, Salesforce is also consolidating its URL inspection process. Whereas previously, different parts in an agentic workflow might have each acted upon a URL, now all URL-related AI traffic is funneled through a single gateway that applies more consistent inspection and security rules. Time will tell whether researchers will break Salesforce's fixes all over again. And as Zenity's analysts point out, there are more structural weaknesses to agentic platforms that URL policies can't account for. "We've been saying it for years now: The more power you give agents, the more dangerous they are," says Tamir Ishay Sharbat, director of security research at Zenity. "The minute that an agent has the power to send messages by itself to multiple channels, for example, it becomes something that you can abuse. And when you give them access to both sensitive information — your accounts payable, leads, contracts, etc. — and external channels [like Web-to-lead forms], this combination is very toxic." On top of that toxic combination, agents also have avisibility problem. "When you buy enterprise software, you assume that it will have logs — that it will have a clear understanding of who did what and why," notes Zenity chief technology officer Michael Bargury. "With agents, because everybody's building fast, the entire market is building black boxes. That makes them more difficult to trust." "You cannot look at the reasoning, you cannot look at what it does behind the scenes — you only get summaries," Bargury laments. "That's not just a problem in Salesforce; that's pervasive across the industry."

𝐗 Twitter f Facebook ☎ WhatsApp ✈ Telegram

← VOLVER A CIBERSEGURIDAD