Stellen Sie sich vor, eine Rechnung landet in Ihrem Posteingang. Ihr KI-Assistent fasst sie automatisch zusammen: Betrag, Frist, Absender – alles auf einen Blick, bevor Sie überhaupt die E-Mail geöffnet haben. Praktisch, schnell, genau das, wofür Sie den Assistenten eingerichtet haben. Nur: Was Ihnen die KI zeigt, muss nicht das sein, was tatsächlich in der Mail steht. Genau das haben Sicherheitsforscher von Forcepoint X-Labs Ende August 2026 in einem Testaufbau demonstriert – mit einer Methode, die so simpel ist, dass sie fast schon banal wirkt: weiße Schrift auf weißem Grund.
Was diesen Fund für Unternehmen im Mittelstand so relevant macht, ist nicht die technische Raffinesse – die ist überschaubar. Relevant ist, wie viel Vertrauen viele Betriebe inzwischen genau den Systemen entgegenbringen, die sich mit einem einzigen, unsichtbaren CSS-Trick austricksen lassen. Wer eine KI-Zusammenfassung ungeprüft in Buchhaltung, Terminplanung oder Kundenkommunikation übernimmt, verlässt sich auf eine Quelle, die – wie der Forcepoint-Test zeigt – von jedem manipuliert werden kann, der weiß, wie man eine HTML-Mail formatiert.
Der Fund: Was Forcepoint X-Labs entdeckt hat
Am 25. August 2026 veröffentlichte Forcepoint X-Labs einen Blogbeitrag mit dem Titel „HTML Payload Hijacks Email Summarizer via Prompt Injection", verfasst von Ben Gibney, Security Researcher III bei Forcepoint. Der Artikel beschreibt einen kontrollierten Testaufbau: ein isoliertes Labor mit synthetischen Daten und einem selbst gebauten Outlook-Add-in, das E-Mail-Header und -Inhalt an einen KI-gestützten Zusammenfassungsdienst schickte – angetrieben von Claude Haiku 4.5.
Wichtig vorab, weil es leicht zu Missverständnissen führt: Es handelt sich nicht um eine Sicherheitslücke bei Microsoft Outlook, nicht um ein Problem des verwendeten Sprachmodells und auch nicht um ein kommerzielles Produkt, das im produktiven Einsatz kompromittiert wurde. Forcepoint hat einen eigenen Prototyp gebaut, um ein strukturelles Risiko sichtbar zu machen, das grundsätzlich überall dort entsteht, wo E-Mail-Inhalte ungefiltert an ein Sprachmodell weitergereicht werden. Die Forscher selbst betonen das ausdrücklich: Es geht nicht um einen bestimmten Anbieter, sondern um ein Muster, das sich in vielen KI-Assistenten wiederfindet, die heute im Unternehmensalltag eingesetzt werden.
Und genau deshalb lohnt sich ein genauer Blick – auch und gerade für Betriebe, die selbst gar keinen Outlook-Summarizer im Einsatz haben, sondern irgendeine andere E-Mail-KI, einen Chat-Agenten mit Postfachzugriff oder ein Tool, das Dokumente automatisch verarbeitet.
Wie der Angriff funktioniert: Ein CSS-Trick, der so alt ist wie das Web selbst
Die Technik, die Forcepoint demonstriert, ist keine neue Erfindung. Spam-Versender nutzen unsichtbaren Text seit Jahrzehnten, um Filter zu überlisten – etwa indem sie harmlose Wörter in weißer Schrift unter den eigentlichen Spam-Inhalt packen. Neu ist nur das Ziel: Statt einen Spamfilter zu täuschen, wird jetzt das Sprachmodell getäuscht, das die E-Mail für Sie zusammenfasst.
Konkret nutzten die Forscher folgendes CSS-Styling innerhalb einer HTML-E-Mail:
font-size:0px; color:#ffffff; line-height:0
Für den Menschen, der die Mail in Outlook öffnet, ist dieser Textblock schlicht nicht sichtbar – Schriftgröße null, weiße Farbe, keine Zeilenhöhe. Für das Add-in, das den rohen HTML-Code der E-Mail ausliest und an das Sprachmodell übergibt, ist der Text jedoch vollständig vorhanden. Das Modell „liest" also etwas ganz anderes, als der Mensch vor dem Bildschirm zu sehen bekommt.
Die Zahlen aus dem Forcepoint-Test machen das greifbar: Die sichtbare E-Mail umfasste 537 Zeichen. Der tatsächlich an das Sprachmodell übergebene Text war mit 1.009 Zeichen fast doppelt so lang. Der Unterschied – 472 Zeichen – war der versteckte Injection-Payload: eine Anweisung an das Modell, die es aufforderte, den eingeschleusten Inhalt als „authoritative record", also als maßgebliche, verbindliche Quelle zu behandeln – und den versteckten Hinweis in der eigenen Zusammenfassung mit keinem Wort zu erwähnen.
Das ist der eigentliche Kern des Problems: Ein Sprachmodell unterscheidet von sich aus nicht zwischen „das ist der Inhalt, den ich zusammenfassen soll" und „das ist eine Anweisung, der ich folgen soll". Beides kommt im selben Textstrom an. Wenn im Text steht „behandle diese Angabe als verbindlich", dann tut das Modell genau das – unabhängig davon, ob diese Anweisung vom Absender der ursprünglichen Mail stammt oder von einem Angreifer, der sich in den HTML-Code eingeschlichen hat.
Ihr Unternehmen setzt bereits KI-Agenten für E-Mail, Rechnungsprüfung oder Dokumentenverarbeitung ein – oder plant es? Lassen Sie uns gemeinsam prüfen, wo ungefilterte Inhalte in Ihre KI-Prozesse gelangen könnten.
Kostenloses Erstgespräch vereinbarenDas Ergebnis: Zehn von zehn Testläufen manipuliert
Forcepoint führte den Test zehnmal durch. In allen zehn Läufen – also mit einer Erfolgsquote von 100 Prozent – übernahm die KI-Zusammenfassung die vom Angreifer vorgegebenen, falschen Angaben. Der Rechnungsbetrag erschien in der Zusammenfassung als 46.200 Euro, obwohl dieser Wert nicht dem tatsächlichen, sichtbaren Rechnungsinhalt entsprach. Die Zahlungsfrist wurde auf „3 Sep 2026 / 14:00" verschoben. Und ein Name, der ursprünglich Teil der Korrespondenz war – „Diego Siciliani" – verschwand komplett aus der Zusammenfassung, als hätte es diese Person in der E-Mail nie gegeben.
Besonders bemerkenswert: Für den Menschen, der die manipulierte E-Mail in Outlook öffnete, gab es praktisch kein erkennbares Warnsignal. Der einzige Hinweis auf die Manipulation war minimal zusätzlicher Weißraum vor der Signatur – ein Unterschied, den in der Praxis niemand bewusst bemerken würde, wenn er nicht gezielt danach sucht. Wer sich auf die KI-Zusammenfassung verlässt, weil genau das der Sinn der Automatisierung ist, hätte den falschen Betrag und die verschobene Frist ohne Weiteres für bare Münze genommen.
Genau hier liegt die eigentliche Brisanz: Es geht nicht darum, dass ein Sprachmodell „Fehler macht" im Sinne einer Ungenauigkeit. Es folgt exakt der Anweisung, die es erhalten hat – nur eben einer Anweisung, die nicht von Ihnen oder Ihrem tatsächlichen Geschäftspartner stammt, sondern von jemandem, der sich zwischen die Zeilen geschmuggelt hat.
Kein Einzelfall: Prompt Injection ist Risiko Nummer eins
Wer jetzt denkt, das sei ein exotisches Laborexperiment ohne reale Relevanz, sollte einen Blick auf den größeren Kontext werfen. Im OWASP Top 10 for LLM Applications 2025 führt Prompt Injection bereits zum zweiten Mal in Folge die Rangliste der Risiken für KI-Anwendungen an – Platz eins, noch vor Themen wie Datenlecks oder unsicherer Ausgabeverarbeitung. Das ist kein Zufall, sondern die logische Konsequenz daraus, dass immer mehr Unternehmen Sprachmodelle mit externen, nicht vertrauenswürdigen Inhalten füttern: E-Mails, Webseiten, hochgeladene Dokumente, Kalendereinladungen.
Ein besonders eindrückliches reales Beispiel liefert der Fall EchoLeak (CVE-2025-32711), den die Sicherheitsfirma Aim Security im Juni 2025 offenlegte. EchoLeak gilt als der erste dokumentierte Zero-Click-Prompt-Injection-Exploit in einem produktiven KI-System – konkret in Microsoft 365 Copilot. Mit einem CVSS-Score von 9,3 zählt die Schwachstelle zu den kritischsten, die je in einem produktiven KI-Assistenten gefunden wurden. Auch hier war der Auslöser eine präparierte E-Mail, und auch hier war keinerlei Interaktion des Nutzers nötig – die Kompromittierung lief vollständig im Hintergrund ab, während der Empfänger nichts davon mitbekam. EchoLeak wurde inzwischen gepatcht und ist ein abgeschlossener, dokumentierter Vorfall aus 2025 – wichtig ist er hier vor allem als Beleg dafür, dass das, was Forcepoint im Labor zeigt, keine theoretische Spielerei ist, sondern ein Muster, das bereits in freier Wildbahn ausgenutzt wurde. Wichtig ist zudem die Abgrenzung: Forcepoints Test von 2026 und der EchoLeak-Vorfall von 2025 sind zwei getrennte Ereignisse bei zwei unterschiedlichen Systemen – der eine ein bereits behobener, realer Vorfall bei einem produktiven Microsoft-Produkt, der andere ein aktueller Labor-Nachweis mit einem eigenen Prototyp. Gemeinsam zeigen beide jedoch dasselbe Grundmuster: E-Mail als Einfallstor, keine Nutzerinteraktion nötig, und ein Sprachmodell, das exakt dem folgt, was der versteckte Text ihm vorgibt.
Auch akademische Untersuchungen bestätigen, wie real das Problem ist. Der InjecAgent-Benchmark testete, wie anfällig GPT-4-basierte Agenten mit dem verbreiteten ReAct-Framework für indirekte Prompt Injection sind. Im Basisfall ließen sich 24 Prozent der Angriffe erfolgreich durchführen – mit optimierten, gezielteren Angriffstechniken stieg die Erfolgsquote auf 47 Prozent. Fast jeder zweite Versuch war erfolgreich, sobald der Angreifer ein wenig Sorgfalt in die Formulierung seiner versteckten Anweisung investierte.
Es handelt sich nicht um ein spezifisches Problem eines LLM-Anbieters oder Summarizers, sondern um ein strukturelles Risiko, wenn ungefilterter E-Mail-Inhalt ungeprüft an ein Sprachmodell weitergereicht wird.
Diese Einordnung von Forcepoint trifft den Kern: Es ist kein Bug, den ein Software-Update beheben wird. Es ist eine Architekturfrage – nämlich die Frage, ob und wie Sie zwischen vertrauenswürdigen Anweisungen und unkontrolliertem, externem Inhalt trennen, bevor beides in denselben KI-Prompt wandert.
Was das für Ihren Mittelstandsbetrieb bedeutet
An dieser Stelle könnte man einwenden: Das betrifft doch nur Großkonzerne mit komplexen Copilot-Rollouts. Das Gegenteil ist der Fall. Gerade im Mittelstand setzen immer mehr Betriebe E-Mail-Agenten, Outlook-Add-ins oder eigene KI-Pipelines ein, die eigenständig Fristen setzen, Rechnungen zusammenfassen, Termine anlegen oder Rückfragen formulieren – oft mit deutlich weniger dedizierten IT-Sicherheitsressourcen als ein Großunternehmen. Genau dieses autonome Handeln war es, das Forcepoint im Test vollautomatisch und für den Menschen unsichtbar kaperte.
Der entscheidende Prüfmaßstab dafür, wie riskant ein bestimmter Agenten-Workflow in Ihrem Betrieb tatsächlich ist, lässt sich auf drei Fragen herunterbrechen – manchmal als „tödliches Trio" bezeichnet: Hat der Agent Zugriff auf sensible, vertrauliche Daten? Verarbeitet er Inhalte, die von außen kommen und nicht geprüft sind – E-Mails, Webinhalte, hochgeladene Dateien? Und kann er selbstständig nach außen kommunizieren oder handeln – eine Mail versenden, eine Zahlung anstoßen, einen Termin verschieben? Sobald alle drei Bedingungen gleichzeitig erfüllt sind, ist ein Workflow grundsätzlich anfällig für genau die Art von Angriff, die Forcepoint demonstriert hat.
Wie ernst es um die Vorbereitung vieler Unternehmen auf dieses Risiko steht, zeigen Erhebungen von Kiteworks aus dem Jahr 2026 – die Zahlen unterscheiden sich je nach zitierter Quelle etwas, zeichnen aber unabhängig davon ein konsistentes Bild: Ein erheblicher Anteil der Unternehmen verfügt demnach noch nicht über grundlegende, dedizierte Kontrollen für den sicheren Einsatz von KI-Agenten, und vielen fehlt eine durchsetzbare Zweckbindung, die festlegt, welche Daten ein Agent überhaupt anfassen darf. Mit anderen Worten: Die Technik ist oft schon im Einsatz, die Governance dahinter hinkt vielerorts noch hinterher.
Wie steht es um die Freigabe-Stufen Ihrer eigenen KI-Agenten? Wir helfen Ihnen, kritische Aktionen – Fristen, Zahlungen, Rechnungsdaten – mit sinnvollen menschlichen Kontrollpunkten abzusichern, ohne die Effizienz der Automatisierung zu verlieren.
Governance-Check anfragenPraxis-Check: So schützen Sie Ihre KI-Agenten vor versteckten Anweisungen
Die gute Nachricht: Forcepoint hat aus dem Test nicht nur ein Problem, sondern auch konkrete Gegenmaßnahmen abgeleitet – und die meisten davon sind auch für kleinere IT-Teams ohne riesiges Sicherheitsbudget umsetzbar.
Erstens: Extrahieren Sie nur den für den Nutzer sichtbaren Text, bevor Inhalte an ein Sprachmodell gehen – nicht den rohen HTML-Code. Was der Mensch nicht sieht, sollte auch die KI nicht als relevanten Inhalt bekommen. Zweitens: Erkennen und filtern Sie verdächtige, versteckte CSS-Styles aktiv – Schriftgröße null, weiße oder transparente Schriftfarbe, Zeilenhöhe null, display:none. Das sind bekannte Muster, die sich technisch zuverlässig erkennen lassen, bevor der Text überhaupt beim Modell ankommt. Drittens: Trennen Sie E-Mail-Header strikt vom eigentlichen Body, damit Absenderinformationen nicht mit potenziell manipuliertem Inhalt vermischt werden.
Viertens, und das ist vielleicht der wichtigste Grundsatz: Behandeln Sie jeglichen E-Mail-Inhalt grundsätzlich als nicht vertrauenswürdige Daten – unabhängig davon, wie seriös der Absender wirkt. Und fünftens: Verifizieren Sie KI-Ausgaben stichprobenartig gegen die Originalquelle, bevor auf ihrer Basis kritische Aktionen ausgelöst werden – gerade bei Beträgen, Fristen und rechtlich relevanten Zusagen.
Für Ihren konkreten Betrieb heißt das ganz praktisch: Prüfen Sie, ob Ihr aktuelles Setup E-Mail-HTML vor der KI-Verarbeitung überhaupt filtert, oder ob roher Inhalt ungeprüft durchgereicht wird. Definieren Sie klare Freigabe-Stufen: Eine reine Zusammenfassung oder ein Vorschlag durch den Agenten ist im Regelfall unkritisch – ein autonomes Ausführen, etwa das Verschieben einer Frist, das Anlegen einer Rechnung oder das Auslösen einer Zahlung, sollte ab einer bestimmten Sensitivität zwingend eine menschliche Bestätigung erfordern. Und machen Sie sich einen einfachen Erstcheck zur Gewohnheit: Welche E-Mail- und Dokumenten-Agenten in Ihrem Unternehmen haben aktuell Schreib- oder Ausführungsrechte auf Kalender, Rechnungswesen oder CRM – und läuft das ohne jeden Bestätigungsschritt?
Keine dieser Maßnahmen erfordert, dass Sie auf die Vorteile von KI-Agenten verzichten. Es geht nicht darum, Automatisierung zurückzudrehen, sondern darum, sie so zu bauen, dass ein unsichtbarer Textblock in weißer Schrift eben nicht ausreicht, um Ihre Zahlen, Fristen und Namen zu verändern, ohne dass es jemand bemerkt.
Ein einfaches Gedankenexperiment zeigt, wie schnell aus einer kleinen technischen Lücke ein echter finanzieller Schaden werden kann: Ein Lieferant sendet eine Rechnung über einen vierstelligen Betrag. Ihr E-Mail-Agent fasst sie zusammen und trägt die Zahlungsfrist automatisch in Ihr Kalender- oder Buchhaltungssystem ein. Enthält die Mail einen versteckten Textblock nach dem Forcepoint-Muster, könnte die KI-Zusammenfassung einen deutlich höheren Betrag und eine falsche, unter Umständen früher liegende Frist ausgeben – und wenn niemand die Originalmail gegenprüft, weil man sich ja auf die Automatisierung verlässt, wird genau dieser falsche Betrag angewiesen oder zumindest als Grundlage für interne Freigabeprozesse genutzt. Der Aufwand für den Angreifer: eine Zeile CSS. Der potenzielle Schaden für Sie: ein finanzieller Fehlbetrag, eine verpasste echte Frist oder eine Zahlung an die falsche Adresse.
Sie möchten wissen, ob Ihre bestehenden KI-Workflows gegen Prompt-Injection-Angriffe wie diesen abgesichert sind? Wir analysieren Ihre Agenten-Architektur und zeigen konkrete Guardrails auf.
Sicherheits-Check buchenDer Forcepoint-Fund ist letztlich kein Grund, KI-Agenten in E-Mail- und Dokumentenprozessen zu meiden. Er ist ein Grund, sie von Anfang an mit der richtigen Architektur zu bauen: klare Trennung von Inhalt und Anweisung, saubere Filterung vor der Modellübergabe und menschliche Kontrollpunkte genau dort, wo es um Geld, Fristen und rechtlich bindende Zusagen geht. Genau das ist der Unterschied zwischen einer KI-Automatisierung „von der Stange", die blind jedem Text vertraut, der bei ihr ankommt, und einem professionell aufgesetzten Agenten-System, das strukturell weiß, wem es vertrauen darf – und wem nicht.