Rechnungsbetrug: Prompt Injection in E-Mails

Rechnungs-E-Mails können Anweisungen enthalten, die ein Mensch beim Lesen nicht sieht, ein KI-Agent aber verarbeitet. Wenn der Agent daraus eine Weiterleitung oder einen anderen Arbeitsschritt ableitet, wird fremder Nachrichteninhalt zur Handlungsanweisung. Gegen diesen Übergang braucht es Kontrollen vor der Ausführung.

Kurz gesagt

• Eine neue Kampagne verbindet Rechnungsbetrug mit versteckten Anweisungen an E-Mail-Agenten.
• Menschliche Ansicht, extrahierter Text und Modelleingabe können sich unterscheiden.
• Die beobachteten Nachrichten belegen einen Angriffsversuch, keine erfolgreiche Zahlung.

Stand der Quellen- und Produktprüfung: 27. Oktober 2026.

Was Sublime beobachtet hat

Sublime beschreibt am 26. Oktober eine am 22. Oktober 2026 erkannte Kampagne. Rechnungsnachrichten enthielten eine in HTML und Unicode-Tag-Zeichen versteckte Aufforderung, die E-Mail samt PDF weiterzuleiten. Sublimes Modellversuche lieferten unterschiedliche Reaktionen. Ein erfolgreicher Zahlungsablauf ist nicht belegt. Originalbericht

Das PDF ist hier Teil des gewünschten Weiterleitungsvorgangs. Daraus folgt nicht, dass die Injection im PDF steckte. Diese Unterscheidung ist wichtig: Eine Pipeline, die ausschließlich Anhänge prüft, untersucht womöglich den falschen Teil der Nachricht. Unser Beitrag zu Prompt Injection in PDFs behandelt einen anderen Eingabekanal.

Warum Mensch und Agent verschiedene Nachrichten lesen

HTML kann Text enthalten, den die Darstellung verbirgt. Ein Extraktor, der Texte aus dem Quellcode übernimmt, kann ihn trotzdem weiterreichen. Ein Extraktor, der nur die gerenderte Ansicht berücksichtigt, kann ihn dagegen verwerfen. Welche Variante deine Anwendung verwendet, musst du an ihrer tatsächlichen Ausgabe prüfen.

Unicode-Tag-Zeichen sind eine weitere Ebene. Der Unicode-Standard beschreibt sie als besondere Formatzeichen und unterscheidet den Zeichenblock von seiner inzwischen veralteten Verwendung zur Sprachkennzeichnung. Sie sind keine gewöhnlichen Leerzeichen. Unicode, Kapitel 23.9

Sublime erläutert in einem früheren Bericht vom 14. Oktober, wie solche Zeichen unsichtbare Informationen tragen können. Microsoft beschrieb am 3. September außerdem ihren Einsatz zur Verschleierung von Phishing-Inhalten. Eine Injection und eine verschleierte Phishing-Nachricht können sich technisch ähneln, verfolgen aber unterschiedliche Ziele. Sublime zur Unicode-Technik, Microsoft zu ASCII Smuggling

Eine automatische Unicode-Normalisierung ist deshalb kein ausreichender Nachweis, dass der Text unbedenklich ist. Lass dir bei einem Test die Codepoints und die verschiedenen Verarbeitungsschritte anzeigen. So kannst du feststellen, ob eine Anweisung entfernt, erhalten oder erst durch eine Dekodierung lesbar wird.

Wie aus einer Rechnung ein zusätzlicher Auftrag wird

Ein erfundenes Beispiel: Du beauftragst deinen Assistenten, neue Rechnungen zusammenzufassen. Eine Nachricht enthält zusätzlich einen an das Assistenzsystem gerichteten Absatz, der das Weiterleiten des Anhangs an eine bestimmte Adresse verlangt.

Die Zusammenfassung kann weiterhin korrekt aussehen. Der Fehler entsteht, wenn der Assistent auch die Weiterleitung anstößt. Der Absender durfte eine Rechnung einreichen. Daraus ergibt sich keine Berechtigung, deinen Assistenten mit zusätzlichen Aktionen zu beauftragen.

Auch die Adresse löst das Problem nicht. Ein interner Empfänger kann Teil eines unerwünschten Vorgangs sein. Die Frage lautet daher: Ist genau diese Aktion durch deinen Auftrag und die Regeln der Anwendung gedeckt? Eine bloße Prüfung auf die eigene Unternehmensdomain beantwortet das nicht.

Welche Kontrollen an welcher Stelle helfen

Für einen solchen Rechnungsworkflow würden wir die Prüfung in fünf Schritte teilen:

1. Nachricht nachvollziehbar zerlegen. Bewahre Rohdaten auf und kennzeichne, welche Teile aus Betreff, Text, HTML oder Anhang stammen. Die Analyse darf diese Herkunft nicht durch bloßes Zusammenkopieren verlieren.
2. Die tatsächliche Modelleingabe prüfen. Vergleiche gerenderte Ansicht, extrahierten Text und gegebenenfalls eine gesonderte dekodierte Ansicht. Markiere dabei weiter, dass der Inhalt von außen kommt. Eine dekodierte Anweisung erhält keine zusätzliche Autorität.
3. Auffällige Inhalte behandeln. Lege fest, wann eine Nachricht zurückgehalten oder manuell geprüft wird. Ein unsichtbares Formatzeichen kann ein Hinweis sein, ist aber für sich noch kein Beweis für eine Injection.
4. Zusammenfassen und Handeln trennen. Ein lesender Auftrag benötigt keine automatische Versand- oder Zahlungsberechtigung. Ein geplanter Versand wartet auf die Prüfung von Auftrag, Empfänger und konkretem Anhang.
5. Die Wirkung kontrollieren. Teste, ob eine unzulässige Aktion tatsächlich ausbleibt. Ein Alarm nach dem Versand macht die Weitergabe nicht rückgängig.

Wie du solche Freigaben und Fehlerpfade festlegst, behandeln wir ausführlicher unter Freigeben, Blockieren und Weiterprüfen.

Welche Gegenbeispiele in einen Test gehören

Ein Testset braucht auch harmlose E-Mails mit komplexem HTML, legitime Rechnungsweiterleitungen und Sicherheitsschulungen, die einen Angriff erklären. Sonst lernt ein Detektor möglicherweise nur, jede unsichtbare Passage oder das Wort „weiterleiten“ verdächtig zu finden.

Für einen kontrollierten Test kannst du zwei eigene Nachrichten mit derselben Rechnungshülle erstellen: eine mit harmlosen Zusatzinformationen und eine mit einer Anweisung, die den Assistenten vom Auftrag abbringen soll. Prüfe danach jede Verarbeitungsansicht separat. Wenn die Extraktion die Anweisung vollständig entfernt hat, enthält der ausgegebene Text diese Injection nicht mehr. Die ursprüngliche E-Mail und die bereinigte Eingabe brauchen dann unterschiedliche Bewertungen.

Ein Textdetektor beantwortet dabei eine andere Frage als ein vollständiger Workflow-Test. Ob eine Weiterleitung autorisiert ist, kann zusätzlich vertrauenswürdigen Auftragskontext erfordern. Und ob der Agent die Anweisung tatsächlich befolgt, muss am Ausführungsergebnis geprüft werden.

Wo Wolf Defender und die Scanner API passen

Wolf Defender Small ist ein kostenlos verfügbares Modell zur Erkennung von Prompt Injection in einzelnen Texteingaben. Die Patronus Scanner API bietet einen kostenlosen Einstieg in die Inhaltsprüfung.

Für die hier beschriebenen Nachrichten haben wir keine eigene Erkennungsrate gemessen. Welche Wirkung eine Prüfung hat, hängt auch davon ab, welche Darstellung sie erhält. Ein Textscore ersetzt keine Kontrolle von Versand- oder Zahlungsberechtigungen und belegt keinen Schutz über mehrere Chats.

Quellen

1. Sublime Security: Invoice fraud campaign adds prompt injection aimed at email AI agents, 26. Oktober 2026.
2. Sublime Security: Hiding attacks in plain sight with invisible Unicode tag characters, 14. Oktober 2026.
3. Microsoft: ASCII smuggling crosses over from AI prompt injection to phishing evasion, 3. September 2026.
4. Unicode Consortium: Unicode 17.0, Kapitel 23.9: Tag Characters, geprüft am 27. Oktober 2026.

Hinweise auf sachliche Fehler nehmen wir über unsere Kontaktseite entgegen.