SalesBleed: Ein öffentlicher Lead, drei Agentforce-Schwächen, null Klicks

Am 24. September 2026 veröffentlichte Zenity Labs eine Studie, die es SalesBleed nennt: drei Sicherheitslücken in Salesforce Agentforce, der Plattform des CRM-Anbieters zum Erstellen und Bereitstellen von KI-Agenten, die es einem Fremden ermöglichen, Kundendatensätze aus der Salesforce-Org eines Unternehmens herauszuziehen und dann den eigenen Agenten des Unternehmens zu nutzen, um dessen Mitarbeiter zu phishen. Zwei der drei erfordern keinen Klick von jemandem im Unternehmen. Die Anfälligkeit betrifft Agentforce-Tenants, die Web-to-Lead-Übermittlungen akzeptieren, sowie jeden Agenten, den ein Tenant in Slack veröffentlicht hat. Dark Reading berichtet, dass keine CVE-Identifikatoren vergeben wurden, und Salesforce teilte der Publikation mit, dass es keine Hinweise auf eine Ausnutzung gegenüber einem Kunden gibt. Der vollständige Eintrag mit dem eigenen Konfidenzgrad und dem Schadensstatus des Archivs befindet sich im Orca AI Incident Archive, das jeden dokumentierten Agentenvorfall anhand seiner zitierten Quellen protokolliert.

Wie ein öffentliches Lead-Formular zu einem Datenkanal wird

Web-to-Lead ist Salesforces offizieller Mechanismus zum Erfassen von Leads, und er ist bewusst nicht authentifiziert – er existiert, damit jeder im Internet ein Formular absenden kann und der Inhalt im CRM des Kunden landet. Zenitys erster Beitrag, der Alex Apostolov und Kollegen zugeschrieben wird, beginnt mit genau diesem Umstand als der gesamten Einstiegsbedingung: kein Konto, das gesperrt werden müsste, keine Sitzung, die widerrufen werden müsste, kein Login-Ereignis, das erkannt werden müsste. Der Angreifer berührt den Tenant nie.

Die Kette, die die Forscher beschreiben, verläuft in fünf Schritten:

• Der Angreifer übermittelt einen Lead über einen öffentlichen Web-to-Lead-Endpunkt, mit einer versteckten Prompt-Injection in einem seiner Felder. Es wirkt wie eine gewöhnliche Anfrage.

• Der Lead bleibt dort liegen, bis ein Mitarbeiter seinen Agenten etwas völlig Alltägliches fragt – Zenitys Beispiel lautet: „Sieh dir meine neuesten Leads an und hilf mir mit dem neuesten."

• Der Agent liest den vergifteten Datensatz und befolgt die darin enthaltenen Anweisungen, indem er das Tool „Query Records“ verwendet, das der Standard-Subagent General CRM bereits besitzt, um die Tabelle „Accounts“ abzufragen. Zenity stellt ausdrücklich klar, dass keine Rechteausweitung erforderlich war: Derselbe Subagent verfügt standardmäßig über Lesezugriff auf sowohl „Leads“ als auch „Accounts“, und dabei handelt es sich um Standardeinstellungen und nicht um Fehlkonfigurationen.

• Es schreibt die abgerufenen Werte – im Beispiel der Forscher einen Firmennamen und eine Deal-Größe – in die Subdomain eines Hostnamens, den der Angreifer kontrolliert, und gibt das Ergebnis als HTML-Bild-Tag an den Nutzer zurück.

• Die Chat-Oberfläche stellt externe Bildquellen ohne Bereinigung oder Bestätigungsschritt dar, wodurch der Client den Hostnamen auflöst. Die Daten verlassen das Gerät in der DNS-Abfrage.

Der letzte Schritt ist der, bei dem man sich Zeit lassen sollte. Da die Nutzlast im DNS-Lookup übertragen wird, ist die darauf folgende HTTP-Anfrage irrelevant – sie kann fehlschlagen, in ein Timeout laufen oder vollständig blockiert werden, und die Daten sind bereits abgeflossen. Zenity weist darauf hin, dass dies HTTP-Egress-Kontrollen übersteht. Ein einzelnes DNS-Label ist auf 63 Zeichen und ein vollständiger Name auf 253 Zeichen begrenzt, sodass eine einzelne Übermittlung nur einen Ausschnitt preisgibt; die Forschenden beschreiben, wie sie eine gesamte Accounts-Tabelle Konto für Konto durch wiederholte Anfragen ausgelesen haben, woher der „Bleed“ im Namen rührt.

Es gibt einen zweiten Weg, der sogar noch weniger erfordert: Für Agents, die in Slack veröffentlicht werden, ist kein Image-Tag nötig. Slack verwandelt rohe URLs in Vorschauen und crawlt den Link, um eine solche Vorschau zu erstellen, daher reicht das Ausgeben der URL aus, um denselben DNS-Lookup auszulösen. SecurityWeek zitiert Zenitys Zusammenfassung des daraus resultierenden Verhaltens: Slack initiiert Anfragen mit CRM-Daten an von Angreifern kontrollierte Infrastruktur, sobald die Links erscheinen.

Zenity ist vorsichtig, was „Zero-Click“ hier bedeutet, und die Unterscheidung ist wichtig. Der Mitarbeiter tut genau eine Sache: Er stellt seinem eigenen Agenten eine normale Frage zu seinen eigenen Leads. Er öffnet keinen Anhang, folgt keinem Link und interagiert mit nichts, was der Angreifer gesendet hat. Alles nach dieser Frage ist automatisch. Der bösartige Lead bleibt außerdem wie jeder andere Datensatz in der Leads-Tabelle, sodass er jedes Mal erneut ausgelöst werden kann, wenn ein Mitarbeiter ihn überprüft – und ein Angreifer, der einen breiteren Kanal will, kann einfach mehr Leads einreichen. SecurityWeek hält ein Detail fest, das das Versagen noch schärfer macht: Agentforce meldete, dass der Inhalt durch die Sicherheitsrichtlinien der Organisation blockiert worden sei, obwohl die CRM-Daten bereits den Server des Angreifers erreicht hatten.

Warum der Trusted URLs-Filter nicht gegriffen hat

Vertrauenswürdige URLs ist die Salesforce-Kontrolle, die genau das verhindern soll – sie beschränkt die externen Ziele, die Agentforce erreichen kann, und entfernt Links und Bilder, die auf Domains verweisen, die niemand freigegeben hat. Zenity fand zwei Sonderfälle, die in Kombination direkt daran vorbeigingen.

Das erste war die Top-Level-Domain. Der Redactor erkannte nur eine feste Liste von TLDs, und .fun — die Domain, die von der Out-of-Band-Testplattform app.interactsh.com verwendet wird — stand nicht darauf. Ein Hostname, der auf eine unbekannte TLD endet, wurde möglicherweise überhaupt nicht als Hostname erkannt. Das zweite war, wo eine URL endet: Der Redactor und die Oberfläche, die die Antwort darstellte, waren sich bei den Abschlusszeichen uneinig, und geschweifte Klammern sowie eckige Klammern lagen in dieser Lücke. Eine Zeichenfolge wie https://random_string.oast.fun/{email} ist nach RFC 3986 keine gültige URI, erzeugt aber trotzdem die DNS-Abfrage, die der Angriff benötigt. Der Redactor sah eine fehlerhafte Nicht-URL und ließ sie unangetastet; der Browser war bereit, sie als Bildquelle abzurufen.

Ein strukturelles Detail machte die Umgehung justierbar. Die Schwärzung erfolgt, nachdem der Agent seine Ausgabe erzeugt hat, als separater Prozess, von dem das Modell nichts weiß. Zenity fand sowohl die Rohausgabe des Agenten als auch die geschwärzte Version in den an den Client gesendeten Antworten vor, wodurch die Forscher beide vergleichen und alle Anomalien beseitigen konnten, die der Filter abfing – etwa eckige Klammern in einer Subdomain –, bis die Injection durchgängig stabil war.

Dark Reading berichtet, dass Salesforces URL-Redaktion bislang auf Regular-Expression-Matching setzte, um zu entscheiden, ob eine Zeichenkette wie eine URL aussah, was es ermöglichte, Domains in unerwarteten Formaten zu verbergen. Das Unternehmen gibt an, dies durch spezifikationskonformes URL-Parsing ersetzt und die URL-Inspektion zusammengeführt zu haben, sodass der gesamte URL-bezogene Agenten-Traffic nun über ein einziges Gateway läuft.

Der dritte Fehler: Phishing unter dem eigenen Namen des Agenten

Der Slack-Befund, der am selben Tag in einem zweiten Beitrag veröffentlicht wurde, der João Donato und Kollegen zugeschrieben wird, betrifft Identität und nicht Daten. Agentforce-Agenten können direkt in Slack veröffentlicht werden, und ihre Fähigkeiten kommen als Subagenten; Zenity merkt an, dass die Slack Knowledge-Vorlage einschließlich aller ihrer Aktionen mit zwei Klicks hinzugefügt werden kann.

Die meisten Slack-Schreibaktionen, die die Forscher untersuchten, hatten zwei Schutzmechanismen: einen Bestätigungsschritt vor dem Senden und eine Zuordnung des Aufrufers, die den Empfängern mitteilte, durch welche Anfrage welches Benutzers die Nachricht ausgelöst worden war. Das Senden einer Slack-Direktnachricht erfüllte beides. Das Antworten auf einen Slack-Thread erfüllte keines von beiden. Sobald Agentforce beschloss, diese Aktion aufzurufen, ging die Nachricht ohne Genehmigung und ohne Zuordnung hinaus – sie trug die Identität des Agenten und nichts, was auf die Person zurückwies, die sie angefordert hatte.

Daraus ergaben sich zwei Angriffswege. Ein böswilliger Insider, der bereits mit dem Agenten chatten kann, kann Phishing im richtigen Thread posten und sich davonmachen, ohne dass sich etwas zu ihm zurückverfolgen lässt, weil die Empfänger es als Nachricht des Agenten lesen. Ein externer Angreifer erzielt dasselbe Ergebnis über die Web-to-Lead-Injection: Der vergiftete Lead weist den Agenten an, in Slack-Kanälen zu antworten, und er tut dies, ohne den Mitarbeiter zu fragen, der ihn ausgelöst hat. Die Umgehung der URL-Redaktion aus dem ersten Beitrag ist es, die den Phishing-Link die Filterung überleben lässt; Zenity fand später heraus, dass Links auch hinter harmlos wirkendem Markdown-Text verborgen werden konnten. Zenity und Salesforce formulieren die Konsequenz beide in denselben Begriffen: Mitarbeiter erhalten die Nachricht von einem vertrauenswürdigen System, das bereits in ihrem Arbeitsumfeld aktiv ist, und nicht von einem unbekannten externen Absender; und wer dem Link folgt und Zugangsdaten preisgibt, legt damit E-Mail, Slack, Quellcode-Repositories und alles Weitere offen, was diese Identität erreichen kann.

Was gilt als gesichert und was nicht

Vier Dinge sind in den hier untersuchten Quellen geklärt. Zenity hat die Angriffsketten demonstriert und ein Video als Proof of Concept veröffentlicht. Salesforce bestätigt die Analyse und beschreibt die vorgenommenen Änderungen – in Aussagen gegenüber Dark Reading und SecurityWeek. Keiner der drei Schwachstellen wurde eine CVE zugewiesen, was Dark Reading darauf zurückführt, dass die Korrekturen auf Salesforce-Seite eines gehosteten Dienstes und nicht in der von Kunden betriebenen Software vorgenommen wurden. Und Salesforce erklärt, dass es derzeit keine Hinweise darauf gibt, dass eine davon gegen einen Kunden ausgenutzt wurde.

Ungeklärt bleibt alles, was das Ausmaß betrifft. Keine der hier geprüften Quellen gibt an, wie viele Agentforce-Tenants mit den betroffenen Standardeinstellungen liefen, ob tatsächlich Kundendaten eine Kundenumgebung verlassen haben oder ob jemand außerhalb von Zenity Labs und Salesforce danach gesucht hat. Die unabhängigen Medien – Dark Reading, SecurityWeek, Infosecurity Magazine und The Register – berichteten jeweils über die Befunde und gaben die Antwort von Salesforce wieder, doch keiner dieser Berichte enthält eine eigene Reproduktion des Angriffs. Es gibt keine zweite unabhängige technische Untersuchung von SalesBleed, und dieser Artikel impliziert keine solche.

Die eigenen Quellen des Berichts widersprechen sich zudem in einem Detail – auf eine Weise, die es wert ist, benannt statt geglättet zu werden. Zenitys Pressemitteilung, die am 24. September über Business Wire verbreitet wurde, besagt, Salesforce habe die von Zenity gemeldeten spezifischen Umgehungen der Trusted URLs „innerhalb von etwa zwei Wochen“ behoben. Die tagesgenaue Zeitleiste in Zenitys technischem Beitrag reicht vom 1. Juni, als der Bericht gesendet wurde, bis zum 18. und 19. August, als die Behebung bestätigt wurde – näher an elf Wochen. Beide Darstellungen stammen von derselben Organisation.

Was Salesforce geändert hat und wann

Die Offenlegung zog sich lange hin und verlief nach Zenitys Darstellung freundlich. Die Befunde gingen am 1. Juni 2026 per E-Mail an Salesforce; Salesforce bestätigte sie am nächsten Tag und teilte mit, an Fehlerbehebungen zu arbeiten; die beiden Teams hielten am 16. Juni einen technischen Call ab; Salesforce schloss die Offenlegungen am 17. Juni ab und merkte an, dass die Engineering-Abteilung noch daran arbeite. Am 18. August bestätigte Salesforce die Fehlerbehebungen, und am 19. August verifizierte Zenity gezielt die Umgehung der Trusted URLs. Die Zuordnung bei der Slack-Aktion wurde am 20. August als behoben bestätigt. Die standardmäßige Bestätigungspflicht dauerte länger: Am 25. August erklärte Salesforce, noch daran zu arbeiten, am 10. September nannte Salesforce den 21. September als Ziel, und am 21. September testete und bestätigte Zenity alle drei.

Die von Salesforce beschriebenen Änderungen sind konkret. Standardeinstellungen für bestimmte Agentforce-Aktionen in Slack erfordern jetzt eine Bestätigung durch den Benutzer, bevor eine Nachricht gesendet wird, und das Unternehmen gibt an, Kunden direkt zu kontaktieren, um ihre Konfigurationen zu überprüfen. Bei Trusted URLs entfällt der Regex-Abgleich zugunsten einer spezifikationskonformen Verarbeitung, und die URL-Inspektion wurde in einem einzigen Gateway zusammengeführt, statt an mehreren Stellen eines Workflows behandelt zu werden.

Zenitys abschließende Anmerkung zur Slack-Korrektur ist ein Vorbehalt statt einer Entwarnung. Die Bestätigungspflicht ist eine Einstellung, und sie lässt sich mit einem Klick deaktivieren; ist sie einmal aus, steht derselbe Angriffsweg wieder offen. Die Empfehlung der Forscher an Organisationen, die Agenten entwickeln, lautet, genau darauf zu achten, wie Schreibaktionen konfiguriert sind, statt anzunehmen, dass die Standardeinstellung Bestand hat.

Warum die Forscher sagen, dass es sich verallgemeinern lässt

So Salesforce-spezifisch die Details auch sein mögen, betrachtet Zenity SalesBleed als einen Fall eines Musters. Die eigene Zusammenfassung lautet, dass jeder Agent, der von externen Quellen übermittelte Datensätze liest, Links oder Bilder an einen Nutzer zurückgibt und außerdem Tool-Zugriff auf sensible Daten besitzt, dieselben drei Zutaten am selben Ort vereint. Die Forscher nennen die Kombination eine Variante der lethal trifecta – private Daten, nicht vertrauenswürdige Inhalte und ein ausgehender Kanal, die in einer Identität zusammentreffen.

Das Muster hat lokale Vorgeschichte. Dark Reading berichtet, dass Forscher von Noma Security ein Jahr vor SalesBleed über dieselbe Web-to-lead-Route auf Salesforce-Daten zugriffen und dass Salesforce darauf mit einer Verschärfung seiner URL-Regeln reagierte – die regexbasierte Schwärzung, die Zenity anschließend umging. Ein Salesforce-Sprecher räumte gegenüber Dark Reading ein, die damalige Reaktion sei eine schnelle Lösung und keine umfassende gewesen, und sagte, diese hier solle robuster sein.

"Wir haben mehrere Wege gefunden, die Sicherheitsgrenze zu durchbrechen, die verhindern soll, dass Agentforce Unternehmensdaten an nicht genehmigte Ziele sendet", sagt Michael Bargury, Mitbegründer und Chief Technology Officer von Zenity, in der Mitteilung. "Harte Grenzen bleiben eines der stärksten Werkzeuge, die wir haben, um KI-Agenten einzudämmen, aber sie sind immer noch Software. Wenn diese Kontrollen versagen, bleibt uns ein Agent mit privilegiertem Zugriff, hoher Autonomie und ohne Grenzen." Tamir Ishay Sharbat, Leiter der Sicherheitsforschung bei Zenity, äußerte gegenüber Dark Reading den übergeordneten Punkt: Je mehr Macht einem Agenten gegeben wird, desto gefährlicher ist er, und ein Agent, der selbstständig mehrere Kanäle bedienen und gleichzeitig Verträge, Leads oder Kreditorenbuchhaltung lesen kann, ist eine Kombination, die missbraucht werden wird. Bargury fügte gegenüber demselben Medium eine zweite Sorge hinzu – dass Agenten als Blackboxes gebaut werden, mit Zusammenfassungen statt Protokollen, was es schwer macht zu sagen, was ein Agent getan hat oder warum.

Was diesen Eintrag von einer Demonstration zu einem Vorfall machen würde, ist keine neue Technik, sondern ein Beweisstück: eine Offenlegung durch einen Kunden, eine CVE oder eine Erklärung von Salesforce oder Zenity, dass die Ketten in der Praxis beobachtet wurden. Nichts davon existiert in den hier geprüften Quellen. Bis eines davon vorliegt, bleibt SalesBleed das, als was das Archiv es verzeichnet – eine Schwachstelle mit hohem Schweregrad, dokumentiert nach einem Confidence-A-Standard von den Personen, die sie fanden, und vom Hersteller als behoben bestätigt, ohne dokumentierten realen Schaden.