Análise editorial original do OrbTrail, ampliada com pesquisa complementar, contexto prático e referências verificadas.
A Zenity Labs divulgou em 24 de setembro de 2026 três falhas agrupadas sob o nome SalesBleed. Duas cadeias começavam em um formulário público Web-to-Lead e terminavam na saída de dados de CRM sem clique, por uma imagem renderizada na conversa ou pelo unfurl automático de uma URL no Slack. A terceira usava a ação Reply to a Slack Thread para publicar mensagens sob a identidade do agente sem confirmação prévia e sem atribuir visivelmente quem disparou a ação. A pesquisa foi reportada à Salesforce em 1º de junho; a Zenity afirma que o bypass de URL foi validado como corrigido em 19 de agosto e que todas as correções estavam testadas em 21 de setembro. Portanto, a cadeia descrita não deve ser apresentada como explorável por padrão hoje.
A questão central é o que uma organização precisa comprovar depois do patch: como garantir que conteúdo recebido de fora continue sendo tratado como dado, sem ganhar autoridade para orientar um agente que também lê registros sensíveis ou escreve em um canal confiável? No experimento, o atacante não precisou autenticar-se nem elevar privilégios. Ele inseriu instruções ocultas em um Lead; mais tarde, uma solicitação legítima de um funcionário fez o agente ler esse registro. O mesmo subagente tinha a ferramenta Query Records com alcance a Leads e Accounts, e a resposta encontrou uma saída automática até um domínio controlado pelo pesquisador.
A análise da OrbTrail é que o incidente não cabe em um único controle. A correção do redator de URLs fecha o bypass conhecido; permissões limitam quais registros a ferramenta alcança; detecção de prompt injection tenta reconhecer instruções hostis; confirmação e atribuição contêm ações de escrita; o canal decide se uma URL é renderizada ou expandida automaticamente. Um programa de segurança precisa testar essas fronteiras juntas. Se cada equipe valida apenas seu componente, a transição entre entrada pública, raciocínio, ferramenta e interface pode permanecer sem responsável.
O lead público recebe conteúdo não confiável
Web-to-Lead é público por desenho. O registro precisa permanecer dado, mesmo quando seu texto parece uma instrução para o modelo.
Uma pergunta legítima lê o registro envenenado
O funcionário não abre link nem anexo; a execução começa quando pede ajuda sobre os leads recentes.
A ferramenta define o dado exposto
No teste, Query Records alcançava Leads e Accounts dentro do mesmo subagente. Permissão existente determinou o raio, sem escalada.
Renderização e unfurl transformam texto em tráfego
Imagem HTML ou prévia de URL gerava uma consulta DNS. O dado já saía na resolução do nome, antes de qualquer resposta HTTP útil.
O patch precisa sobreviver ao fluxo completo
Valide redaction em cada canal, escopo mínimo de ferramenta, detecção ativa, confirmação de escrita e atribuição do invocador.
O lead não invadiu a org: ele atravessou a fronteira como um registro válido
O primeiro ponto complementar é entender por que o ataque era zero-click sem confundi-lo com acesso anônimo direto ao banco. Web-to-Lead aceita submissões externas justamente para criar Leads. A carga maliciosa ficava armazenada em um campo e permanecia inativa. Quando um funcionário pedia ao Agentforce para revisar o lead mais recente, o modelo recebia o texto do registro junto com a tarefa legítima e interpretava parte daquele conteúdo como instrução. Essa é uma injeção indireta: a ordem não vem do usuário autenticado, mas de um dado que entrou por outra superfície.
Segundo a Zenity, as instruções faziam a ferramenta Query Records buscar campos de Accounts e colocar os valores em um subdomínio. O redator de URLs e o componente que renderizava a resposta discordavam sobre o que constituía uma URL válida quando o hostname usava um domínio de topo não reconhecido e caracteres de terminação específicos. O redator deixava a sequência passar; o navegador ainda tentava carregar a origem de uma tag de imagem. No Slack, a expansão automática da URL cumpria função semelhante. Como os valores estavam no nome consultado, o servidor DNS autoritativo do domínio do pesquisador podia recebê-los mesmo que o tráfego HTTP posterior falhasse.
O reteste útil não deve copiar dados reais nem transformar a prova de conceito em receita. Em sandbox, crie registros externos sintéticos com marcadores inofensivos, execute as mesmas jornadas que equipes de vendas usam e observe quatro resultados: o texto externo não muda o objetivo do agente; uma consulta não atravessa objetos ou campos fora do caso; qualquer destino não aprovado é redigido de forma consistente na web e no Slack; nenhum marcador aparece em DNS ou requisição externa. Repita com os canais habilitados na organização, porque o bypass dependia da interpretação diferente da mesma saída por mais de um componente.
O raio de exposição é o conjunto de ferramentas, não a intenção escrita no tópico
O segundo ponto pergunta por que um pedido sobre Leads alcançou Accounts. A documentação atual da Salesforce afirma que agentes respeitam licenças, permissões, segurança em nível de campo e regras de compartilhamento; ações personalizadas também herdam o contexto configurado em Flow, Apex ou prompt template. Isso impede que o agente ultrapasse a identidade que executa. Mas o SalesBleed mostrou outra dimensão: dentro dessa identidade, uma ferramenta ampla pode alcançar mais dados do que a tarefa específica precisa. A injeção não concedeu um novo privilégio; ela reutilizou o privilégio já presente no subagente General CRM.
A revisão pós-patch deve começar por uma matriz de capacidade efetiva. Para cada subagente, liste ferramentas, objetos, campos, operações de leitura ou escrita, identidade de execução e canais onde a saída aparece. Depois associe cada capacidade a uma tarefa justificável. Se a revisão de um lead precisa apenas dos campos de qualificação, o caso de teste negativo deve pedir Account, Contact e valores comerciais e confirmar a negação. Quando um único agente precisa de contextos amplos, separe subagentes e ações de forma que a leitura de entrada pública não compartilhe automaticamente a mesma superfície com dados sensíveis ou mensageria de escrita.
A detecção de prompt injection acrescenta sinal, não certeza. A Salesforce documenta que o recurso, ainda beta, reconhece tentativas diretas e indiretas, registra pontuações no audit trail e armazena esses sinais em Data 360; também declara explicitamente que nenhum modelo garante 100% de acerto. O recurso é habilitado no nível da org e depende de edições e add-ons indicados na documentação. Ative-o quando elegível, acompanhe os relatórios e teste falsos negativos e falsos positivos, mas mantenha menor privilégio e saídas controladas como limites determinísticos para quando a classificação falhar.
No Slack, confirmação e autoria fazem parte da autorização
O terceiro ponto trata do efeito operacional. A Zenity comparou ações de escrita no Slack e encontrou proteções diferentes: Send a Slack Direct Message pedia confirmação e mostrava quem invocou a ação, enquanto Reply to a Slack Thread não exigia nenhuma das duas. Isso permitia a um usuário interno publicar phishing sob a aparência do agente e, combinado ao lead envenenado, permitia que uma entrada externa acionasse a mensagem quando um funcionário processasse o registro. O contexto da thread e a identidade conhecida do agente aumentavam a plausibilidade, mesmo sem comprometer a conta de quem recebia.
A Salesforce alterou o padrão reportado: a atribuição foi confirmada em 20 de agosto e a exigência de confirmação, em 21 de setembro. A Zenity ressalta que um administrador ainda pode desativar a confirmação com uma configuração. Por isso, o aceite não termina em 'patch aplicado'. Para cada ação que envia mensagem, email, altera registro ou inicia integração, execute uma tarefa de teste e capture se houve pausa para aprovação, quais detalhes foram mostrados antes do aceite, como o invocador apareceu para os destinatários e qual evento ficou disponível para auditoria. Uma confirmação vaga, depois que o conteúdo já foi enviado, não cumpre a função.
O plano imediato é objetivo: confirmar as configurações atuais das ações de escrita; revisar agentes que combinam dados externos, ferramentas de consulta e canais de comunicação; pesquisar registros criados por formulários públicos durante a janela relevante conforme a política de incidente da organização; e criar testes de regressão que atravessem web e Slack. Não há base nas fontes consultadas para afirmar que toda org foi comprometida, nem que a correção conhecida elimina qualquer futura injeção indireta. A conclusão da OrbTrail é mais estreita e acionável: SalesBleed foi corrigido, mas o controle durável é provar que um dado não confiável nunca recebe, sozinho, o poder combinado de instruir, consultar e publicar.
