Copilot legte den eigenen Schutzmechanismus offen
Eine kritische Schwachstelle in Microsoft 365 Copilot Enterprise ermöglichte den Zugriff auf sensible Daten nach nur einem Klick. Sicherheitsforscher konnten präparierte Links erstellen, die Prompts automatisch im Kontext einer bereits angemeldeten Sitzung ausführten.
Bemerkenswert ist der Weg zur Schwachstelle. Das Sprachmodell selbst gab schrittweise Details über seine internen Schutzmechanismen preis. Auf wiederholte Fragen erklärte Copilot unter anderem, welche URL-Strukturen verwendet werden und warum bestimmte Befehle eine ausdrückliche Bestätigung erfordern.
Schließlich nannte das System den undokumentierten Parameter ?autorun=1. In Verbindung mit dem bereits bekannten Parameter ?q= ließ sich ein Prompt beim Laden der Seite automatisch starten.
Ein Klick auf eine legitime Copilot-Adresse durfte nicht genügen, um einen Prompt im angemeldeten Kontext auszuführen. Der undokumentierte Parameter setzte genau diese Vertrauensgrenze außer Kraft.
So funktionierte der One-Click-Angriff
Copilot kann Prompts aus einer URL übernehmen. Diese Funktion ist unter anderem für Verknüpfungen mit Browser-Erweiterungen und verbundenen Anwendungen gedacht. Normalerweise muss eine Benutzergeste folgen, beispielsweise das Bestätigen einer Eingabe.
Der Autorun-Parameter umging diese Hürde. Nach dem Klick auf den Link arbeitete Copilot den eingebetteten Prompt mit den Berechtigungen der aktiven Sitzung ab. Dazu gehörte auch der Zugriff auf verbundene Anwendungen, den Copilot-Speicher und freigegebene Postfachinhalte.
| Schritt | Vorgang | Risiko |
|---|---|---|
| 1 | Ein präparierter Link wird per E-Mail, Chat, Webseite oder QR-Code geöffnet | Die Adresse verweist auf die legitime Copilot-Domain |
| 2 | Der Browser verwendet die aktive Microsoft-Sitzung | Eine erneute Anmeldung ist nicht erforderlich |
| 3 | ?autorun=1 startet den über ?q= eingefügten Prompt | Die vorgesehene Bestätigung entfällt |
| 4 | Copilot durchsucht freigegebene Datenquellen | E-Mails, Zugangsdaten und gespeicherte Informationen können verarbeitet werden |
| 5 | Die Ergebnisse werden an eine externe Adresse übertragen | Sensible Daten verlassen die Microsoft-Umgebung |
In einem demonstrierten Szenario suchte Copilot nach der neuesten E-Mail-Adresse im Postfach und fügte sie in eine vom Angreifer kontrollierte URL ein. Ein weiterer Prompt suchte gezielt nach Passwörtern und anderen Zugangsdaten.
Die Informationen wurden vor der Übertragung in Base64 umgewandelt. Das ist lediglich eine Kodierung und keine Verschlüsselung. Sie kann Daten in URLs weniger auffällig machen, bietet aber keinen Schutz vor Einsicht.
Manipulierte Webseiten konnten den Speicher vergiften
Die Forscher beschrieben zusätzlich eine Prompt-Injection gegen den dauerhaften Copilot-Speicher. Bei einer Prompt-Injection werden versteckte Anweisungen in fremden Inhalten platziert, damit ein KI-System sie wie legitime Befehle behandelt.
Beim Zusammenfassen einer präparierten Webseite konnte Copilot Anweisungen aus deren Metadaten übernehmen. Diese Anweisungen ließen sich als vermeintliche Präferenzen oder Regeln im Speicher des Nutzers hinterlegen.
Solche manipulierten Erinnerungen können spätere Antworten filtern, Inhalte in eine bestimmte Richtung lenken oder Aktionen bei festgelegten Bedingungen auslösen. Besonders problematisch ist die Beständigkeit. Die Einträge blieben nach Passwortänderungen, dem Widerruf von Sitzungen und einer erneuten Geräteanmeldung erhalten.
Damit entsteht eine Angriffsebene, die mit klassischen Maßnahmen des Access Managements nur teilweise erfasst wird. Eine manuelle Kontrolle des KI-Speichers kann erforderlich sein, selbst wenn Konten und Sitzungen bereits zurückgesetzt wurden.
Microsoft hat die URL-Ausführung eingeschränkt
Microsoft schloss die erste Angriffsmöglichkeit im Februar 2026, rund drei Monate nach der Meldung. Der Parameter ?q= durfte danach keinen Text mehr direkt in das Eingabefeld übertragen. Nutzer mussten wieder selbst klicken und Text eingeben.
Diese Änderung beeinträchtigte allerdings auch Browser-Integrationen, die den Parameter für legitime Abläufe verwendeten. Im August 2026 folgten umfassendere Korrekturen. Welche zusätzlichen Schutzschichten dabei verändert wurden, ist nicht im Detail offengelegt.
Der Fall ergänzt eine Reihe von Sicherheitsproblemen rund um KI-Assistenten. So hatte eine kritische Snowflake-Lücke mit GitHub Copilot gezeigt, dass KI-gestützte Prüfungen keine verlässliche Sicherheitskontrolle ersetzen. Auch auslesbare KI-Denkblöcke mit offengelegten API-Schlüsseln verdeutlichen, wie schnell interne Modellinformationen zu einem praktischen Risiko werden.
Was Unternehmen jetzt prüfen sollten
Für Unternehmen im DACH-Raum ist vor allem die Kombination aus weitreichenden Zugriffsrechten und automatischer Ausführung relevant. Wenn Copilot auf E-Mail, Dateien, Kalender und weitere Geschäftsanwendungen zugreifen darf, vergrößert jeder zusätzliche Connector den möglichen Schaden.
Nicht benötigte Integrationen sollten deaktiviert und Berechtigungen nach dem Prinzip der geringsten Rechte vergeben werden. Zudem sollten ausgehende Netzwerkzugriffe, ungewöhnliche Copilot-Aktivitäten und Änderungen am dauerhaften Speicher überwacht werden.
Auch technische Schutzmechanismen gegen gefährliche Werkzeugaufrufe gewinnen an Bedeutung. Ansätze wie AWS Dogwood gegen falsche Tool-Aufrufe zeigen, dass Anbieter dafür zusätzliche Kontrollschichten entwickeln. Solche Systeme reduzieren Risiken, beseitigen aber nicht die grundsätzliche Abhängigkeit von den Sicherheitsregeln des jeweiligen Plattformbetreibers.
Der Vorfall macht außerdem deutlich, warum die Freigabe eines KI-Assistenten nicht mit der Einführung eines gewöhnlichen SaaS-Werkzeugs gleichzusetzen ist. Ein Assistent mit Zugriff auf mehrere Systeme bündelt Berechtigungen und kann Aktionen selbstständig verketten. Datenschutz, Protokollierung und regelmäßige Rechteprüfungen müssen deshalb bereits vor dem breiten Einsatz geklärt sein.