SalesBleed: Um Lead Público, Três Falhas do Agentforce, Zero Cliques

Em 24 de setembro de 2026, Zenity Labs publicou uma pesquisa que chama de SalesBleed: três vulnerabilidades no Salesforce Agentforce, a plataforma da fornecedora de CRM para criar e implantar agentes de IA, que permitem que um estranho extraia registros de clientes da organização Salesforce de uma empresa e depois use o próprio agente dessa empresa para fazer phishing contra sua equipe. Duas das três não exigem clique de ninguém dentro da empresa. A exposição se aplica a tenants do Agentforce que aceitam envios de Web-to-Lead e a qualquer agente que um tenant tenha publicado no Slack. O Dark Reading relata que nenhum identificador CVE foi atribuído, e a Salesforce disse ao veículo que não tem evidências de exploração contra nenhum cliente. O registro completo, com a nota de confiança e o status de dano do próprio arquivo, está no Orca AI Incident Archive, que registra cada incidente documentado de agente em relação às suas fontes citadas.

Como um formulário público de captação de leads se torna um canal de dados

O Web-to-Lead é o mecanismo oficial da Salesforce para recolher leads e, por design, não é autenticado — existe para que qualquer pessoa na internet possa submeter um formulário e fazer com que o conteúdo chegue ao CRM do cliente. O primeiro post da Zenity, atribuído a Alex Apostolov e colegas, começa precisamente com isso como a única condição de entrada: nenhuma conta para suspender, nenhuma sessão para revogar, nenhum evento de login para detetar. O atacante nunca toca no tenant.

A cadeia que os pesquisadores descrevem se desenrola em cinco movimentos:

• O atacante envia um lead por um endpoint público Web-to-Lead, com uma injeção de prompt oculta em um de seus campos. Parece uma consulta comum.

• O lead fica ali parado até que um funcionário peça ao seu agente algo completamente comum — o exemplo da Zenity é "verifique meus leads mais recentes e me ajude com o mais novo."

• O agente lê o registro envenenado e segue as instruções nele contidas, usando a ferramenta Query Records que o subagente padrão General CRM já possui para consultar a tabela Accounts. A Zenity deixa explícito que nenhuma escalação de privilégios foi necessária: o mesmo subagente vem com acesso de leitura tanto a Leads quanto a Accounts, e esses são padrões, e não configurações incorretas.

• Ele grava os valores que recuperou — no exemplo dos pesquisadores, o nome de uma empresa e o tamanho de um negócio — no subdomínio de um nome de host controlado pelo atacante e exibe o resultado de volta ao usuário como uma tag de imagem HTML.

• A superfície de chat renderiza fontes de imagem externas sem sanitização nem uma etapa de confirmação, portanto o cliente resolve o nome do host. Os dados saem dentro da consulta DNS.

Essa última etapa é a parte em que vale a pena ir devagar. Como o payload viaja na consulta DNS, a requisição HTTP que vem depois é irrelevante — ela pode falhar, dar timeout ou ser bloqueada de imediato, e os dados já terão saído. A Zenity observa que isso sobrevive a controles de saída HTTP. Um único rótulo DNS tem limite de 63 caracteres e um nome completo, de 253, então cada envio vaza uma fatia; os pesquisadores descrevem drenar uma tabela Accounts inteira, uma conta por vez, por meio de requisições repetidas, e é daí que vem o "bleed" do nome.

Há uma segunda via que exige ainda menos: para agentes publicados no Slack, nenhuma tag de imagem é necessária. O Slack transforma URLs brutas em pré-visualizações e rastreia o link para criar uma, então exibir a URL é suficiente para disparar a mesma consulta DNS. A SecurityWeek cita o resumo da Zenity sobre o comportamento resultante: o Slack inicia solicitações que carregam dados de CRM para infraestrutura controlada por atacantes assim que os links aparecem.

A Zenity toma cuidado com o que “zero-click” significa aqui, e a distinção importa. O funcionário faz exatamente uma coisa: faz ao próprio agente uma pergunta normal sobre os próprios leads. Ele não abre um anexo, não segue um link nem interage com nada que o atacante tenha enviado. Tudo depois dessa pergunta é automático. O lead malicioso também permanece na tabela Leads como qualquer outro registro, então pode disparar novamente sempre que um funcionário o revisar — e um atacante que queira um canal mais amplo pode simplesmente enviar mais leads. A SecurityWeek registra um detalhe que torna a falha ainda mais evidente: a Agentforce informou que o conteúdo havia sido bloqueado pelas políticas de segurança da organização, embora os dados do CRM já tivessem chegado ao servidor do atacante.

Por que o filtro de URLs confiáveis não funcionou

URLs confiáveis é o controle do Salesforce feito exatamente para impedir isso — ele restringe os destinos externos que o Agentforce pode alcançar e remove links e imagens que apontam para domínios que ninguém aprovou. A Zenity encontrou dois casos limite que, combinados, passaram direto por ele.

O primeiro era o domínio de nível superior. O redator reconhecia apenas uma lista fixa de TLDs, e .fun — o domínio usado pela plataforma de teste fora de banda app.interactsh.com — não estava nela. Um nome de host terminado em um TLD não reconhecido podia nem ser reconhecido como nome de host. O segundo era onde uma URL termina: o redator e a superfície que renderizava a resposta discordavam sobre os caracteres de terminação, e chaves e colchetes ficavam nessa lacuna. Uma string como https://random_string.oast.fun/{email} não é uma URI válida segundo a RFC 3986, mas ainda assim produz a consulta DNS de que o ataque precisa. O redator via uma não URL malformada e a deixava intacta; o navegador estava disposto a buscá-la como fonte de imagem.

Um detalhe estrutural tornou o bypass ajustável. A redação é executada depois que o agente gera sua saída, como um processo separado sobre o qual o modelo não sabe nada. A Zenity descobriu que a saída bruta do agente e a versão redigida estavam ambas presentes nas respostas enviadas ao cliente, o que permitiu aos pesquisadores comparar as duas e remover quaisquer anomalias que o filtro estivesse capturando — colchetes em um subdomínio, por exemplo — até que a injeção ficasse estável de ponta a ponta.

A Dark Reading relata que a ocultação de URLs da Salesforce até agora dependia de correspondência por expressões regulares para decidir se uma string se parecia com uma URL, o que permitia que domínios fossem ocultados em formatos inesperados. A empresa diz que substituiu isso por uma análise de URL em conformidade com a especificação e consolidou a inspeção de URLs, de modo que todo o tráfego de agentes relacionado a URLs agora passa por um único gateway.

A terceira falha: phishing em nome do próprio agente

A descoberta sobre o Slack, publicada no mesmo dia em uma segunda postagem atribuída a João Donato e colegas, é sobre identidade, e não sobre dados. Os agentes Agentforce podem ser publicados diretamente no Slack, e suas capacidades chegam como subagentes; a Zenity observa que o Slack Knowledge template, incluindo todas as suas ações, pode ser adicionado com dois cliques.

A maioria das ações de escrita no Slack examinadas pelos pesquisadores tinha duas proteções: uma etapa de confirmação antes do envio e a atribuição do invocador, informando aos destinatários qual solicitação de usuário causou a mensagem. Enviar uma mensagem direta no Slack tinha as duas. Responder a uma thread do Slack não tinha nenhuma das duas. Depois que o Agentforce decidiu invocar essa ação, a mensagem foi enviada sem aprovação e sem atribuição — carregava a identidade do agente e nada que apontasse de volta para quem a solicitou.

Isso gerou dois caminhos de ataque. Um insider malicioso que já consegue conversar com o agente pode publicar phishing no tópico certo e sair sem deixar nada que o rastreie, porque os destinatários leem a mensagem como se viesse do agente. Um atacante externo obtém o mesmo resultado por meio da injeção Web-to-Lead: o lead envenenado instrui o agente a responder em canais do Slack, e ele o faz sem perguntar ao funcionário que o acionou. O bypass de redação de URL da primeira postagem é o que permite que o link de phishing sobreviva à filtragem; mais tarde, a Zenity descobriu que links também podiam ser ocultados atrás de texto markdown de aparência inofensiva. A Zenity e a Salesforce enquadram a consequência nos mesmos termos: os funcionários recebem a mensagem de um sistema confiável que já opera dentro do ambiente de trabalho, e não de um remetente externo desconhecido, e qualquer pessoa que siga o link e entregue credenciais expõe e-mail, Slack, repositórios de código-fonte e tudo o mais que essa identidade conseguir acessar.

O que está estabelecido e o que não está

Quatro coisas estão assentadas nas fontes analisadas aqui. A Zenity demonstrou as cadeias de ataque e publicou um vídeo de prova de conceito. A Salesforce reconhece a análise e descreve as mudanças que fez — em declarações ao Dark Reading e ao SecurityWeek. Nenhum CVE foi atribuído a qualquer uma das três falhas, o que o Dark Reading atribui ao fato de as correções terem sido feitas no lado da Salesforce de um serviço hospedado, e não no software que os clientes executam. E a Salesforce afirma que, no momento, não tem evidências de que qualquer uma delas tenha sido explorada contra um cliente.

O que não está esclarecido é tudo o que diz respeito à escala. Nenhuma fonte analisada aqui indica quantos tenants do Agentforce executaram as predefinições afetadas, se algum dado de cliente chegou efetivamente a sair do ambiente de um cliente ou se alguém fora da Zenity Labs e da Salesforce o procurou. Os meios de comunicação independentes — Dark Reading, SecurityWeek, Infosecurity Magazine e The Register — noticiaram todos as conclusões e divulgaram a resposta da Salesforce, mas nenhuma dessas reportagens relata uma reprodução própria do ataque. Não existe uma segunda investigação técnica independente do SalesBleed, e este artigo não sugere que exista.

As próprias fontes do registro também divergem quanto a um detalhe, de uma forma que vale a pena explicitar em vez de suavizar. O comunicado de imprensa da Zenity, distribuído pela Business Wire em 24 de setembro, afirma que a Salesforce resolveu os bypasses específicos de Trusted URLs relatados pela Zenity "em aproximadamente duas semanas". A cronologia dia a dia na publicação técnica da Zenity vai de 1 de junho, quando o relatório foi enviado, a 18 e 19 de agosto, quando a correção foi confirmada — mais perto de onze semanas. Ambos os relatos vêm da mesma organização.

O que a Salesforce mudou, e quando

A divulgação foi longa e, segundo a Zenity, cordial. As constatações foram enviadas à Salesforce por e-mail em 1º de junho de 2026; a Salesforce confirmou-as no dia seguinte e disse que estava trabalhando em correções; as duas equipes realizaram uma chamada técnica em 16 de junho; a Salesforce encerrou as divulgações em 17 de junho, observando que a engenharia ainda estava trabalhando. Em 18 de agosto, a Salesforce confirmou as correções, e, em 19 de agosto, a Zenity verificou especificamente o bypass de Trusted URLs. A atribuição na ação do Slack foi confirmada como corrigida em 20 de agosto. Exigir confirmação por padrão levou mais tempo: em 25 de agosto, a Salesforce disse que ainda estava trabalhando nisso, em 10 de setembro deu 21 de setembro como meta, e em 21 de setembro a Zenity testou e confirmou todas as três.

As alterações que a Salesforce descreve são específicas. As definições predefinidas para determinadas ações do Agentforce no Slack agora exigem confirmação do usuário antes do envio de uma mensagem, e a empresa afirma que está contatando os clientes diretamente para reverem as suas configurações. Em Trusted URLs, a correspondência por regex foi removida em favor de uma análise sintática em conformidade com a especificação, e a inspeção de URLs foi consolidada num único gateway, em vez de ser tratada em vários pontos de um fluxo de trabalho.

A nota final da Zenity sobre a correção do Slack é uma ressalva, e não uma liberação total. O requisito de confirmação é uma configuração, e basta um clique para desativá-lo; depois de desativado, o mesmo caminho de ataque volta a ficar disponível. O conselho dos pesquisadores para organizações que criam agentes é observar como as ações de escrita são configuradas, em vez de presumir que o padrão se mantém.

Por que os pesquisadores dizem que isso se generaliza

Por mais específicos que sejam os detalhes para o Salesforce, a Zenity enquadra o SalesBleed como uma instância de um padrão. Seu próprio resumo é que qualquer agente que lê registros enviados por fontes externas, renderiza links ou imagens de volta a um usuário e também possui acesso de ferramenta a dados sensíveis tem os mesmos três ingredientes no mesmo lugar. Os pesquisadores chamam a combinação de uma versão da tríade letal — dados privados, conteúdo não confiável e um canal de saída convergindo em uma única identidade.

O padrão tem histórico local. O Dark Reading relata que, um ano antes do SalesBleed, pesquisadores da Noma Security usaram a mesma rota Web-to-lead para acessar dados do Salesforce, e que o Salesforce respondeu reforçando suas regras de URL — a ocultação baseada em regex que a Zenity então contornou. Um porta-voz do Salesforce reconheceu ao Dark Reading que a resposta anterior foi uma solução rápida, e não abrangente, e disse que esta agora pretende ser mais robusta.

"Encontramos várias maneiras de contornar a fronteira de segurança projetada para impedir que o Agentforce envie dados empresariais para destinos não aprovados", diz Michael Bargury, cofundador e diretor de tecnologia da Zenity, no comunicado. "Fronteiras rígidas continuam sendo uma das ferramentas mais fortes que temos para conter agentes de IA, mas ainda são software. Quando esses controles falham, ficamos com um agente com acesso privilegiado, alta autonomia e sem limites." Tamir Ishay Sharbat, diretor de pesquisa de segurança da Zenity, apresentou o ponto mais amplo ao Dark Reading: quanto mais poder é dado a um agente, mais perigoso ele é, e um agente que pode enviar mensagens por vários canais por conta própria enquanto também lê contratos, leads ou contas a pagar é uma combinação que será abusada. Bargury acrescentou uma segunda preocupação ao mesmo veículo — que os agentes estão sendo construídos como caixas-pretas, com resumos em vez de logs, o que dificulta saber o que um agente fez ou por quê.

O que faria este registro passar de demonstração para incidente não é uma nova técnica, mas uma peça de evidência: uma divulgação por cliente, uma CVE ou uma declaração da Salesforce ou da Zenity de que as cadeias foram observadas em uso. Nada disso existe nas fontes revisadas aqui. Até que exista, o SalesBleed permanece como o arquivo o registra — uma vulnerabilidade de alta gravidade, documentada com um padrão de confiança A pelas pessoas que a encontraram e confirmada como corrigida pelo fornecedor, sem nenhum dano real registrado.