Microsoft 365 Copilot SearchLeak (CVE-2026-42824): Wenn Ihr KI-Assistent zum Exfiltrationstool wird
Sicherheitsforscher haben gerade demonstriert, dass ein Enterprise-AI-Assistent mit nichts weiter als einem manipulierten Link zu einem präzisen Tool für Datenexfiltration umfunktioniert werden kann – und der unternehmenseigene DLP-Stack bleibt dabei völlig blind. CVE-2026-42824, inzwischen weithin als „SearchLeak“ bekannt, benannt nach der Bing-SSRF-Komponente im Kern, ist eine dreistufige Angriffskette in Microsoft 365 Copilot, die es Angreifern ermöglicht, Dokumente, E-Mails und Teams-Nachrichten aus einem Zielunternehmen zu extrahieren – ohne direkten Zugriff auf die Umgebung. Microsoft hat die Schwachstelle gepatcht und ihr einen CVSS-Score von 9.1 zugewiesen, was die Kombination aus niedriger Angriffskomplexität, fehlenden erforderlichen Privilegien und dem Umfang der zugänglichen Daten widerspiegelt.
Die SearchLeak-Offenlegung ist nicht nur wegen ihrer technischen Schwere relevant. Sie verdeutlicht ein Risiko, vor dem Sicherheitsarchitekten seit dem Einsatz von Enterprise-AI-Tools warnen: Wenn ein großes Sprachmodell umfassenden Lesezugriff auf Unternehmensdaten erhält und dann externen Eingaben ausgesetzt wird, entsteht eine Angriffsfläche, für die herkömmliche Sicherheitskontrollen nie konzipiert wurden. Die Tools, auf die Unternehmen zur Verhinderung von Datenverlust setzen – Netzwerk-DLP, CASB, E-Mail-Gateways – wurden für eine Welt entwickelt, in der Menschen Dateitransfers initiieren. Sie haben keinen Bezugsrahmen für einen AI-Assistenten, der im Hintergrund Dateien abruft und kodiert, weil eine Anweisung in einer Webseite versteckt ist.
Auch das Timing ist bedeutsam. Der Kiteworks 2026 Data Security and Risk: Annual Forecast Report identifizierte AI Data Governance als die prägende Sicherheitsherausforderung des Jahres und stellte fest, dass Unternehmen AI-Produktivitätstools schneller einführen, als sie Governance-Kontrollen dafür umsetzen. SearchLeak ist die erste schwerwiegende CVE, die diese Sorge in großem Maßstab bestätigt – und sie wird nicht die letzte sein.
Dieser Beitrag analysiert im Detail, wie die Angriffskette funktioniert, welche Inhalte gefährdet sind, warum bestehende Kontrollen versagen und wie eine verteidigungsfähige AI-Sicherheitsstrategie nach CVE-2026-42824 aussieht.
wichtige Erkenntnisse
1. Drei Schwachstellen verbinden sich zu einer verheerenden Angriffskette
CVE-2026-42824 ist keine einzelne Schwachstelle – sie kombiniert eine Prompt-Injection-Schwachstelle, eine Race Condition beim HTML-Rendering und ein Bing-SSRF-basiertes CSP-Bypass zu einem nahtlosen Angriff, der keine weitere Nutzerinteraktion als das Klicken auf einen bösartigen Link erfordert.
2. Herkömmliche Erkennungskontrollen sind blind für den Angriff
Da der Exfiltrationskanal über Microsofts eigene Bing-Infrastruktur läuft, erkennen Standard-DLP-Tools, Netzwerk-Proxys und CASB-Lösungen die ausgehende Anfrage nicht als verdächtig – der Datenverkehr sieht aus wie legitime Copilot-Telemetrie.
3. Jeder Microsoft 365-Mandant mit aktiviertem Copilot ist potenziell betroffen
Die Schwachstelle liegt in der Rendering-Schicht, die Copilot für Microsoft 365 gemeinsam nutzt. Das bedeutet, dass die Gefährdung nicht auf ein bestimmtes Modul oder Lizenzmodell beschränkt ist – jedes Unternehmen mit aktiviertem Copilot sollte dies als Risiko mit höchster Priorität behandeln.
4. Sensible Dokumente, E-Mails und Teams-Nachrichten sind betroffen
Copilot indiziert umfangreiche Unternehmensinhalte – einschließlich SharePoint-Dateien, Exchange-Postfächer und Teams-Konversationsverläufe. Ein erfolgreicher Angriff kann nahezu alle Inhalte, auf die der Zielnutzer Zugriff hat, sichtbar machen und exfiltrieren.
5. Patch-Deployment allein reicht nicht als Schutzmaßnahme
Obwohl Microsoft einen Patch veröffentlicht hat, sollten Unternehmen die sofortige Installation mit einer Überprüfung ihrer AI Data Governance-Strategie verbinden – einschließlich der Frage, auf welche Inhalte Copilot zugreifen kann, wer Zugriff hat und ob AI-generierte Ausgaben denselben Audit-Trail-Anforderungen unterliegen wie von Menschen initiierte Dateitransfers.
Sie vertrauen darauf, dass Ihr Unternehmen sicher ist. Aber können Sie es auch nachweisen?
Jetzt lesen
So funktioniert die SearchLeak-Angriffskette
Um SearchLeak zu verstehen, muss man wissen, wie Microsoft 365 Copilot externe Eingaben verarbeitet und Antworten rendert. Copilot ist darauf ausgelegt, Informationen aus der gesamten Microsoft 365-Umgebung eines Nutzers – SharePoint, OneDrive, Exchange, Teams – abzurufen und in natürlichsprachliche Antworten zu integrieren. Dafür benötigt Copilot umfassenden Lesezugriff auf Unternehmensinhalte. Genau dieser breite Zugriff macht Copilot wertvoll – und gefährlich, wenn ein Angreifer Anweisungen in den Kontext des Modells einschleusen kann.
Stufe 1: Parameter-to-Prompt-Injection
Die erste Schwachstelle ist eine Parameter-to-Prompt-Injection in der Art, wie Copilot bestimmte URL-Parameter verarbeitet, wenn ein Nutzer eine Seite aufruft oder auf einen per Teams oder E-Mail geteilten Link klickt. Wird eine manipulierte URL verarbeitet, gelangt vom Angreifer kontrollierter Text aus dem URL-Parameter ohne ausreichende Bereinigung in den Copilot-Prompt-Kontext. Das bedeutet: Der Angreifer kann versteckte Anweisungen in einen Link einbauen – etwa, um Copilot anzuweisen, bestimmte Dokumente abzurufen, E-Mail-Inhalte zusammenzufassen oder Teams-Verläufe zu durchsuchen – und diese Anweisungen werden ausgeführt, als hätte der Nutzer sie selbst eingegeben.
Prompt Injection ist eine bekannte AI-Risiko-Klasse – sie entspricht im Prinzip einem Cross-Site-Scripting-Angriff, bei dem nicht vertrauenswürdige Inhalte als vertrauenswürdige Anweisungen behandelt werden. Besonders gefährlich an SearchLeak ist, dass die Injection keine Interaktion mit einem Copilot-Chatfenster erfordert. Die bösartigen Anweisungen werden passiv ausgeführt, sobald der Browser des Nutzers die Seite lädt.
Stufe 2: Race Condition beim HTML-Rendering
Die zweite Schwachstelle ist eine Race Condition beim HTML-Rendering in Copilots Antwortoberfläche. Wenn Copilot eine Antwort mit HTML-Rendering erzeugt – etwa für Rich-Card-Displays in bestimmten Integrationen – gibt es ein Zeitfenster, in dem vom Angreifer kontrolliertes HTML in einem Kontext ausgeführt werden kann, der noch nicht den vollständigen Content Security Policy (CSP)-Restriktionen unterliegt. Forscher konnten dieses Fenster nutzen, um ein manipuliertes -Tag einzuschleusen, dessen src-Attribut die exfiltrierten Daten als Query-Parameter kodiert.
Die CSP ist die Browser-Kontrolle, die genau diese Art von Exfiltration verhindern soll – indem sie einschränkt, mit welchen externen Domains eine Seite kommunizieren darf. Hier wird die dritte Stufe der Angriffskette entscheidend.
Stufe 3: CSP-Bypass über Bing SSRF
Die dritte Schwachstelle ist eine Server-Side-Request-Forgery (SSRF) in der Art, wie Copilot Anfragen über Microsofts Bing-Infrastruktur weiterleitet. Copilot kommuniziert legitim mit Bing für bestimmte Such- und Grounding-Operationen, und der Bing-Endpunkt steht daher auf der CSP-Allowlist. Forscher fanden heraus, dass sie durch eine speziell gestaltete Bing-URL die Exfiltrationsanfrage so routen konnten, dass die gestohlenen Daten über einen Endpunkt übertragen werden, den die CSP-Regeln ausdrücklich erlauben.
Das Ergebnis: Das -Tag des Angreifers wird ausgelöst, kodiert abgerufene Dokumenteninhalte als URL-Parameter und die Anfrage läuft über Bing – für jedes Netzwerk-Monitoring sieht das wie normaler Copilot-zu-Bing-Traffic aus. Die Daten verlassen das Unternehmen unbemerkt.
Welche Daten sind gefährdet?
Der Umfang der durch SearchLeak exfiltrierbaren Daten richtet sich nach dem, worauf Copilot zugreifen kann – und das ist bei Unternehmen, die Copilots Index nicht explizit eingeschränkt haben, praktisch alles, worauf der Zielnutzer in Microsoft 365 Zugriff hat.
Forscher demonstrierten das Abrufen von SharePoint-Dokumentbibliotheken, Exchange-E-Mail-Inhalten inklusive Anhängen, Teams-Direktnachrichten und Kanal-Konversationen sowie OneDrive-Dateien. In der Praxis bedeutet das: geistiges Eigentum in SharePoint, personenbezogene Daten und Gesundheitsdaten in E-Mail-Threads mit Patienten oder Kunden, juristische Kommunikation, M&A-Dokumente in virtuellen Datenräumen und regulierte Inhalte, die HIPAA-, DSGVO– oder CMMC-Pflichten unterliegen.
Der Angriff ist gezielt steuerbar: Da der eingeschleuste Prompt spezifische Suchanfragen enthalten kann, kann ein Angreifer, der etwas über die Zielumgebung weiß – etwa durch LinkedIn oder frühere Aufklärung – Copilot anweisen, Dokumente mit bestimmten Begriffen zu suchen. „Finde E-Mails zu Akquisitionszielen der letzten 90 Tage“ oder „rufe die aktuellsten Verträge im Legal-SharePoint ab“ sind Beispiele für Anweisungen, die ein Prompt enthalten kann. Der Angriff ist also nicht auf wahllose Massen-Exfiltration beschränkt, sondern kann chirurgisch präzise erfolgen.
Deshalb ist die DSPM-Frage so dringend: Unternehmen, die nicht wissen, welche sensiblen Inhalte in ihrer Microsoft 365-Umgebung existieren und worauf ein bestimmter Nutzer – oder Copilot im Namen dieses Nutzers – zugreifen kann, arbeiten mit unbekannter Gefährdung. Data Governance, Zugriffskontrollen und Zugriffsbeschränkungen sind in diesem Kontext keine abstrakten Compliance-Übungen, sondern direkte Voraussetzungen, um das Risiko zu verstehen und zu begrenzen.
Warum bestehende Sicherheitskontrollen bei SearchLeak versagen
Der SearchLeak-Angriff ist gezielt darauf ausgelegt, die Kontrollkategorien zu umgehen, auf die sich die meisten Unternehmen zur Verhinderung von Datenexfiltration verlassen. Das ist kein Zufall – es spiegelt ein tiefes Verständnis der Schwachstellen von Unternehmenssicherheits-Tools im AI-Kontext wider.
Netzwerk-DLP- und CASB-Beschränkungen.
DLP und CASBs untersuchen ausgehenden Traffic auf erkennbare sensible Datenmuster – Sozialversicherungsnummern, Kreditkartennummern, bekannte Dokumentstrukturen. Bei SearchLeak sind die exfiltrierten Daten jedoch als URL-Parameter in scheinbar legitimen Copilot-zu-Bing-Anfragen kodiert. Die meisten DLP-Tools sind nicht darauf ausgelegt, URL-Parameter in auf der Allowlist stehenden Microsoft-Verbindungen tiefgehend zu prüfen. Selbst wenn sie dies tun, müssten sie das Kodierungsschema entschlüsseln, um zu erkennen, dass ein Dokument übertragen wird – was voraussetzt, dass sie den Angriff im Voraus kennen.
E-Mail-Gateway- und Proxy-Beschränkungen.
Der Angriff nutzt E-Mail nicht als Exfiltrationskanal. Es findet kein ausgehender Dateitransfer statt, den ein Proxy erkennen würde. Der gesamte Exfiltrationspfad ist ein HTTP-GET-Request zu einer Bing-URL, ausgelöst durch das Rendering einer Copilot-Antwort im Browser. Standard-Proxys sehen eine Microsoft-zu-Microsoft-Anfrage und lassen sie passieren.
Endpoint-DLP-Beschränkungen.
Endpoint-Agents, die Datei- und Zwischenablagezugriffe überwachen, erkennen diesen Angriff nicht, da keine Datei vom Nutzer geöffnet, kopiert oder über einen vom Endpoint-Agent überwachten Kanal übertragen wird. Der Dateizugriff erfolgt vollständig innerhalb der Copilot-Service-Schicht.
SIEM- und Verhaltensanalyse-Beschränkungen.
SIEM– und User-Behavior-Analytics-Plattformen suchen nach Anomalien im Nutzerverhalten. Eine Copilot-Sitzung, die ein Dutzend Dokumente abruft und eine GET-Anfrage an Bing sendet, sieht aus verhaltensanalytischer Sicht aus wie normale Copilot-Nutzung. Ohne eine spezifische Erkennungsregel für das SearchLeak-Muster erzeugen diese Tools keinen Alarm.
Das Fazit ist unangenehm: Unternehmen, die Microsoft 365 Copilot mit Standard-Sicherheitskontrollen einsetzen, haben eine Lücke. Diese zu schließen, erfordert gezielte Sicherheitsinvestitionen für AI-vermittelte Datenzugriffe – nicht nur Erweiterungen bestehender Kontrollen für menschliche Aktivitäten.
Das Governance-Problem, das SearchLeak offenlegt
SearchLeak wäre schon in einer klassischen Anwendung eine schwerwiegende Schwachstelle. In Microsoft 365 Copilot offenbart sie jedoch etwas Grundsätzlicheres: Die Governance-Infrastruktur, die Unternehmen für den verantwortungsvollen AI-Einsatz in regulierten Umgebungen benötigen, hält mit der Geschwindigkeit der AI-Einführung nicht Schritt.
Die zentrale Governance-Lücke betrifft ABAC und die Datenbegrenzung. Die meisten Unternehmen setzen Microsoft 365 Copilot mit Standardeinstellungen ein, wodurch Copilot auf alles zugreifen kann, was der Nutzer sehen darf. Für Führungskräfte mit breiten SharePoint-Berechtigungen bedeutet das: Copilot – und jeder Angreifer, der Prompts einschleusen kann – hat denselben Zugriff auf sensible Inhalte. Eine angemessene Data Governance verlangt, dass AI-Tools nach dem Prinzip der Datenminimierung arbeiten – also nur auf das zugreifen, was für die jeweilige Aufgabe nötig ist, nicht auf alles, wozu der Nutzer Rechte hat.
Die zweite Governance-Lücke ist die Revisionssicherheit. Wenn ein Mitarbeiter ein sensibles Dokument öffnet, wird dieser Zugriff im SharePoint-Audit-Log protokolliert und DLP-Plattformen können ihn mit anderen Aktivitäten korrelieren. Wenn Copilot dasselbe Dokument im Namen des Nutzers abruft – insbesondere, wenn dies durch eine eingeschleuste Anweisung und nicht durch eine bewusste Nutzeraktion geschieht – ist der Audit-Trail über mehrere Log-Quellen fragmentiert, die die meisten Unternehmen nicht korrelieren. Ein Angreifer, der mit SearchLeak 50 Dokumente exfiltriert, hinterlässt Spuren in Copilot-Sitzungslogs, Bing-Request-Logs und SharePoint-Audit-Logs – aber diese Spuren zu verbinden, erfordert eine einheitliche Transparenz, die den meisten Unternehmen fehlt.
Die dritte Governance-Lücke ist die Richtliniendurchsetzung auf AI-Ebene. DLP-Richtlinien werden meist auf Dateisystem-, E-Mail-Gateway- und Endpoint-Ebene durchgesetzt. Es gibt jedoch keine vergleichbare Durchsetzungsschicht auf der Ebene der AI-Interaktion – keine Kontrolle, die verhindert, dass Copilot vertrauliche Dokumente abruft und deren Inhalte in einer HTML-Antwort ausgibt. Solche AI Data Governance-Fähigkeiten erfordern speziell entwickelte AI-Sicherheitsinfrastrukturen. Sie zu erreichen, verlangt dieselbe Sorgfalt, die Unternehmen bei der Einhaltung gesetzlicher Vorgaben anwenden – systematisch, revisionssicher und kontinuierlich durchgesetzt.
So sieht eine verteidigungsfähige Reaktion aus
Das Patchen von CVE-2026-42824 ist der notwendige erste Schritt, aber als alleinige Maßnahme nicht ausreichend. Unternehmen, die nur den Patch anwenden, schließen lediglich diesen spezifischen Angriffsvektor, lassen aber die zugrundeliegenden Governance-Lücken für den nächsten offen. Eine verteidigungsfähige Reaktion umfasst vier Komponenten.
- Patch sofort anwenden. Der Microsoft-Patch für CVE-2026-42824 sollte mit höchster Priorität ausgerollt werden. Unternehmen, die Microsoft 365 Copilot in regulierten Umgebungen nutzen – etwa Rüstungsunternehmen mit CMMC 2.0-Compliance-Pflichten, Gesundheitsorganisationen unter HIPAA-Compliance, Finanzdienstleister unter DSGVO oder FINRA – sollten dies als Zero-Day-Reaktion behandeln, auch wenn der Patch verfügbar ist, angesichts der Schwere und der Wahrscheinlichkeit, dass die Schwachstelle bereits vor der Offenlegung ausgenutzt wurde.
- Copilot-Datenzugriff eingrenzen. Überprüfen Sie die SharePoint-Sensitivitätslabels, Berechtigungsstrukturen und Copilot-Zugriffskonfigurationen in Ihrem Microsoft 365-Mandanten. Wenden Sie das Prinzip der Datenminimierung an: Copilot sollte nur auf die Inhalte zugreifen können, die ein Nutzer für seine Rolle benötigt – nicht auf alles, was seine Microsoft 365-Berechtigungen erlauben. Datenklassifizierung ist hier Voraussetzung – Unternehmen, die sensible Inhalte in SharePoint und Exchange nicht gekennzeichnet haben, können den Copilot-Zugriffsbereich nicht effektiv steuern. Microsofts Copilot Data Governance-Dokumentation bietet konkrete Hinweise zur Eingrenzung. Wo Sensitivitätslabels nicht konsequent angewendet werden, sollte dies jetzt beschleunigt werden.
- AI-Ebene: Transparenz und Richtliniendurchsetzung implementieren. Speziell entwickelte AI Data Governance-Tools – wie das Kiteworks AI Data Gateway – bieten die Durchsetzungs- und Transparenzschicht, die generische DLP- und CASB-Lösungen nicht abdecken. Das AI Data Gateway erzwingt Datenzugriffsrichtlinien an der Schnittstelle zwischen AI-Modellen und Unternehmensinhalten, wendet ABAC-Kontrollen darauf an, welche Inhalte AI-Tools anzeigen dürfen, und protokolliert AI-vermittelte Zugriffe im selben einheitlichen Audit-Trail wie menschliche Aktivitäten. Das ist die architektonische Antwort auf die von SearchLeak offengelegten Governance-Lücken – nicht nur ein taktischer Patch für diese spezifische CVE.
- Nach dem Vorfall: Überprüfung auf mögliche Ausnutzung durchführen. Da CVE-2026-42824 vor Veröffentlichung des Patches ausnutzbar war, sollten Unternehmen Copilot-Sitzungslogs, SharePoint-Audit-Logs und Bing-Proxy-Logs für den Zeitraum vor dem Patch analysieren. Suchen Sie gezielt nach Copilot-Sitzungen mit ungewöhnlich hohem Dokumentabruf, Sitzungen, die durch externe Linkklicks initiiert wurden, und ausgehenden Bing-Anfragen mit auffällig großen URL-Parametern. Ein dokumentierter Incident-Response-Plan für AI-vermittelte Exfiltrationsszenarien stellt sicher, dass das Unternehmen im Falle einer bestätigten Ausnutzung schnell reagieren kann. Dies garantiert keine Entdeckung – der Angriff ist auf Tarnung ausgelegt – aber es ist ein verantwortungsvoller Schritt der Sorgfaltspflicht, insbesondere für Unternehmen mit regulatorischen Meldepflichten.
Die größere Lektion: AI-Sicherheit ist keine Erweiterung bestehender Sicherheitsmaßnahmen
CVE-2026-42824 sollte als Auslöser für eine überfällige Diskussion dienen. Die Tools und Architekturen, die Unternehmensdaten vor menschlich initiierten Exfiltrationen schützen sollen, reichen nicht aus, wenn ein AI-Assistent darauf zugreifen kann und externe Angreifer Anweisungen in diesen Assistenten einschleusen können.
Das Problem ist nicht, dass Microsoft ein unsicheres Produkt gebaut hat – jede komplexe Software hat Schwachstellen, und Microsoft hat angemessen reagiert. Das Problem ist, dass die von Unternehmen eingesetzten Sicherheitskontrollen für Copilot auf einem völlig anderen Bedrohungsmodell basieren. Sie gehen davon aus, dass Daten durch menschliche Aktionen das Unternehmen verlassen – Downloads, E-Mail-Anhänge, USB-Sticks, Web-Uploads. Sie sind nicht darauf ausgelegt, zu erkennen oder zu verhindern, dass ein AI-Assistent Inhalte auf Anweisung eines eingeschleusten Prompts abruft und kodiert.
Unternehmen benötigen ein Private Data Network-Modell für AI-vermittelten Datenzugriff: Eines, das zero trust architecture-Prinzipien auf jede Interaktion zwischen AI-Tool und Unternehmensdaten anwendet. Das bedeutet: Durchsetzung von Datenminimierung auf AI-Ebene, Protokollierung jedes AI-vermittelten Zugriffs in einem einheitlichen Audit-Log, an Sensitivität orientierte Richtlinienkontrollen für den Zugriff von AI-Tools und Aufbau von Erkennungsmechanismen speziell für AI-basierte Angriffsmuster.
Unternehmen, die SearchLeak nur als einmalige Patch-Aufgabe sehen, werden beim nächsten CVE derselben Klasse erneut exponiert sein. Unternehmen, die dies als Anlass nehmen, eine echte AI-Governance-Infrastruktur aufzubauen – einschließlich konformer AI-Frameworks, die Richtlinien auf Modellebene durchsetzen – sind deutlich besser aufgestellt: sowohl gegen zukünftige Schwachstellen als auch gegenüber Regulatoren und Auditoren, die AI-Datenzugriffe zunehmend als eigenständigen Compliance-Bereich prüfen werden.
Erfahren Sie mehr über den Schutz sensibler Daten vor AI-Exfiltration und vereinbaren Sie noch heute eine individuelle Demo.
Häufig gestellte Fragen
CVE-2026-42824 ist eine kritische Schwachstelle (CVSS 9.1) in Microsoft 365 Copilot, die drei unterschiedliche Schwächen kombiniert: eine Parameter-to-Prompt-Injection, die es ermöglicht, durch eine manipulierte URL Anweisungen in den Copilot-Kontext einzuschleusen; eine Race Condition beim HTML-Rendering, die ein Zeitfenster für die Ausführung von eingeschleustem HTML vor Anwendung der Content Security Policy schafft; und eine Server-Side-Request-Forgery, die es erlaubt, den Exfiltrationskanal über die Bing-Infrastruktur von Microsoft zu leiten – eine Domain, die bei allen Unternehmen auf der CSP-Allowlist steht. Die Kombination bedeutet: Ein Nutzer, der auf einen bösartigen Link klickt, kann Dokumente, E-Mails und Teams-Nachrichten unbemerkt von Copilot abrufen und an einen Angreifer exfiltrieren lassen – ohne sichtbare Interaktion mit Copilot und ohne Auslösung herkömmlicher DLP– oder CASB-Kontrollen. Um diese Angriffsklasse zu verstehen, müssen Unternehmen ihre Bewertung des Sicherheitsrisikomanagements in AI-fähigen Umgebungen neu denken.
Jedes Unternehmen, das Microsoft 365 Copilot aktiviert hat und den Patch noch nicht eingespielt hat, ist gefährdet. Besonders kritisch ist die Lage für Unternehmen, die große Mengen sensibler Inhalte in Microsoft 365 speichern – darunter Gesundheitsorganisationen mit personenbezogenen Gesundheitsdaten in Exchange und SharePoint, Rüstungsunternehmen mit CUI gemäß NIST 800-171 und CMMC, Finanzdienstleister mit regulierten Kundendaten und Rechtsabteilungen mit privilegierter Kommunikation. Für diese Unternehmen kann ein erfolgreicher Angriff regulatorische Incident-Response– und Meldepflichten auslösen, sodass der Patch sowohl aus Sicherheits- als auch aus Compliance-Sicht höchste Priorität hat. Unternehmen, die unter den Vorgaben des EU AI Act arbeiten, sind zusätzlich exponiert, da die Regulierung AI-System-Schwachstellen zunehmend als Governance-Versagen mit dokumentierter Abhilfe bewertet.
Der Angriff ist so gestaltet, dass er wie legitimer Copilot-zu-Bing-Traffic aussieht. Die Exfiltration erfolgt über einen HTTP-GET-Request zu einer Bing-URL, ausgelöst durch das Rendering einer Copilot-Antwort im Browser – ein Vorgang, der auf Netzwerkebene nicht von normalem Copilot-Suchtraffic zu unterscheiden ist. Standardmäßige DLP-Tools, die ausgehenden Traffic auf sensible Datenmuster prüfen, sind nicht darauf ausgelegt, URL-Parameter in auf der Allowlist stehenden Microsoft-Verbindungen tiefgehend zu analysieren. Selbst wenn sie dies tun, müssten sie das spezifische Kodierungsschema von SearchLeak kennen, um die gestohlenen Daten zu identifizieren. Die Lehre ist nicht, dass DLP und CASB nutzlos sind – sie bieten echten Schutz gegen viele Exfiltrationsszenarien –, sondern dass speziell entwickelte AI Data Governance-Kontrollen nötig sind, um AI-spezifische Angriffsvektoren zu adressieren. Diese Lücke betrifft auch Datenschutzpflichten: Unternehmen können nicht nachweisen, dass regulierte Daten geschützt blieben, wenn ihre Monitoring-Tools den Exfiltrationskanal nicht erkennen konnten.
Die höchste Priorität hat die Anwendung des Microsoft-Patches für CVE-2026-42824. Darüber hinaus sollten Unternehmen den Copilot-Datenzugriffsbereich überprüfen – konkret: Auf welche SharePoint-Sites, Postfächer und Teams-Kanäle kann Copilot für jeden Nutzer zugreifen und spiegelt dieser Zugriff den tatsächlichen Bedarf oder nur Standardberechtigungen wider? Unternehmen sollten außerdem die Microsoft 365-Audit-Logs für den Zeitraum vor dem Patch analysieren und nach auffälligen Copilot-Sitzungen oder ausgehenden Anfragen suchen, die auf das SearchLeak-Muster hindeuten. Wer regulatorische Meldepflichten nach HIPAA, DSGVO oder CMMC hat, sollte mit Rechts- und Compliance-Teams klären, ob der potenzielle Gefährdungszeitraum Melde- oder Dokumentationspflichten auslöst. Eine risikospezifische Bewertung des AI-Datenzugriffs sollte vor der erneuten oder erweiterten Nutzung von Copilot abgeschlossen werden.
Das Kiteworks AI Data Gateway schließt die Governance-Lücken, die CVE-2026-42824 auf architektonischer Ebene offenlegt. Es erzwingt ABAC– und Datenminimierungsrichtlinien an der Schnittstelle zwischen AI-Tools und Unternehmensinhalten, sodass Modelle nur auf Inhalte zugreifen können, die zur Rolle des Nutzers und zum jeweiligen Aufgaben-Kontext passen – nicht auf alles, wozu der Nutzer Berechtigungen hat. Jeder AI-vermittelte Zugriff wird im einheitlichen Audit-Log von Kiteworks protokolliert und schafft so die Transparenz, die Unternehmen benötigen, um anomale AI-Aktivitäten zu erkennen, Compliance nachzuweisen und Vorfälle zu untersuchen. Das CISO Dashboard bietet Echtzeit-Transparenz darüber, auf welche Inhalte AI-Tools im Unternehmen zugreifen – und ermöglicht so das Security Risk Management, das SearchLeak als unverzichtbar für AI-fähige Unternehmen aufzeigt. Unternehmen, die diese Schutzmaßnahmen auf eigene AI-Workflows ausweiten möchten, können zudem den Kiteworks Secure MCP Server nutzen, um dieselben Governance-Richtlinien für Modellintegrationen durchzusetzen.
Weitere Ressourcen
- Blogbeitrag
Zero‑Trust-Strategien für kosteneffizienten AI-Datenschutz - Blogbeitrag
Wie 77 % der Unternehmen bei AI-Datensicherheit scheitern - eBook
AI Governance Gap: Warum 91 % der kleinen Unternehmen 2025 russisches Roulette mit Datensicherheit spielen - Blogbeitrag
Für Ihre Daten gibt es kein „–dangerously-skip-permissions“ - Blogbeitrag
Regulierungsbehörden fragen nicht mehr, ob Sie eine AI-Policy haben. Sie wollen Beweise, dass sie funktioniert.