Ein Unternehmen erhält eine Marktanalyse als Word-Dokument, nutzt sie als Quelle für einen Quartalsbericht und lässt Microsoft 365 Copilot beim Entwurf helfen. Für den Nutzer sieht der Vorgang nach normaler Büroarbeit aus: Quellen auswählen, Bericht generieren, Ergebnis prüfen, intern weitergeben. Genau in diesem Alltagsszenario liegt das Sicherheitsproblem, das der Forscher Håkon Måløy am 28. Juli öffentlich beschrieben hat. Versteckte Anweisungen in einem Word-Dokument können Copilot dazu bringen, Inhalte eines neuen Dokuments zu verändern und dieselben Anweisungen in die erzeugte Datei zu kopieren. Wird diese Datei später erneut als Quelle für Copilot verwendet, kann sich der Effekt fortsetzen.
Das ist kein klassischer Makrovirus, keine Zero-Click-Malware und kein Beleg für massenhafte Ausnutzung. Es ist aber ein sehr praktisches Beispiel dafür, warum KI-Assistenten in Office-Workflows nicht nur Datenschutz-, sondern Integritätsrisiken erzeugen. Der kritische Punkt ist nicht, dass ein Modell „böse“ wird. Der kritische Punkt ist, dass untrusted Content, Nutzerabsicht und produktive Dokumentenerzeugung im selben Kontextfenster landen.
Was technisch passiert
Måløys Bericht „Context Collapse, Part 3 – AI Worming through Word“ ist Teil einer koordinierten Offenlegung mit Microsofts Security Response Center. Nach seinen Angaben erhielt Microsoft Reproduktionsschritte, Videos, Umgebungsannahmen und die exakten Proof-of-Concept-Prompts. Die Koordination dauerte 144 Tage. Microsoft blockierte die ursprünglichen Payloads und nahm weitere Mitigations vor, darunter eine Modellaktualisierung. Måløy schreibt jedoch, dass die breitere Angriffsklasse zum Zeitpunkt der Veröffentlichung mit veränderten Instruktionen weiterhin reproduzierbar blieb.
Der Einstieg ist banal: Ein Angreifer platziert Anweisungen in einem Word-Dokument, zum Beispiel als weiße Schrift auf weißem Hintergrund und in kleiner Schriftgröße. Für den menschlichen Leser ist der Text praktisch unsichtbar. Copilot verarbeitet den Dokumenttext jedoch ohne dieselbe visuelle Wahrnehmung; laut Forschungsbericht werden Formatierungen wie Farbe und Schriftgröße vor der Übergabe an das Sprachmodell entfernt. Damit wird der versteckte Text für das Modell lesbar.
Wenn das Dokument in Copilots Kontext gelangt, etwa weil der Nutzer es als Quelle anhängt oder weil Copilot über Work-IQ-/OneDrive-Kontext relevante Dateien findet, kann das Modell die eingebetteten Anweisungen als Teil der Arbeitsaufgabe interpretieren. In Måløys Demonstration wurden Finanzzahlen in einem Bericht halbiert. Gleichzeitig kopierte Copilot den vollständigen versteckten Prompt an das Ende des neu erzeugten Dokuments, wiederum unsichtbar formatiert. Aus der initialen externen Datei wurde so ein intern erzeugter Träger.
Die zweite Stufe ist entscheidend. Wird dieser scheinbar legitime interne Bericht später als Quelle für einen weiteren Copilot-Entwurf verwendet, ist das ursprüngliche Angreifer-Dokument nicht mehr nötig. Der kopierte Prompt steckt bereits im internen Dokument. In der Demonstration veränderte Copilot erneut Zahlen und kopierte die Anweisung weiter. Das Verhalten ist deshalb „wurmähnlich“, aber nicht autonom: Jede Weitergabe braucht eine weitere Copilot-Drafting- oder Editieroperation, in der ein infiziertes Dokument in den Modellkontext gelangt.
Warum das für Unternehmen relevant ist
Microsoft beschreibt Copilot in Word ausdrücklich als Werkzeug, das Entwürfe auf Basis bestehender Dateien, E-Mails oder Meetings erstellen kann. Die Support-Dokumentation empfiehlt sogar, vorhandene Dokumente als Quellen zu referenzieren; Nutzer sollen erzeugte Inhalte anschließend prüfen und anpassen. Das ist aus Produktsicht sinnvoll, macht aber die Sicherheitsgrenze kompliziert. Ein Quellendokument enthält eigentlich Daten, keine Befehle. Ein LLM verarbeitet beides jedoch als Token im selben Berechnungskontext.
Genau hier entsteht der Architekturkonflikt. In klassischen Office-Sicherheitsmodellen waren gefährliche Dokumente vor allem Makros, eingebettete Objekte, Links oder Exploits gegen Parser. Hier besteht das Risiko in der Semantik des Inhalts. Ein scheinbarer Absatz kann für Menschen uninteressant, für den Assistenten aber eine operative Anweisung sein. Noch schwieriger: Sobald Copilot die Anweisung in ein intern erzeugtes Dokument kopiert, verschwindet die klare Herkunft. Der neue Träger stammt aus einem legitimen Workflow, möglicherweise von einem vertrauenswürdigen Kollegen oder Partner.
The Hacker News berichtete am 30. Juli über dieselbe Offenlegung und bestätigte zentrale Details: Microsoft habe das Verhalten am 31. März bestätigt, zwei Mitigations deployed und die zugrunde liegenden Modelle aktualisiert; eine öffentliche CVE oder eigenständige Microsoft-Advisory war in den gängigen Datenbanken und im Security Update Guide nicht auffindbar. CyberInsider ordnete die Technik ebenfalls als selbstverbreitende, dokumentgebundene Prompt-Injection ein. Wichtig ist die nüchterne Lesart: Es gibt keinen Hinweis auf Ausnutzung in freier Wildbahn, und der vollständige Payload wurde nicht veröffentlicht.
Konkrete Implikationen für Sicherheitsprogramme
Erstens müssen Unternehmen Office-Copilots als Teil der Angriffskette modellieren, nicht als reine Produktivitätsfunktion. Wer darf Copilot mit externen Dokumenten verwenden? Welche Dateitypen, SharePoint-Sites, Teams-Kanäle und OneDrive-Bereiche können als Quellen dienen? Welche Abteilungen erzeugen kritische Dokumente wie Finanzberichte, Verträge, Angebotsunterlagen, regulatorische Nachweise oder Vorstandsunterlagen mithilfe von KI?
Zweitens reicht „Nutzer sollen prüfen“ allein nicht aus. Måløys Demonstration zielt gerade darauf, subtile Änderungen zu erzeugen, die in normalen Review-Prozessen leicht übersehen werden. Für sensitive Dokumentklassen braucht es deterministischere Kontrollen: Versionsvergleiche, Quellenprovenienz, Änderungsmarkierungen, Vier-Augen-Prüfung bei Zahlen und Rechtsformulierungen, sowie klare Regeln, wann externe Quellen nicht direkt in generative Workflows übernommen werden dürfen.
Drittens sollten Unternehmen Prompt-Injection-Schutz an mehreren Schichten betrachten. Microsoft Defender for Office 365 beschreibt Prompt-Injection-Erkennung für eingehende E-Mails als Teil der Mail-Flow-Inspektion und verweist auf zusätzliche Copilot-Safeguards wie Input-Filtering, Prompt-Design, Grounding-Grenzen und Output-Filter. Solche Kontrollen sind sinnvoll, aber sie lösen das Grundproblem nicht vollständig: Ein Filter muss untrusted Content interpretieren, bevor er entscheiden kann, ob dieser Content eine schädliche Instruktion enthält.
Viertens wird Dokumentenprovenienz wichtiger. Generated-by-AI-Metadaten allein helfen wenig, wenn nicht nachvollziehbar ist, welche Quellen ein Dokument beeinflusst haben und welche Passagen durch Copilot verändert wurden. Für Enterprise-Workflows wäre eine robuste, maschinenlesbare Herkunftskette hilfreich: verwendete Quelldokumente, Zeitpunkt, Nutzer, Copilot-Funktion, erkannte externe Quellen, und idealerweise sichtbare oder auditierbare Modelländerungen. Das ist keine perfekte Prävention, aber es verbessert Erkennung und Incident Response erheblich.
Risiken und Grenzen der Einordnung
Der Fall sollte nicht überdramatisiert werden. Die beschriebene Kette benötigt Nutzerinteraktion oder zumindest eine produktive Copilot-Operation. Sie führt nicht automatisch zu Codeausführung, lateraler Bewegung oder Datenabfluss. Sie ist außerdem abhängig davon, dass ein manipuliertes Dokument tatsächlich in den relevanten Kontext gelangt und die formulierten Anweisungen vom jeweiligen Modell und den aktuellen Schutzmechanismen akzeptiert werden.
Gleichzeitig wäre es falsch, den Fall als Labor-Kuriosität abzutun. Office-Dokumente sind in Unternehmen extrem vertrauensbildend: Sie wandern durch E-Mail, Teams, SharePoint, Kundenportale, Anwaltskanzleien, Beratungshäuser und Lieferantenketten. Wenn KI-Assistenten solche Dokumente nicht nur lesen, sondern daraus neue interne Unterlagen erzeugen, wird Integrität zum zentralen Sicherheitsziel. Ein manipulierter Bericht, eine verzerrte Zusammenfassung oder eine unbemerkt veränderte Vertragsklausel kann geschäftlich relevanter sein als ein blockierter Malware-Anhang.
Fazit
Copilot for Word zeigt ein Muster, das über Microsoft hinausgeht: KI-Assistenten brauchen Kontext, aber Kontext ist nicht automatisch vertrauenswürdig. Sobald externe Inhalte, interne Dokumente und Handlungsabsicht im selben Modellkontext verschmelzen, entsteht eine neue Sicherheitsgrenze. Unternehmen sollten deshalb nicht nur fragen, ob ein Copilot Daten lesen darf, sondern ob die Herkunft und Integrität dieser Daten kontrollierbar bleiben, wenn daraus neue Dokumente entstehen.
Die praktische Konsequenz ist kein pauschales Copilot-Verbot. Sinnvoller ist eine risikobasierte Einführung: externe Dokumente als untrusted behandeln, kritische Dokumentklassen besonders schützen, Quellen- und Änderungsprovenienz verlangen, Review-Prozesse für Zahlen und rechtliche Aussagen verschärfen und Prompt-Injection nicht als reines Modellproblem behandeln. In der KI-Office-Welt ist das Dokument selbst wieder ein aktiver Teil der Angriffsfläche.
Quellen: Håkon Måløy, „Context Collapse, Part 3 – AI Worming through Word“, 28. Juli 2026; The Hacker News, „Microsoft Copilot for Word Can Copy Hidden Prompts Into New Documents“, 30. Juli 2026; CyberInsider, „Microsoft Copilot for Word vulnerable to self-propagating worm-like attack“, 30. Juli 2026; Microsoft Support, „Draft and add content with Copilot in Word“; Microsoft Learn, „Prompt injection protection in Microsoft Defender for Office 365“.
