SalesBleed: un lead pubblico, tre difetti di Agentforce, zero clic

Il 24 settembre 2026, Zenity Labs ha pubblicato una ricerca che chiama SalesBleed: tre vulnerabilità in Salesforce Agentforce, la piattaforma del fornitore CRM per creare e distribuire agenti AI, che consentono a un estraneo di estrarre i dati dei clienti dall'org Salesforce di un'azienda e poi usare l'agente della stessa azienda per fare phishing ai danni del personale. Due delle tre non richiedono alcun clic da parte di nessuno all'interno dell'azienda. L'esposizione riguarda i tenant Agentforce che accettano Web-to-Lead invii, e qualsiasi agente che un tenant ha pubblicato in Slack. Dark Reading riporta che non sono stati assegnati identificatori CVE, e Salesforce ha dichiarato alla testata di non avere prove di sfruttamento ai danni di alcun cliente. Il registro completo, con il grado di confidenza e lo stato di danno propri dell'archivio, si trova nel Orca AI Incident Archive, che registra ogni incidente documentato di agenti rispetto alle fonti citate.

Come un modulo pubblico per l'acquisizione di lead diventa un canale dati

Web-to-Lead è il meccanismo ufficiale di Salesforce per la raccolta dei lead ed è non autenticato per progettazione — esiste affinché chiunque su Internet possa inviare un modulo e far sì che il contenuto arrivi nel CRM del cliente. Il primo post di Zenity, attribuito ad Alex Apostolov e colleghi, si apre proprio con questo come unica condizione d'ingresso: nessun account da sospendere, nessuna sessione da revocare, nessun evento di login da rilevare. L'attaccante non tocca mai il tenant.

La catena descritta dai ricercatori si articola in cinque mosse:

• L'attaccante invia un lead tramite un endpoint Web-to-Lead pubblico, con un'iniezione di prompt nascosta in uno dei suoi campi. Sembra una normale richiesta di informazioni.

• Il lead resta lì finché un dipendente non chiede al proprio agente qualcosa di completamente ordinario — l'esempio di Zenity è "controlla i miei lead più recenti e aiutami con quello più recente".

• L'agente legge il record avvelenato e segue le istruzioni al suo interno, usando lo strumento Query Records che il subagente predefinito General CRM già possiede per interrogare la tabella Accounts. Zenity afferma esplicitamente che non è stata necessaria alcuna escalation di privilegi: lo stesso subagente dispone dell'accesso in lettura sia a Leads sia ad Accounts, e queste sono impostazioni predefinite anziché configurazioni errate.

• Scrive i valori recuperati — nell'esempio dei ricercatori, il nome di un'azienda e la dimensione di un'operazione — nel sottodominio di un hostname controllato dall'attaccante, e stampa il risultato all'utente come tag immagine HTML.

• La superficie della chat visualizza sorgenti di immagini esterne senza sanificazione né una fase di conferma, quindi il client risolve il nome host. I dati fuoriescono all'interno della query DNS.

È su quest’ultimo passaggio che vale la pena soffermarsi. Poiché il payload viaggia nella risoluzione DNS, la richiesta HTTP che segue è irrilevante: può fallire, andare in timeout o essere bloccata del tutto, e i dati sono già usciti. Zenity osserva che questo sopravvive ai controlli di egress HTTP. Una singola etichetta DNS è limitata a 63 caratteri e un nome completo a 253, quindi ogni invio fa trapelare solo una porzione; i ricercatori descrivono l’estrazione di un’intera tabella Accounts un account alla volta tramite richieste ripetute, ed è da qui che deriva il "bleed" nel nome.

Esiste una seconda via d’uscita che richiede ancora meno: per gli agenti pubblicati su Slack, non è necessario alcun tag immagine. Slack trasforma gli URL grezzi in anteprime ed esegue la scansione del link per generarne una, quindi stampare l’URL è sufficiente per attivare la stessa risoluzione DNS. SecurityWeek cita il riepilogo di Zenity sul comportamento risultante: Slack avvia richieste che trasportano dati CRM verso infrastrutture controllate dagli attaccanti non appena i link compaiono.

Zenity è attenta a cosa significa qui "zero-click", e la distinzione conta. Il dipendente fa esattamente una cosa: pone al proprio agente una normale domanda sui propri lead. Non apre un allegato, non segue un link e non interagisce con nulla di ciò che l'attaccante ha inviato. Tutto ciò che segue a quella domanda è automatico. Il lead malevolo resta anche nella tabella Leads come qualsiasi altro record, quindi può scattare di nuovo ogni volta che un dipendente lo esamina — e un attaccante che vuole un canale più ampio può semplicemente inviare più lead. SecurityWeek registra un dettaglio che rende il fallimento ancora più netto: Agentforce ha segnalato che il contenuto era stato bloccato dalle politiche di sicurezza dell'organizzazione, anche se i dati del CRM avevano già raggiunto il server dell'attaccante.

Perché il filtro Trusted URLs non ha funzionato

URL attendibili è il controllo Salesforce pensato per fermare esattamente questo: limita le destinazioni esterne che Agentforce può raggiungere e rimuove link e immagini che puntano a domini che nessuno ha approvato. Zenity ha trovato due casi limite che, combinati, lo hanno aggirato senza problemi.

Il primo era il dominio di primo livello. Il redattore riconosceva solo un elenco fisso di TLD, e .fun — il dominio usato dalla piattaforma di test out-of-band app.interactsh.com — non era presente. Un nome host che termina con un TLD non riconosciuto potrebbe non essere registrato affatto come nome host. Il secondo riguardava dove termina un URL: il redattore e la superficie che visualizza la risposta non concordavano sui caratteri di terminazione, e parentesi graffe e quadre stavano nel divario. Una stringa come https://random_string.oast.fun/{email} non è un URI valido secondo la RFC 3986, eppure produce comunque la query DNS necessaria all'attacco. Il redattore vedeva un non-URL malformato e lo lasciava intatto; il browser era disposto a recuperarlo come sorgente di un'immagine.

Un dettaglio strutturale ha reso il bypass regolabile. L’oscuramento avviene dopo che l’agente ha generato il proprio output, come processo separato di cui il modello non sa nulla. Zenity ha scoperto che l’output grezzo dell’agente e la versione oscurata erano entrambi presenti nelle risposte inviate al client, il che ha permesso ai ricercatori di confrontare i due e rimuovere qualunque anomalia il filtro stesse intercettando — ad esempio le parentesi quadre in un sottodominio — finché l’iniezione non è risultata stabile end-to-end.

Dark Reading riporta che fino ad ora il mascheramento degli URL di Salesforce si basava sul confronto tramite espressioni regolari per stabilire se una stringa somigliasse a un URL, il che consentiva di nascondere domini in formati inattesi. L'azienda afferma di aver sostituito tale meccanismo con un'analisi degli URL conforme alle specifiche e di aver consolidato l'ispezione degli URL, così che tutto il traffico degli agenti relativo agli URL passi ora attraverso un unico gateway.

Il terzo difetto: phishing a nome dell'agente stesso

La scoperta di Slack, pubblicata lo stesso giorno in un secondo post attribuito a João Donato e colleghi, riguarda l'identità più che i dati. Gli agenti Agentforce possono essere pubblicati direttamente in Slack e le loro capacità arrivano come subagenti; Zenity segnala che il template Slack Knowledge, comprese tutte le sue azioni, può essere aggiunto in due clic.

La maggior parte delle azioni di scrittura su Slack esaminate dai ricercatori prevedeva due protezioni: un passaggio di conferma prima dell'invio e l'attribuzione dell'invocatore, che indicava ai destinatari quale richiesta dell'utente avesse causato il messaggio. Invia un messaggio diretto su Slack le applicava entrambe. Rispondi a un thread di Slack non ne applicava nessuna. Dopo che Agentforce ha deciso di invocare quell'azione, il messaggio è partito senza approvazione e senza attribuzione — portava con sé l'identità dell'agente e nulla che rimandasse a chi l'aveva richiesto.

Ciò ha prodotto due percorsi di attacco. Un insider malintenzionato che può già chattare con l'agente può pubblicare phishing nel thread giusto e andarsene senza che nulla lo riconduca a lui, perché i destinatari lo leggono come un messaggio proveniente dall'agente. Un attaccante esterno ottiene lo stesso risultato tramite l'iniezione Web-to-Lead: il lead avvelenato indica all'agente di rispondere nei canali Slack, e l'agente lo fa senza chiedere al dipendente che l'ha attivato. Il bypass di redazione degli URL del primo post è ciò che consente al link di phishing di sopravvivere al filtro; in seguito Zenity ha scoperto che i link potevano anche essere nascosti dietro un testo markdown dall'aspetto innocuo. Zenity e Salesforce inquadrano entrambi la conseguenza negli stessi termini: i dipendenti ricevono il messaggio da un sistema affidabile che opera già all'interno del loro ambiente di lavoro anziché da un mittente esterno sconosciuto, e chiunque segua il link e consegni le credenziali espone email, Slack, repository di codice sorgente e quant'altro quell'identità possa raggiungere.

Che cosa è stabilito e che cosa non lo è

Quattro punti sono stabiliti nelle fonti esaminate qui. Zenity ha dimostrato le catene di attacco e pubblicato un video proof of concept. Salesforce riconosce l’analisi e descrive le modifiche apportate — in dichiarazioni a Dark Reading e a SecurityWeek. Nessun CVE è stato assegnato a nessuna delle tre vulnerabilità, cosa che Dark Reading attribuisce al fatto che le correzioni sono state apportate dal lato di Salesforce di un servizio ospitato anziché nel software eseguito dai clienti. E Salesforce afferma che al momento non ha prove che una qualsiasi di esse sia stata sfruttata contro un cliente.

Ciò che resta irrisolto riguarda ogni aspetto della scala. Nessuna delle fonti esaminate qui afferma quanti tenant Agentforce utilizzassero le impostazioni predefinite interessate, se dati dei clienti siano effettivamente usciti da un ambiente cliente o se qualcuno al di fuori di Zenity Labs e Salesforce abbia cercato prove in merito. Le testate indipendenti — Dark Reading, SecurityWeek, Infosecurity Magazine e The Register — hanno tutte riportato i risultati e pubblicato la risposta di Salesforce, ma nessuna di tali coperture riporta una propria riproduzione dell'attacco. Non esiste una seconda indagine tecnica indipendente su SalesBleed, e questo articolo non ne implica l'esistenza.

Anche le fonti del record stesso non concordano su un dettaglio, in un modo che vale la pena menzionare anziché attenuare. Il comunicato stampa di Zenity, diffuso tramite Business Wire il 24 settembre, afferma che Salesforce ha risolto i bypass specifici dei Trusted URLs segnalati da Zenity «in circa due settimane». La cronologia giorno per giorno nel post tecnico di Zenity va dal 1° giugno, quando è stata inviata la segnalazione, al 18 e 19 agosto, quando è stata confermata la correzione — più vicina a undici settimane. Entrambi i resoconti provengono dalla stessa organizzazione.

Cosa ha cambiato Salesforce, e quando

La divulgazione è stata lunga e, secondo Zenity, cordiale. I risultati sono stati inviati a Salesforce via email il 1° giugno 2026; Salesforce li ha confermati il giorno successivo e ha dichiarato di essere al lavoro sulle correzioni; i due team hanno tenuto una chiamata tecnica il 16 giugno; Salesforce ha chiuso le segnalazioni il 17 giugno, osservando che l'ingegneria era ancora al lavoro. Il 18 agosto Salesforce ha confermato le correzioni e il 19 agosto Zenity ha verificato specificamente il bypass dei Trusted URLs. L'attribuzione sull'azione Slack è stata confermata corretta il 20 agosto. Richiedere la conferma per impostazione predefinita ha richiesto più tempo: il 25 agosto Salesforce ha detto che ci stava ancora lavorando, il 10 settembre ha indicato il 21 settembre come obiettivo e il 21 settembre Zenity ha testato e confermato tutte e tre.

I cambiamenti descritti da Salesforce sono specifici. Le impostazioni predefinite per determinate azioni di Agentforce in Slack ora richiedono la conferma dell'utente prima dell'invio di un messaggio, e l'azienda afferma di star contattando direttamente i clienti per rivedere le loro configurazioni. Per quanto riguarda gli URL attendibili, la corrispondenza regex è stata eliminata a favore di un'analisi conforme alle specifiche, e l'ispezione degli URL è stata consolidata in un unico gateway invece di essere gestita in più punti di un flusso di lavoro.

La nota conclusiva di Zenity sulla correzione di Slack è un'avvertenza, non un via libera. Il requisito di conferma è un'impostazione e basta un clic per disattivarla; una volta disattivata, lo stesso percorso di attacco è di nuovo disponibile. Il consiglio dei ricercatori alle organizzazioni che sviluppano agenti è di monitorare come sono configurate le azioni di scrittura invece di dare per scontato che l'impostazione predefinita regga.

Perché i ricercatori dicono che è generalizzabile

Per quanto i dettagli siano specifici di Salesforce, Zenity inquadra SalesBleed come un'istanza di un pattern. La sua sintesi è che qualsiasi agente che legge record inviati da fonti esterne, mostra link o immagini all'utente e dispone anche di accesso tramite strumenti a dati sensibili ha gli stessi tre ingredienti nello stesso punto. I ricercatori chiamano la combinazione una versione della trifecta letale — dati privati, contenuti non attendibili e un canale in uscita che si incontrano in un'unica identità.

Il pattern ha una storia locale. Dark Reading riporta che un anno prima di SalesBleed, i ricercatori di Noma Security avevano usato la stessa via Web-to-lead per raggiungere i dati di Salesforce, e che Salesforce aveva risposto stringendo le proprie regole sugli URL — la redazione basata su regex che Zenity aveva poi aggirato. Un portavoce di Salesforce ha riconosciuto a Dark Reading che la risposta precedente era una toppa rapida anziché una soluzione completa, e ha affermato che questa volta l'intento è di essere più robusti.

"Abbiamo trovato molteplici modi per superare il confine di sicurezza progettato per impedire ad Agentforce di inviare dati aziendali a destinazioni non approvate", afferma Michael Bargury, cofondatore e chief technology officer di Zenity, nel comunicato. "I confini rigidi restano uno degli strumenti più potenti di cui disponiamo per contenere gli agenti AI, ma sono pur sempre software. Quando quei controlli falliscono, ci ritroviamo con un agente con accesso privilegiato, dotato di elevata autonomia e senza limiti". Tamir Ishay Sharbat, direttore della ricerca sulla sicurezza di Zenity, ha illustrato il concetto più ampio a Dark Reading: maggiore è il potere conferito a un agente, più pericoloso esso è, e un agente in grado di inviare messaggi su più canali da solo mentre legge contratti, lead o contabilità fornitori è una combinazione che verrà sfruttata. Bargury ha aggiunto una seconda preoccupazione alla stessa testata — ovvero che gli agenti vengono costruiti come scatole nere, con riepiloghi al posto dei log, il che rende difficile capire cosa abbia fatto un agente o perché.

Ciò che farebbe passare questa voce dalla dimostrazione a un incidente non è una nuova tecnica, ma un elemento di prova: una divulgazione da parte di un cliente, una CVE o una dichiarazione di Salesforce o Zenity secondo cui le catene sono state viste in uso. Nulla di tutto ciò esiste nelle fonti esaminate qui. Finché non esisterà, SalesBleed resta ciò che l’archivio registra che sia — una vulnerabilità ad alta gravità, documentata a uno standard di confidenza A dalle persone che l’hanno scoperta e confermata come risolta dal fornitore, senza alcun danno reale registrato.