Der neue SearchLeak-Fall rund um Microsoft 365 Copilot ist mehr als ein weiterer Sicherheitsbericht über KI. Er zeigt sehr konkret, wie aus einer vermeintlich komfortablen Suchfunktion ein Einfallstor für Datenabfluss werden kann. Laut Varonis reichte in dem beschriebenen Angriff ein einziger Klick auf einen präparierten Link, um vertrauliche Inhalte aus Microsoft-365-Umgebungen anzustoßen und an ein vom Angreifer kontrolliertes Ziel weiterzuleiten. Microsoft hat die Schwachstelle inzwischen unter CVE-2026-42824 behoben. Für Betreiber ist der Fall trotzdem relevant, weil er ein Muster sichtbar macht, das mit KI-gestützten Enterprise-Tools nicht verschwinden wird.
Worum es bei SearchLeak geht
Die Entdeckung stammt von Varonis Threat Labs und wurde am 15. Juni 2026 veröffentlicht. Golem hat den Fall am 16. Juni 2026 aufgegriffen und auf Deutsch eingeordnet. Die Kernaussage ist ernüchternd: In Microsoft 365 Copilot Enterprise Search ließ sich ein Angriffsketten-Szenario bauen, das mit einem harmlos wirkenden Link begann und im Hintergrund mehrere Schutzschichten nacheinander ausnutzte. Der Angriff war nicht deshalb gefährlich, weil ein einzelner exotischer Bug existierte, sondern weil mehrere normalerweise getrennt betrachtete Schwächen zusammenspielten.
Varonis beschreibt drei Stufen: Erstens eine sogenannte Parameter-to-Prompt-Injection, bei der der URL-Parameter für die Suche direkt als Eingabe für Copilot genutzt wurde. Zweitens eine Race Condition beim HTML-Rendering, durch die kurzzeitig gefährliche Markup-Elemente im Browser auftauchen konnten, bevor die Ausgabe vollständig abgesichert war. Drittens ein Umweg über Bing, der die Content-Security-Policy im entscheidenden Moment aushebelte. Zusammengenommen führte das dazu, dass sich sensible Inhalte aus Mails, Kalendern, SharePoint und OneDrive an einen fremden Server spiegeln ließen.
Warum das für IT-Teams so wichtig ist
Der technische Kern ist interessant, aber die betriebliche Bedeutung ist größer. Viele Organisationen betrachten KI-Assistenten noch immer als Produktivitätswerkzeug, nicht als Teil der Sicherheitsarchitektur. Genau diese Trennung ist in der Praxis gefährlich. Sobald ein Assistent interne Inhalte durchsuchen, zusammenfassen oder aufbereiten darf, erweitert sich die Angriffsfläche. Das System hat dann nicht nur Zugriff auf Daten, sondern auch auf Kontexte, Beziehungen und Suchpfade, die sich aus klassischen DLP- oder Endpoint-Szenarien nicht ohne Weiteres ableiten lassen.
SearchLeak ist deshalb ein gutes Beispiel dafür, warum Security-Teams bei KI-Systemen anders denken müssen als bei klassischen Webanwendungen. Der Nutzer klickt auf einen Link, aber der eigentliche Schaden entsteht im Zusammenspiel aus Identität, Suchfunktion, Rendering und erlaubten Zielsystemen. Wer nur auf den Linkfilter schaut, sieht zu wenig. Wer nur auf die App schaut, übersieht den Browserpfad. Wer nur auf das Prompting schaut, übersieht die Infrastruktur dahinter.
Was der Angriff fachlich zeigt
Besonders brisant ist die Kombination aus drei Dingen, die in vielen Reviews getrennt bewertet würden. Die Parameter-to-Prompt-Injection ist ein KI-spezifisches Problem: Benutzereingaben werden nicht nur interpretiert, sondern in Handlungsanweisungen übersetzt. Die HTML-Race-Condition ist ein klassisches Webproblem. Die SSRF- und CSP-Komponente ist ein Infrastruktur- und Plattformproblem. Erst die Kette macht daraus einen realen Datenabfluss.
Genau das ist der Punkt, den viele Teams unterschätzen. Sicherheitskontrollen sind häufig entlang von Zuständigkeiten organisiert. Das Webteam prüft XSS, das Identity-Team prüft Rollen, das Cloud-Team prüft Netzpfade, das AI-Team prüft Prompt Injection. Ein Angreifer braucht diese Grenze nicht zu respektieren. Er kombiniert die Schwächen einfach so, dass jede Einzelkontrolle für sich genommen harmlos aussieht. In Summe entsteht aber ein echter Incident.
Für Betreiber ist daraus eine klare Lehre abzuleiten: KI-gestützte Such- und Assistenzfunktionen müssen wie produktive Systeme mit privilegiertem Datenzugriff behandelt werden. Sie gehören in dieselbe Risikoklasse wie interne Admin-Tools, nicht in die Kategorie "nice to have". Wer Copilot, ähnliche Assistenten oder eigene RAG-Systeme ausrollt, sollte dieselben Fragen stellen wie bei jeder anderen Plattform mit weitreichenden Leserechten: Welche Daten sind erreichbar? Wie werden Ausgaben sanitisiert? Welche externen Ziele dürfen angesprochen werden? Was passiert bei verketteten Fehlern?
Praktische Konsequenzen für den Betrieb
Der Fall liefert eine Reihe sehr konkreter Handlungsimpulse. Erstens sollte der Datenzugriff bei KI-Assistenten grundsätzlich minimal gehalten werden. Nicht jede Suchfunktion braucht das vollständige Postfach, nicht jede Zusammenfassungsfunktion braucht Zugriff auf alle geteilten Bereiche, und nicht jede Ausgabekomponente sollte externe Requests auslösen dürfen. Je weniger Breite ein Assistent hat, desto kleiner wird der mögliche Blast Radius.
Zweitens braucht es härtere Prüfungen für die Ausgabe. Sanitizing ist kein kosmetisches Detail, sondern eine Sicherheitskontrolle. Sobald HTML, Links, eingebettete Bilder oder externe Abrufe im Spiel sind, muss die Pipeline deterministisch sein. Streaming-Ausgaben sind bequem, aber sie erhöhen die Komplexität im Rendering. Genau dort entstehen oft die kleinen Zeitfenster, die ein Angreifer zum Einhaken braucht.
Drittens sollten Security- und Plattform-Teams bei KI-Systemen auf Telemetrie achten, die man bei klassischen Produktivitätswerkzeugen vielleicht nicht priorisiert hätte. Ungewöhnliche Suchmuster, plötzlich auftauchende Bildabrufe, exzessive Weiterleitungen, überraschende Domains oder Kopplungen zwischen Suche und Ausgabedownload sind Warnsignale. Wer die richtigen Logs nicht hat, sieht den Vorfall erst, wenn Daten bereits abfließen.
Viertens bleibt User Awareness wichtig, aber sie ist nicht die Hauptverteidigung. Ein einzelner Klick darf in einem modernen Enterprise-Setup nicht reichen, um vertrauliche Inhalte abfließen zu lassen. Schulung hilft, ersetzt aber keine robuste Architektur. Die bessere Sicherheitsfrage lautet daher nicht: "Wie bringen wir Nutzer dazu, bessere Klickentscheidungen zu treffen?" Sondern: "Wie entwerfen wir Systeme so, dass ein Klick keinen unverhältnismäßigen Schaden anrichten kann?"
Warum der Fall über Microsoft hinausweist
Auch wenn SearchLeak konkret Microsoft 365 Copilot betrifft, ist der Befund allgemeiner. Nahezu jedes Unternehmen, das gerade KI-Suchfunktionen, Agenten, interne Assistenten oder Automatisierungsbrücken einführt, baut damit einen Kontextverstärker. Diese Werkzeuge verknüpfen Identität, Berechtigung, Inhalt und Ausgabe. Genau dadurch sind sie nützlich. Genau dadurch werden sie aber auch risikoreich.
Für FreshCore-Leser ist das besonders anschlussfähig, weil dieselbe Logik aus dem Betrieb bekannt ist. Monitoring, Heartbeats, DNS, Statusseiten und Notifications sind erst dann nützlich, wenn der Pfad zwischen Signal und Aktion sauber kontrolliert ist. KI-Systeme folgen demselben Prinzip, nur mit deutlich mehr semantischer Komplexität. Ein falscher Alert ist lästig. Ein falsch verarbeiteter interner Kontext in einem Assistenten kann vertrauliche Daten preisgeben. Das ist eine andere Größenordnung.
Einordnung für Security- und DevOps-Teams
Der wichtigste praktische Schritt ist deshalb nicht Panik, sondern Systematik. Teams sollten ihre KI-Integrationen wie jede andere sicherheitskritische Komponente inventarisieren. Welche Assistenten lesen welche Quellen? Welche Antworten dürfen sie erzeugen? Welche externen Ziele sind technisch erreichbar? Welche Abhängigkeiten entstehen durch Browser, Suchindex, CDN, Proxy oder Image Fetcher? Und vor allem: Welche Kombinationen aus kleinen Schwächen wären bereits gefährlich?
Wer diese Fragen sauber beantwortet, baut bessere Leitplanken als mit Einzelregeln. Genau dort liegt der Mehrwert des SearchLeak-Falls: Er liefert kein abstraktes Risiko, sondern ein nachvollziehbares Angriffsmuster. Damit lässt sich intern argumentieren, warum KI-Sicherheitsprüfungen nicht nur Prompt-Reviews, sondern auch Web Security, Identity Design und Infrastrukturhärtung umfassen müssen.
Die eigentliche Nachricht ist also nicht, dass Copilot unsicher sei. Die Nachricht ist, dass Enterprise-KI kein Spezialfall außerhalb der Sicherheitsdisziplin ist. Sie ist ein Sicherheitsfall mit neuem Namen. Wer das früh versteht, kann Systeme so bauen, dass Produktivität und Schutz nicht gegeneinander ausgespielt werden müssen.
Quellen
- Varonis Threat Labs: SearchLeak, 15. Juni 2026
- Golem.de: Microsoft 365: Datenklau über Copilot mit nur einem Klick, 16. Juni 2026
- Microsoft MSRC: CVE-2026-42824
