Um formulário público de angariação de contactos bastou para transformar um agente de inteligência artificial de confiança numa via de fuga de dados. A investigação, divulgada a 24 de setembro de 2026 pela equipa Zenity Labs, descreve três falhas no Salesforce Agentforce — batizadas em conjunto como SalesBleed — que permitiam exfiltrar dados de CRM sem qualquer clique da vítima e, num dos cenários, usar o próprio agente para enviar mensagens de phishing em canais internos de Slack. Segundo o relato da imprensa especializada e os apontamentos publicados pelos investigadores, a Salesforce corrigiu os problemas reportados e não há indícios de exploração real.
Resposta rápida: A Zenity Labs revelou três vulnerabilidades no Salesforce Agentforce, exploráveis através de formulários públicos Web-to-Lead, que permitiam roubo silencioso de dados de CRM e envio de mensagens fraudulentas via Slack em nome do agente. A Salesforce corrigiu as falhas — a última confirmação de teste ocorreu a 21 de setembro de 2026 — e afirma não ter evidências de exploração real. Não foram atribuídos identificadores CVE. As organizações que usam agentes de IA devem rever permissões, listas de URL permitidos e tratar todo o conteúdo submetido por terceiros como potencialmente malicioso.
Um ataque que começa num formulário de contacto
O ponto de entrada é banal e está presente em milhares de sites empresariais. Os investigadores explicam que era possível colocar cargas de injeção de prompt escondidas em formulários públicos Web-to-Lead, uma funcionalidade padrão do Salesforce que permite a utilizadores externos submeter dados que entram diretamente em registos de CRM. A questão é particularmente sensível porque o Web-to-Lead é, por desenho, não autenticado — qualquer pessoa na Internet pode submeter conteúdo.
O ataque não é imediato. As instruções maliciosas injetadas num lead permaneciam adormecidas até que um colaborador pedisse ao agente Agentforce para interagir com a submissão, levando-o a processar o registo envenenado e a executar as instruções ocultas. Na prática, é um payload que espera pacientemente dentro da base de dados comercial da empresa.
A partir daí, a cadeia desenrola-se sem pedir autorização a ninguém. As instruções injetadas podiam orientar o subagente “General CRM” a usar a capacidade Query Records que já possuía para aceder a outros dados do CRM, incluindo registos de contas — sem necessidade de escalar privilégios, porque o mesmo subagente já tinha acesso a leads e contas — e a colocar valores como nomes de empresas e dimensões de negócio dentro de um subdomínio de um URL controlado pelo atacante. O ambiente de conversação tentava carregar automaticamente esse endereço através de uma imagem HTML e a consulta de DNS resultante transportava os dados no subdomínio, sem que o colaborador tivesse de abrir qualquer ligação ou sequer ver a carga maliciosa.
Como os “Trusted URLs” foram contornados
A Salesforce dispõe de um mecanismo pensado exatamente para travar este tipo de fuga. As duas primeiras falhas resultavam de várias fragilidades nos Trusted URLs, o mecanismo de segurança concebido para impedir o Agentforce de apresentar URL e imagens de origens não fidedignas. O problema estava na divergência entre duas camadas de software. Em resumo, certos domínios de topo e caracteres de terminação de URL eram tratados de forma diferente pelo mecanismo de redação e pela superfície que consumia o resultado, pelo que um URL não fidedigno feito à medida podia passar sem ser reconhecido e continuar utilizável.
O detalhe mais incómodo para quem monitoriza estes sistemas: em alguns casos, o sistema indicava que o conteúdo tinha sido bloqueado por políticas de segurança da organização mesmo depois de os dados sensíveis já terem sido transmitidos com sucesso para o atacante. Ou seja, o painel dizia “bloqueado” quando a fuga já tinha acontecido.
Existia ainda uma variante que dispensava totalmente a interface do Salesforce. Os investigadores verificaram que o mecanismo de unfurling de ligações do Slack podia ser abusado para conseguir a mesma exfiltração sem clique: o Slack obtém automaticamente informação a partir de ligações para gerar pré-visualizações, e ligações especialmente construídas podiam levá-lo a iniciar pedidos que transportavam dados de CRM para infraestrutura controlada pelo atacante assim que a ligação aparecia.
Quando o phishing vem de dentro de casa
A terceira falha muda a natureza do risco. O ataque explorava controlos de segurança em falta na ação “Reply to a Slack Thread” do Agentforce: a ação não exigia confirmação do utilizador antes de enviar uma mensagem e não apresentava atribuição visível ao utilizador que a invocava, o que significa que um agente podia enviar mensagens sem aprovação humana. Um atacante podia assim usar um Web-to-Lead malicioso para sequestrar o agente e publicar mensagens de phishing no Slack com a identidade do próprio agente.
O efeito psicológico é evidente: como as mensagens tinham origem num sistema de confiança já a operar dentro do local de trabalho, os colaboradores ficavam mais expostos a seguir ligações maliciosas e a entregar credenciais de correio eletrónico, Slack ou repositórios de código. Os investigadores descobriram ainda que era possível esconder URL atrás de texto de ligação de aparência inofensiva usando markdown, o que tornava as ligações fraudulentas ainda mais credíveis.
Cronologia da divulgação responsável
| Data (2026) | Acontecimento |
|---|---|
| 1 de junho | Zenity Labs reporta as três falhas à Salesforce, que no dia seguinte confirma estar a trabalhar em correções |
| 17 de junho | Salesforce fecha os relatos, indicando que a equipa de engenharia trabalhava numa correção |
| 19 de agosto | Zenity confirma a correção do contorno dos Trusted URLs reportado |
| 20 de agosto | Confirmada a atribuição correta ao utilizador na ação de resposta a threads no Slack |
| 25 de agosto | Salesforce informa que ainda trabalhava na exigência de confirmação do utilizador por omissão |
| 10 e 21 de setembro | Salesforce aponta a conclusão para 21 de setembro; nessa data todas as correções são confirmadas e testadas |
| 24 de setembro | Publicação pública da investigação |
As datas de reporte e de confirmação das correções são apresentadas pelos próprios investigadores na sua cronologia de divulgação e no relato da imprensa especializada que acompanhou o caso.
Sem CVE, sem IOC públicos — e porque isso complica a vida às equipas
Ao contrário do que sucede com vulnerabilidades em software instalado, aqui não há versão para atualizar nem boletim para consultar. Em declarações à imprensa, a Salesforce reconheceu as vulnerabilidades, que não têm números CVE atribuídos, e referiu não haver evidências de exploração por atacantes reais. A empresa afirma ter reforçado os mecanismos afetados e atualizou as definições por omissão de determinadas ações do Agentforce no Slack, passando a exigir confirmação do utilizador antes do envio de mensagens.
Não foram divulgados indicadores de comprometimento (domínios, hashes ou endereços IP) associados a exploração real, o que é coerente com a ausência de casos conhecidos. Para as equipas de segurança, os sinais a procurar em registos históricos são de outra natureza: resoluções de DNS para subdomínios longos e aparentemente aleatórios a partir de ambientes ligados ao CRM, campos de lead com blocos de texto extenso contendo instruções em linguagem natural, e mensagens publicadas por agentes em canais internos sem utilizador associado.
Medidas concretas para quem usa agentes de IA
As recomendações práticas decorrentes da investigação aplicam-se muito para lá do Salesforce. As organizações devem rever as permissões das ferramentas do Agentforce, limitar os agentes ao mínimo de objetos de CRM necessários, aplicar listas de Trusted URLs estritamente delimitadas e tratar os campos de CRM submetidos externamente como instruções não fidedignas e não como conteúdo de negócio fiável. Recomenda-se também aplicar o princípio do menor privilégio aos subagentes, separando funções de revisão de leads do acesso a dados sensíveis de contas e contactos.
- Inventariar todos os agentes de IA em produção e documentar que dados cada um consegue ler e que ações consegue executar.
- Exigir confirmação humana para ações de escrita e de envio de mensagens para o exterior do sistema.
- Garantir atribuição visível: qualquer mensagem gerada por um agente deve identificar quem a desencadeou.
- Registar e monitorizar as chamadas de ferramentas dos agentes, não apenas as respostas em texto.
- Formar as equipas comerciais: uma mensagem vinda de um bot interno não é, por si só, sinal de legitimidade.
O alerta dos investigadores é estrutural. Michael Bargury, cofundador e diretor de tecnologia da Zenity, afirmou que a grande lição é sobre o que é preciso para manter os agentes de IA contidos, e que a ideia de segurança desde a conceção continua essencial mas, no caso dos agentes, pode já não ser suficiente. O SalesBleed demonstra o perigo de combinar três elementos num fluxo de trabalho de IA: conteúdo controlado pelo atacante, acesso a dados internos sensíveis e uma forma de enviar o resultado para fora.
Porque é que isto importa em Portugal
O Salesforce é uma das plataformas de CRM mais usadas por empresas portuguesas de média e grande dimensão, e a adoção de agentes de IA sobre dados comerciais está a acelerar. Os dados em causa — nomes de empresas, contactos, dimensão de negócios — incluem, quase sempre, dados pessoais de clientes e potenciais clientes. Uma exfiltração deste tipo constituiria uma violação de dados pessoais ao abrigo do RGPD, com as correspondentes obrigações de documentação interna e, quando aplicável, de notificação à CNPD no prazo de 72 horas e de comunicação aos titulares em caso de risco elevado.
Há ainda a dimensão da gestão de risco da cadeia de fornecimento digital. Para as entidades abrangidas pelo Regime Jurídico da Ciberseguranca (Decreto-Lei n.º 125/2025, que transpõe a NIS2), a utilização de plataformas SaaS com capacidades autónomas obriga a incluir esses serviços na análise de risco, nas políticas de controlo de acessos e nos procedimentos de deteção e notificação de incidentes ao CNCS/CERT.PT. Um agente com permissões excessivas é, à luz destas obrigações, um controlo de acesso mal desenhado — independentemente de a falha estar no fornecedor.
Para as PME, a lição é mais simples e mais imediata: antes de ligar um assistente de IA à base de clientes, vale a pena perguntar exatamente a que tabelas ele acede, se pode enviar mensagens sozinho e quem fica a saber quando o faz. Neste caso, foi um investigador a encontrar a falha. Na próxima, pode não ser.
Perguntas frequentes
A minha empresa precisa de instalar alguma atualização?
Não. Tratando-se de um serviço em nuvem, as correções foram aplicadas pelo fornecedor do lado do serviço. Segundo os investigadores, as correções da Salesforce garantem que o caminho de ataque descrito já não é possível por omissão. O que cabe às organizações é rever configurações próprias: permissões dos agentes, listas de URL permitidos e exigência de confirmação em ações de escrita.
O que é uma injeção indireta de prompt?
É a colocação de instruções maliciosas em conteúdo que o modelo de linguagem vai ler mais tarde — um campo de formulário, um documento, uma página web — em vez de as escrever diretamente na conversa. O modelo não distingue com fiabilidade entre dados a analisar e ordens a cumprir, pelo que pode executar as instruções escondidas como se viessem de um utilizador legítimo.
Houve roubo de dados de clientes portugueses?
Não há qualquer indicação nesse sentido. A Salesforce declarou não existirem evidências de que atacantes reais tenham explorado estas vulnerabilidades. A investigação corresponde a uma demonstração em ambiente controlado, divulgada de forma responsável após a correção.
Existem CVE ou indicadores de comprometimento a monitorizar?
Não foram atribuídos identificadores CVE a estas falhas nem foram divulgados indicadores de comprometimento associados a exploração real. As equipas podem, ainda assim, procurar sinais indiretos, como consultas de DNS para subdomínios invulgarmente longos geradas por interfaces de IA ou mensagens publicadas por agentes sem utilizador associado.
Esta informação tem caráter noticioso e baseia-se em dados divulgados publicamente pela Zenity Labs, pela Salesforce e por publicações especializadas de cibersegurança.