Luki w Microsoft Copilot Personal umożliwiały wyciek danych z połączonych aplikacji po jednym kliknięciu

Wprowadzenie do problemu / definicja

Badacze bezpieczeństwa ujawnili zestaw podatności w Microsoft Copilot Personal, które mogły umożliwiać uruchomienie złośliwego promptu po pojedynczym kliknięciu spreparowanego odnośnika. Problem dotyczył automatycznego wykonania polecenia w kontekście aktywnej sesji użytkownika, a następnie odczytu danych z usług wcześniej połączonych z asystentem.

To istotny przykład ryzyka związanego z nowoczesnymi asystentami AI, które mają dostęp nie tylko do konwersacji, ale również do pamięci użytkownika i zewnętrznych konektorów. W praktyce oznacza to, że skuteczny atak nie musi przejmować konta w tradycyjnym sensie — wystarczy nadużyć już przyznanych uprawnień.

W skrócie

Opisane problemy zostały zbiorczo nazwane CoSnitch. Najgroźniejszy scenariusz wykorzystywał kombinację parametrów URL, które pozwalały automatycznie uruchomić prompt bez ręcznego wpisywania go przez ofiarę.

atak wymagał tylko jednego kliknięcia w spreparowany link,
prompt działał w ramach już zalogowanej sesji użytkownika,
możliwy był odczyt danych z połączonych usług, takich jak poczta, kalendarz czy magazyny plików,
osobny wektor dotyczył zatruwania pamięci Copilota przez funkcję podsumowywania stron WWW,
zgłoszenie trafiło do Microsoftu w grudniu 2025 roku, a poprawki opublikowano 18 sierpnia 2026 roku.

Kontekst / historia

Incydent wpisuje się w rosnącą kategorię zagrożeń związanych z prompt injection, pośrednim wykonywaniem instrukcji oraz nadużywaniem integracji z usługami zewnętrznymi. W środowisku AI wartość atakowanego zasobu nie wynika wyłącznie z działania modelu, ale przede wszystkim z uprawnień, zakresu dostępu do danych oraz możliwości wykonywania operacji w imieniu użytkownika.

W tym przypadku badacze wskazali, że jednym ze źródeł problemu był nieudokumentowany parametr URL ujawniony podczas testów. Pozwoliło to zbudować łańcuch ataku, w którym użytkownik musiał jedynie otworzyć odpowiednio przygotowany odnośnik. Według opisu badanie koncentrowało się na konsumenckiej wersji Copilot Personal działającej w przeglądarce, a nie na Microsoft 365 Copilot.

Analiza techniczna

Rdzeń ataku opierał się na zestawieniu parametru q, służącego do wstępnego wypełnienia pola wejściowego, z parametrem autorun=1, który powodował wykonanie przygotowanego promptu po załadowaniu strony. W praktyce atakujący mógł osadzić instrukcję w linku i doprowadzić do jej uruchomienia bez klasycznej interakcji z interfejsem.

Po wykonaniu prompt działał z uprawnieniami wynikającymi z bieżącej sesji użytkownika. Nie chodziło więc o eskalację uprawnień po stronie platformy, lecz o wykorzystanie dostępu, który wcześniej został legalnie przyznany asystentowi. Jeśli użytkownik autoryzował połączenia z pocztą, kalendarzem lub repozytorium plików, możliwe było odpytanie tych źródeł i pobranie dostępnych informacji.

Według opisu badaczy zakres potencjalnie dostępnych danych obejmował między innymi treści wiadomości, tematy e-maili, metadane nadawców i odbiorców, informacje kalendarzowe, nazwy plików, podsumowania metadanych w chmurze, historię rozmów oraz zapisane instrukcje znajdujące się w pamięci asystenta. Do eksfiltracji danych miał zostać użyty mechanizm pobierania adresów URL, który pozwalał przesyłać zakodowane informacje do zewnętrznego webhooka.

Istotnym elementem była także trwałość wykonania. Badacze twierdzili, że po uruchomieniu prompt mógł zostać dokończony nawet wtedy, gdy użytkownik zamknął kartę przeglądarki niemal natychmiast po jej otwarciu. Dodatkowym utrudnieniem dla detekcji miał być fakt, że ruch sieciowy generowany podczas eksfiltracji przypominał legalne żądania związane z podsumowywaniem stron przez asystenta.

Trzeci problem dotyczył pamięci Copilota. Spreparowana strona WWW poddana podsumowaniu mogła spowodować zapisanie złośliwych instrukcji do pamięci użytkownika. Taki wpis mógł następnie wpływać na zachowanie przyszłych sesji, prowadząc do trwałego zatrucia kontekstu działania asystenta.

Konsekwencje / ryzyko

Z perspektywy bezpieczeństwa zagrożenie było poważne, ponieważ łączyło niski próg interakcji ofiary, dostęp do danych z wielu źródeł oraz ograniczoną widoczność telemetryczną. Atak typu one-click jest szczególnie niebezpieczny tam, gdzie użytkownicy traktują pracę z asystentem AI jako codzienny, rutynowy element środowiska pracy.

Ryzyko nie polegało na klasycznym przejęciu konta, ale na cichym użyciu istniejących uprawnień użytkownika. Takie nadużycie zaufanego komponentu może omijać część mechanizmów bezpieczeństwa, które koncentrują się na wykrywaniu malware, podejrzanych plików czy znanych wskaźników kompromitacji.

Szczególnie istotny pozostaje wątek pamięci asystenta. Jeśli złośliwa instrukcja zostanie utrwalona, może wpływać na przyszłe odpowiedzi modelu, modyfikować interpretację poleceń i zwiększać ryzyko kolejnych wycieków danych. To zmienia jednorazowy incydent w bardziej trwały problem operacyjny.

Rekomendacje

Organizacje i użytkownicy powinni traktować asystentów AI z konektorami do danych jak systemy uprzywilejowane. Kluczowe znaczenie ma przegląd wszystkich usług połączonych z Copilotem oraz odłączenie tych integracji, które nie są niezbędne do codziennej pracy.

Równie ważne jest wdrożenie zasady minimalnych uprawnień. Asystent nie powinien mieć dostępu do skrzynek, plików i zasobów, które nie są konieczne do realizacji konkretnych zadań. W środowiskach firmowych warto dodatkowo segmentować dane, ograniczać zakres konektorów i monitorować nietypowe wzorce dostępu realizowane przez narzędzia AI.

szkolić użytkowników, aby ostrożnie traktowali linki uruchamiające sesje asystentów AI,
regularnie przeglądać ustawienia pamięci i zapisane preferencje pod kątem nieautoryzowanych wpisów,
monitorować nietypowe żądania wychodzące do webhooków i usług zewnętrznych,
analizować zakres źródeł danych dostępnych dla narzędzi AI,
uwzględnić prompt injection i memory poisoning w testach bezpieczeństwa.

Po stronie producentów platform AI kluczowe pozostaje blokowanie automatycznego wykonywania promptów z parametrów URL, wymuszanie jednoznacznej interakcji użytkownika dla operacji wrażliwych, walidacja pamięci zapisywanej przez funkcje podsumowywania oraz rozwój lepszej telemetrii dla operacji wykonywanych przez asystenta.

Podsumowanie

Przypadek CoSnitch pokazuje, że bezpieczeństwo asystentów AI należy oceniać przede wszystkim przez pryzmat danych, do których mają dostęp, oraz automatyzacji dostępnej w interfejsie użytkownika. W opisanym scenariuszu pojedyncze kliknięcie mogło uruchomić prompt w aktywnej sesji, doprowadzić do odczytu danych z połączonych aplikacji i umożliwić ich przesłanie poza środowisko ofiary.

Najważniejszy wniosek jest praktyczny: każdy asystent AI wyposażony w pamięć, historię rozmów i integracje z usługami zewnętrznymi powinien być objęty kontrolą porównywalną z innymi systemami mającymi dostęp do wrażliwych informacji. Ograniczanie połączeń, minimalizacja uprawnień, przegląd pamięci i monitorowanie zachowań asystenta stają się podstawą współczesnej cyberhigieny.