Wprowadzenie do problemu / definicja
Badacze bezpieczeństwa ujawnili zestaw podatności w Microsoft Copilot Personal, które mogły umożliwić uruchomienie złośliwego promptu w kontekście aktywnej sesji użytkownika. W praktyce oznaczało to ryzyko wykorzystania wcześniej nadanych uprawnień do odczytu danych z połączonych usług, takich jak poczta, kalendarz czy dyski chmurowe, a następnie ich przekazania poza środowisko ofiary.
To kolejny przykład, że asystenci AI zintegrowani z usługami osobistymi i firmowymi stają się elementem o podwyższonym poziomie ryzyka. Gdy model otrzymuje dostęp do danych i funkcji, każda luka w mechanizmie obsługi promptów, pamięci lub parametrów wejściowych może prowadzić do naruszenia poufności informacji.
W skrócie
- Łańcuch ataku nazwany CoSnitch wykorzystywał kilka problemów bezpieczeństwa w Microsoft Copilot Personal.
- Kluczowy scenariusz pozwalał na automatyczne wykonanie promptu po otwarciu spreparowanego linku.
- Atak nie wymagał instalacji malware ani eskalacji uprawnień poza zgody wcześniej nadane przez użytkownika.
- Możliwy był odczyt danych z podłączonych usług oraz ich eksfiltracja do zewnętrznego punktu odbioru.
- Microsoft otrzymał zgłoszenie w grudniu 2025 roku, a poprawki opublikowano 18 sierpnia 2026 roku.
- Według ujawnionych informacji nie stwierdzono dowodów aktywnego wykorzystania podatności w środowisku produkcyjnym.
Kontekst / historia
Rozwój asystentów generatywnych znacząco zwiększył powierzchnię ataku w środowiskach konsumenckich i biznesowych. Copilot Personal działa jako asystent, który po autoryzacji może uzyskać dostęp do informacji znajdujących się w połączonych kontach i usługach. Z jednej strony poprawia to wygodę użytkownika, z drugiej tworzy nową kategorię ryzyk związanych z nadużyciem zaufanego pośrednika mającego szeroki wgląd w dane.
Opisywany przypadek wpisuje się w rosnącą liczbę badań nad prompt injection, parameter-to-prompt injection oraz memory poisoning. W takich scenariuszach atakujący nie musi przełamywać klasycznych zabezpieczeń systemowych. Wystarczy wpłynąć na sposób, w jaki aplikacja przekazuje dane wejściowe do modelu lub jak model zapamiętuje instrukcje, aby osiągnąć efekt podobny do przejęcia części logiki aplikacyjnej.
Analiza techniczna
Rdzeniem problemu była możliwość zbudowania adresu URL, który automatycznie uruchamiał prompt po otwarciu strony. Według opisu badaczy wykorzystano parametr q, służący do wstępnego wypełnienia zapytania, oraz parametr autorun=1, który powodował wykonanie instrukcji bez dodatkowego działania użytkownika. To sprawiało, że złośliwy prompt mógł zostać uruchomiony natychmiast w ramach zalogowanej sesji ofiary.
Kolejny etap polegał na wykorzystaniu uprawnień już przyznanych Copilotowi. Asystent nie potrzebował nowych praw administracyjnych ani obejścia mechanizmów autoryzacji. Wystarczał dostęp do usług wcześniej połączonych przez użytkownika. W takim modelu możliwe było odczytanie treści wiadomości, tematów, metadanych nadawców i odbiorców, informacji kalendarzowych, danych o plikach oraz historii wcześniejszych konwersacji.
Badacze wskazali także możliwość użycia funkcji pobierania zasobów do przekazania zakodowanych danych do zewnętrznego webhooka kontrolowanego przez atakującego. Z perspektywy monitoringu taki ruch mógł przypominać zwykłą aktywność asystenta, na przykład podczas analizy lub podsumowywania treści internetowych. To znacząco utrudniało wykrycie incydentu wyłącznie na podstawie podstawowej telemetrii sieciowej.
Trzecia ścieżka dotyczyła pamięci asystenta. Spreparowana treść mogła skłonić Copilota do zapisania złośliwych instrukcji w pamięci użytkownika, co mogło wpływać na kolejne sesje i odpowiedzi modelu. Tego typu trwałe skażenie kontekstu jest szczególnie niebezpieczne, ponieważ nie kończy się wraz z zamknięciem przeglądarki i może oddziaływać na późniejsze interakcje, jeśli pamięć nie zostanie sprawdzona i wyczyszczona.
Konsekwencje / ryzyko
Najpoważniejszym skutkiem podatności była możliwość cichego wycieku danych bez infekowania urządzenia końcowego. W odróżnieniu od klasycznych kampanii phishingowych użytkownik nie musiał pobierać pliku, uruchamiać makra ani instalować aplikacji. Wystarczyło kliknięcie odpowiednio przygotowanego odnośnika, który uruchamiał złośliwy prompt w zaufanej sesji.
Skala wpływu zależała od liczby połączonych usług i zakresu przyznanych zgód. Im więcej integracji użytkownik aktywował, tym większy potencjalny zasięg incydentu. Ryzyko obejmowało zarówno dane osobiste, jak i informacje organizacyjne, w tym szczegóły korespondencji, harmonogramów, dokumentów oraz kontekstu wcześniejszych rozmów z asystentem.
Szczególne wyzwanie dla zespołów bezpieczeństwa stanowi fakt, że aktywność Copilota mogła wyglądać jak prawidłowe użycie funkcji produktu. To oznacza, że tradycyjne mechanizmy wykrywania anomalii, skupione na endpointach lub prostych wskaźnikach sieciowych, mogły nie zapewnić odpowiedniej widoczności. Wariant związany z pamięcią dodatkowo zwiększał ryzyko długotrwałej kompromitacji warstwy decyzyjnej AI.
Rekomendacje
Organizacje i użytkownicy powinni traktować asystentów AI z dostępem do danych jako uprzywilejowanych pośredników. Oznacza to potrzebę regularnego przeglądu połączonych usług i ograniczania integracji wyłącznie do tych, które są rzeczywiście niezbędne. Redukcja uprawnień bezpośrednio zmniejsza potencjalny wpływ podobnych podatności.
- Regularnie audytować połączone usługi i usuwać zbędne integracje.
- Monitorować nietypowe zapytania, masowy odczyt danych oraz niestandardowe użycie konektorów AI.
- Traktować linki otwierające sesje asystentów AI z taką samą ostrożnością jak odnośniki do systemów uprzywilejowanych.
- Uwzględnić prompt injection, memory poisoning i parameter-to-prompt injection w modelowaniu zagrożeń oraz testach red team.
- Weryfikować zawartość pamięci asystenta w razie podejrzenia incydentu i wdrożyć procedury jej okresowego przeglądu.
- Łączyć telemetrię z systemów tożsamości, poczty i SaaS z obserwacją aktywności narzędzi generatywnych.
W środowiskach korporacyjnych warto również ocenić, czy dostawca platformy umożliwia rejestrowanie zmian pamięci oraz ich integrację z narzędziami SIEM lub XDR. Bez takiej widoczności analiza incydentów związanych z AI może być niepełna.
Podsumowanie
Przypadek CoSnitch pokazuje, że bezpieczeństwo systemów AI zależy nie tylko od jakości modelu, ale również od sposobu integracji interfejsu, pamięci, parametrów URL i konektorów danych. Nawet bez klasycznego exploita systemowego możliwe było zbudowanie skutecznego łańcucha prowadzącego do wycieku informacji po jednym kliknięciu.
Dla zespołów bezpieczeństwa to wyraźny sygnał, że aplikacje oparte na generatywnej AI powinny być objęte pełnym procesem zarządzania ryzykiem, testami bezpieczeństwa i kontrolą dostępu na poziomie porównywalnym z innymi systemami uprzywilejowanymi. Wraz ze wzrostem integracji takich narzędzi stawką staje się nie tylko produktywność, ale również ochrona danych i zaufania do automatycznych decyzji podejmowanych przez asystentów.
Źródła
- https://thehackernews.com/2026/08/microsoft-copilot-personal-flaws-could.html
- https://www.varonis.com/blog/reprompt
- https://support.microsoft.com/en-US/microsoft-copilot/connecting-microsoft-copilot-to-other-services
- https://www.microsoft.com/en-us/security/blog/2026/06/22/guarding-ai-memory/
- https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-24301