Ein Link macht Microsoft-365-Copilot zum Datenleck

Ein einziger Klick auf einen präparierten Link reichte, damit Microsoft 365 Copilot E-Mails, Kalendereinträge und sogar Einmalcodes für die Mehr-Faktor-Anmeldung nach außen durchreichte. Die Schwachstelle, von ihren Entdeckern bei Varonis Threat Labs „SearchLeak“ getauft und als CVE-2026-42824 mit Microsofts höchster Schweregradstufe geführt, begann mit einer Parameter-Injection: einem manipulierten Wert in der URL, der dem Assistenten heimlich Anweisungen unterschob. Microsoft hat die Lücke Anfang Juni serverseitig geschlossen, ein Eingreifen der Anwender war nicht nötig. Das eigentliche Problem bleibt trotzdem auf dem Tisch, denn der Angriffsweg steht KI-Assistenten offen, die breiten Suchzugriff auf Unternehmensdaten mit unsauberer Ausgabe- und Egress-Kontrolle verbinden.

Verwandt:Copilot findet die Datei, die niemand teilen wollte  /  Die Schwachstelle, die nur die KI gefunden hat

Wie aus einem Link ein Datenabfluss wird

SearchLeak bestand aus einer Kette von drei Schwächen, die erst zusammen gefährlich wurden. Am Anfang stand die Parameter-Injection: Über den Suchparameter in der URL ließ sich Copilot ein Stück Text unterschieben, das der Assistent nicht als Nutzereingabe, sondern als Anweisung behandelte. Aus einem harmlosen Link wurde so ein verdeckter Befehl.

Den zweiten Baustein lieferte eine zeitliche Lücke beim Aufbau der Antwortseite. Ein vom Angreifer eingeschleustes Bild-Element wurde geladen, bevor die Ausgabe vollständig bereinigt war. Der dritte Baustein nutzte eine serverseitige Anfrage über einen Bing-Dienst, die die abgegriffenen Daten an der Content-Security-Policy der Seite vorbeischleuste. Das Ergebnis: ein einziger Klick. Inhalte aus der Copilot-Suche im Unternehmen wanderten unbemerkt nach außen, von Mailtexten mit Zugangsdaten über Kalenderdetails bis zu Dokumenten.

Gefährlich macht die Kette ihre Unauffälligkeit. Jedes Glied für sich wirkt harmlos: ein Suchparameter ist Alltag, ein nachladendes Bild ebenso, eine Anfrage an einen Microsoft-eigenen Dienst erst recht. Erst die Verkettung formt daraus einen Exfiltrationspfad, der ohne Schadsoftware, ohne Anhang und ohne zweite Nutzeraktion auskommt. Für das Opfer sah der Vorgang aus wie eine normale Copilot-Antwort, während im Hintergrund die Daten bereits unterwegs waren. Genau diese Tarnung erklärt, warum klassische Abwehr an dem Angriff vorbeigreift: Es gibt weder eine verdächtige Datei, die ein Virenscanner fassen könnte, noch einen offensichtlich bösartigen Absender, an dem ein Spamfilter ansetzt.

Warum der Fix das Grundproblem nicht löst

Varonis meldete die Kette an Microsoft, veröffentlichte einen Machbarkeitsnachweis und fand zum Zeitpunkt der Offenlegung keine Hinweise auf eine Ausnutzung im Feld. Microsoft entschärfte SearchLeak Anfang Juni serverseitig. Für die betroffenen Unternehmen heißt das: kein Client-Patch, keine Nutzeraktion, die akute Gefahr ist weg.

Die Erleichterung trügt aber, wenn sie als Schlusspunkt gelesen wird. SearchLeak ist ein Beispiel für eine ganze Angriffsklasse, bei der ein KI-Assistent mit weitem Zugriff auf Unternehmensdaten zum Hebel wird. Ein gekaperter Assistent erreicht alles, worauf der angemeldete Nutzer Zugriff hat. Genau dieser Radius lässt sich missbrauchen. Vergleichbare Funde sind absehbar, solange Assistenten diesen breiten Zugriff behalten.

Der Kern des Problems liegt im Vertrauensmodell. Copilot Enterprise Search ist bewusst so gebaut, dass er im Namen des Nutzers auf dessen gesamten Datenbestand zugreift, über Postfächer, Kalender, SharePoint und OneDrive hinweg. Das ist sein Nutzen und zugleich seine Angriffsfläche. Wer den Assistenten zu einer Handlung verleitet, handelt mit dessen Rechten, die weit reichen. Parameter- und Prompt-Injection sind dabei keine exotischen Tricks, sondern die logische Folge daraus, dass ein und dieselbe Eingabe für die Maschine sowohl Inhalt als auch Anweisung sein kann. Solange diese Grenze unscharf bleibt, bleibt die Angriffsklasse bestehen, gleichgültig wie sauber ein einzelner Fund geschlossen wird. Das verschiebt die Aufgabe von der Jagd nach der einzelnen Lücke hin zur Frage, wie viel Schaden ein missbrauchter Assistent im Ernstfall überhaupt anrichten kann.

Was Security-Teams jetzt härten sollten

Die sinnvolle Reaktion ist nicht, Copilot abzuschalten, sondern den möglichen Schaden klein zu halten, falls die nächste Lücke auftaucht. Vier Stellschrauben sind dafür entscheidend.

Berechtigungen eng führen. Copilot Enterprise Search erbt die Zugriffsrechte des Nutzers. Wer großzügig geteilte Ablagen und verwaiste Berechtigungen aufräumt, verkleinert den Radius, den ein gekaperter Assistent überhaupt erreichen kann. Das ist die wirksamste und am häufigsten vernachlässigte Maßnahme. In der Praxis heißt das, überbreite SharePoint- und OneDrive-Freigaben, offene Jeder-im-Unternehmen-Links und Altrechte aus abgeschlossenen Projekten systematisch zu prüfen. Je weniger ein durchschnittliches Konto sehen darf, desto kleiner ist der Schaden, wenn genau dieses Konto über den Assistenten missbraucht wird. Das Prinzip ist nicht neu, durch Copilot bekommt es nur einen unmittelbaren Hebel.

Den Datenabfluss überwachen. SearchLeak schleuste Daten über einen externen Dienst aus. Egress-Kontrolle und Data-Loss-Prevention, die ungewöhnliche Abflüsse aus dem Microsoft-365-Umfeld erkennen, adressieren genau dieses letzte Glied der Kette. Microsoft Purview Data Loss Prevention und Defender for Cloud Apps lassen sich so einstellen, dass sensible Inhalte beim Abfluss markiert oder blockiert werden, auch wenn der Weg nach außen über einen scheinbar harmlosen Bild- oder Dienstaufruf läuft. Entscheidend ist, dass die Regeln nicht nur Mailanhänge und offensichtliche Uploads erfassen, sondern auch die unauffälligen Kanäle, über die ein solcher Angriff arbeitet.

Assistenten-Aktivität protokollieren. Wer nicht aufzeichnet, welche Inhalte Copilot abruft und welche externen Ziele dabei kontaktiert werden, sieht einen solchen Abfluss erst, wenn er Schaden angerichtet hat. Logging der KI-Interaktionen gehört auf dieselbe Stufe wie das Protokollieren privilegierter Zugriffe. Das Microsoft-365-Audit-Log und Purview erfassen Copilot-Vorgänge, sofern die Protokollierung aktiviert und regelmäßig ausgewertet wird. Ohne diese Auswertung bleibt ein Vorfall unsichtbar, bis er an anderer Stelle auffällt. Dann fehlt die Spur, um den Umfang zu rekonstruieren.

KI-Links als Angriffsfläche begreifen. Ein Link, der einen Assistenten steuert, ist gefährlicher als ein klassischer Phishing-Link, weil er im Namen des Nutzers auf dessen Daten zugreift. Awareness-Programme sollten diesen neuen Vektor benennen, statt nur vor gefälschten Login-Seiten zu warnen. Mitarbeitende lernen seit Jahren, verdächtige Absender und nachgebaute Anmeldemasken zu erkennen. Ein Link, der intern auf ein vertrautes Microsoft-Werkzeug zeigt, fällt durch dieses Raster, weil er weder fremd noch gefälscht aussieht. Die Schulung muss den Unterschied vermitteln: Auch ein harmlos wirkender Link kann einen Assistenten zu Aktionen bewegen, die der Nutzer nie beabsichtigt hat.

Häufige Fragen

Jede Frage ist verschlossen. Ein Tippen entriegelt die Antwort.

Was ist SearchLeak genau?

SearchLeak ist eine von Varonis Threat Labs entdeckte Schwachstelle in der Enterprise Search von Microsoft 365 Copilot, geführt als CVE-2026-42824 mit Microsofts höchster Schweregradstufe. Über einen präparierten Link ließen sich in einem Klick Daten aus der Copilot-Suche abgreifen, darunter E-Mails, Kalendereinträge, Dokumente und Einmalcodes.

Was bedeutet Parameter-Injection in diesem Fall?

Ein Angreifer schob über den Suchparameter in der URL einen Text ein, den Copilot als Anweisung statt als Suchanfrage verarbeitete. So ließ sich der Assistent steuern, ohne dass der Nutzer etwas anderes tat als auf einen Link zu klicken.

Muss ich als Microsoft-365-Kunde etwas tun?

Für diese konkrete Lücke nicht. Microsoft hat SearchLeak Anfang Juni serverseitig geschlossen, ein Client-Patch oder eine Aktion der Anwender ist nicht erforderlich. Sinnvoll ist trotzdem, die Copilot-Berechtigungen und die Überwachung zu prüfen, weil die Angriffsklasse bleibt.

Wurde die Lücke aktiv ausgenutzt?

Varonis berichtet, zum Zeitpunkt der Offenlegung keine Hinweise auf eine Ausnutzung im Feld gefunden zu haben. Veröffentlicht wurde ein Machbarkeitsnachweis, kein Hinweis auf einen realen Angriff. Das entlastet rückblickend, sagt aber nichts über künftige Funde derselben Art.

Welche Lehre zieht ein Security-Team daraus?

Dass die Sicherheit eines KI-Assistenten an seinem Datenzugriff hängt. Enge Berechtigungen, Egress-Kontrolle, Protokollierung der Assistenten-Aktivität und Awareness für KI-gesteuerte Links begrenzen den Schaden, wenn die nächste Lücke dieser Klasse auftaucht.

Lesetipps der Redaktion

LesetippCopilot Cowork handelt allein, das SOC sieht es nichtLesetippSecurity Awareness: die Klickrate misst das FalscheLesetippDer Notfallplan, den niemand geprobt hat

Mehr aus dem MBF Media Netzwerk

cloudmagazinNIS2 und DORA sauber trennen: Compliance-Cluster in KubernetesMyBusinessFutureWenn der Agent die Eingangsrechnung selbst buchtDigital ChiefsJeder baut jetzt KI-Agenten. Wer kontrolliert sie?