Die Angriffskette knüpft an eine Entdeckung an, die Forscher von Noma Security ein Jahr zuvor veröffentlicht hatten. Schon damals ließ sich über Web-to-Lead-Formulare eine speziell gestaltete KI-Anweisung platzieren, etwa der Befehl, Daten an eine vom Angreifer kontrollierte URL zu senden. Der Agent auf der Gegenseite nahm die Anweisung entgegen und führte sie in der Umgebung des Unternehmens aus. Salesforce reagierte seinerzeit mit einer Nachschärfung der Regeln für erlaubte URLs; Dark Reading hielt damals fest, dass strukturelle Korrekturen an der Art, wie die KI Anweisungen verarbeitet, vorerst ausblieben.
Genau hier setzt Zenity an: Mit einfachen Umgehungen der eingeführten URL-Filterregeln gelang im Wesentlichen derselbe Angriff erneut. Die Forscher betonen die Bequemlichkeit des Vorgehens — wer Web-to-Lead-Formulare missbraucht, lässt sich weder identifizieren noch sperren oder anderweitig belangen. Und indem ein Agent die Arbeit übernimmt, profitieren Angreifer von den großzügigen Berechtigungen, die Salesforce-Kunden ihren Bots üblicherweise einräumen.
Eine Einschränkung blieb: Pro Prompt ließ sich nur so viel Datenmaterial abziehen, wie in eine Subdomain-Zeichenkette passt. Für großen Schaden reicht das kaum — es sei denn, es geht um sehr gezielte Informationen oder um Hunderte bis Tausende automatisierter Anfragen.
Deutlich weiter trägt der Slack-Pfad. Agenten lassen sich dort mit Berechtigungen in Form von “Subagenten” ausstatten, die Daten lesen oder schreiben dürfen. Zum Schutz vor unerwünschten Aktionen kann eine vorherige Bestätigung durch den Nutzer verlangt werden; zudem existiert eine eingebaute Zuordnung, die den verantwortlichen menschlichen Nutzer ausweist. Beim Antworten in einem Slack-Thread fehlten diese Kontrollen. Ein von außen eingeschleuster Prompt konnte einen Salesforce-Bot damit veranlassen, in einem internen Thread zu posten — mit einem Phishing-Link, der die zuvor beschriebenen Lücken im Schutz vertrauenswürdiger URLs ausnutzt. In einem internen, als vertrauenswürdig geltenden Kanal dürfte kaum jemand Verdacht schöpfen.
Salesforce erklärte gegenüber Dark Reading, man habe “die Standardeinstellungen für bestimmte Agentforce-Aktionen in Slack so geändert, dass vor dem Senden von Nachrichten eine Nutzerbestätigung erforderlich ist”, und kommuniziere direkt mit Kunden, damit diese ihre Konfigurationen prüfen und die empfohlenen Änderungen vornehmen. Das Unternehmen räumte zugleich ein, dass die Reaktion auf die Web-to-Lead-Lücke des Vorjahres eher eine schnelle als eine umfassende Lösung war.
Technisch stützte sich die URL-Redaktion bislang auf Abgleiche per regulärem Ausdruck: Geprüft wurde, ob eine Zeichenkette wie eine URL aussieht — was es erlaubte, Domains in unerwarteten Formaten zu verstecken. Nun setzt Salesforce nach eigenen Angaben auf spezifikationskonformes URL-Parsing. Zusätzlich bündelt das Unternehmen die Prüfung: Statt dass verschiedene Stationen eines agentischen Arbeitsablaufs jeweils eigenständig auf URLs reagieren, läuft der gesamte URL-bezogene KI-Verkehr jetzt durch ein einziges Gateway mit einheitlichen Inspektions- und Sicherheitsregeln.
“Wir sagen es seit Jahren: Je mehr Macht man Agenten gibt, desto gefährlicher werden sie”, sagt Tamir Ishay Sharbat, Director of Security Research bei Zenity. Sobald ein Agent von sich aus Nachrichten in mehrere Kanäle senden könne, sei er missbrauchbar — und die Kombination aus Zugriff auf sensible Informationen wie Verbindlichkeiten, Leads und Verträge einerseits und externen Kanälen andererseits sei “sehr toxisch”.
Hinzu kommt ein Transparenzproblem. “Beim Kauf von Unternehmenssoftware geht man davon aus, dass es Protokolle gibt — ein klares Bild davon, wer was warum getan hat”, sagt Zenity-CTO Michael Bargury. Weil alle schnell bauten, entstünden am Markt jedoch Blackboxes: “Man kann weder die Argumentation einsehen noch, was hinter den Kulissen passiert — man bekommt nur Zusammenfassungen.” Das sei kein reines Salesforce-Problem, sondern in der gesamten Branche verbreitet.