Jedno nieudokumentowane ustawienie wystarczyło, aby zamienić Muse od Meta w furtkę do dyktowania.

21 września 2026 r. badacz bezpieczeństwa Patrick Wardle opublikował proof-of-concept o nazwie not-a-mused, pokazujący, że jedno nieudokumentowane ustawienie w asystencie Muse firmy Meta dla systemu macOS decyduje o tym, gdzie aplikacja wysyła to, co dyktujesz. Kluczem jest endo_voyager_dictation_endpoint, a każdy proces działający jako zalogowany użytkownik może go nadpisać bez hasła administratora i bez monitu systemu macOS. Wystarczy wskazać go na adres kontrolowany przez atakującego, a dźwięk i transkrypcja z Muse trafią tam zamiast do Meta; Wardle pokazał, że atakujący może następnie odczytać dyktowane treści, wstrzyknąć instrukcje, których Muse słucha, i przejąć token logowania do konta Muse użytkownika — docierając do każdego urządzenia, na którym to konto jest zalogowane. Meta twierdzi, że następnego dnia wydała poprawkę hotfix. Nie zgłoszono żadnego ataku w warunkach rzeczywistych. Własny zapis ujawnienia w archiwum, wraz z oceną ważności i cytowanymi źródłami, znajduje się w Archiwum incydentów AI obok pozostałych wpisów o podatnościach agentów w tej serii.

Co robi to ustawienie i dlaczego wystarczył jeden klucz

Wardle jest współzałożycielem organizacji non-profit Objective-See – podaje The Register. Muse to osobisty agent Meta, uruchomiony w Stanach Zjednoczonych na początku września 2026 r., a The Hacker News donosi, że po włączeniu przez użytkownika może on działać w obrębie jego plików, poczty e-mail, wiadomości, kalendarza, aplikacji zakupowych i inteligentnego domu, korzystając z dowolnego dostępu, na jaki dana osoba zdecyduje się go udzielić. Odkrycie Wardle'a nie dotyczy tej listy uprawnień. Dotyczy ono mechanizmów znajdujących się pod nią: aplikacja na Maca zawiera ustawienie, które kieruje dźwięk dyktowania poza urządzenie, a adres, na który go kieruje, jest przechowywany w miejscu, gdzie system operacyjny nie chroni go przed innymi programami działającymi jako ten sam użytkownik.

Jak czytamy w samym repozytorium, proof-of-concept pokazuje, że „lokalny atakujący lub złośliwe oprogramowanie może zmodyfikować ten endpoint bez specjalnych uprawnień”, po czym „podyktowane prompty można wysyłać do endpointu kontrolowanego przez atakującego”. Repozytorium wymienia, co to potencjalnie umożliwia: przechwycenie podyktowanego dźwięku i promptów, wstrzyknięcie promptów do Muse, kradzież materiałów uwierzytelniających Muse oraz nadużycie dowolnego dostępu, którego użytkownik udzielił aplikacji. Konsekwencję podsumowuje jednym zdaniem: „Dostęp Muse może potencjalnie stać się dostępem atakującego”. Proof-of-concept implementuje to, co jego README nazywa podzbiorem ponad 50 poleceń udostępnianych przez Muse.

Sekwencja opisywana przez The Hacker News ma charakter mechaniczny. Program, który atakujący uruchamia na tym samym Macu, modyfikuje preferencję, a następnie czeka. Użytkownik dotyka mikrofonu i mówi. Dźwięk oraz powstały tekst trafiają do programu atakującego, a nie do Meta. Z tej pozycji Wardle zademonstrował trzy rzeczy: odczytywanie tego, co użytkownik podyktował, dodawanie dodatkowych instrukcji, którym Muse ufa i które wykonuje — serwis opisuje ten efekt jako prompt injection — oraz przechwytywanie tokena, który służy do logowania na konto użytkownika w Muse.

Token i każde urządzenie za nim

Token to ta część, która opuszcza Maca. Hacker News donosi, że Muse wysyła swój token uwierzytelniający wraz z przekierowanym dyktowaniem, więc ten sam nasłuchiwacz, który przechwytuje transkrypcję, przechwytuje także dane uwierzytelniające. Zdaniem Wardle’a napastnik może dzięki niemu odczytać historię czatu konta i wydawać asystentowi polecenia bezpośrednio — a ponieważ konto Muse może być zalogowane na kilku urządzeniach, te polecenia nie ograniczają się do przejętej maszyny.

Wardle przeprowadził tę część na własnym sprzęcie. Z komputera Mac polecił aplikacji Muse na swoim iPhonie zgłosić swoją dokładną lokalizację, przeprowadzić skanowanie Bluetooth pobliskich urządzeń i wymienić polecenia inteligentnego domu, które mogła wysłać. The Hacker News dodaje do tej demonstracji jedno zastrzeżenie: w jego testach asystent tylko przygotowywał szkice wiadomości, zamiast wysyłać je samodzielnie.

To jest argument za tym, by traktować ten błąd jako coś więcej niż wyciek danych z dyktowania. The Register relacjonuje, jak Wardle ujmuje ogólny problem — że macOS został zbudowany tak, aby uniemożliwić jednemu programowi odczytywanie danych innego, oraz że agent, któremu przyznano szeroki dostęp, staje się pojedynczym punktem awarii tych mechanizmów kontroli. „To, że wprowadza się zły sąsiad, nie oznacza, że ten sąsiad automatycznie ma dostęp do wszystkich mieszkań” — powiedział The Register. Asystent, któremu przekazano klucze, to już inna sprawa.

Czego nie robi

W źródłach podano trzy ograniczenia, które mają znaczenie dla każdego, kto ocenia narażenie. Po pierwsze, luka sama w sobie nie jest sposobem na dostanie się do Maca: wymaga kodu już działającego jako zalogowany użytkownik, dlatego repozytorium Wardle’a określa ją jako „atak lokalny”, a Meta nazwała ją później lokalną eskalacją uprawnień. Po drugie, nie obchodzi izolacji aplikacji macOS — The Hacker News podaje, że nie przekracza granicy, która uniemożliwia jednej aplikacji odczytywanie zapisanych haseł i tokenów innej aplikacji; własny token Muse’a towarzyszy przekierowanemu dyktowaniu, a atak polega na skłonieniu Muse’a do działania z dostępem, który już ma. Po trzecie, nie dowodzi, że złamano projekt chmurowy Meta, który firma zbudowała, aby agent każdego użytkownika był odizolowany od innych.

Pokazuje natomiast, dlaczego ochrona punktów końcowych może tego nie zauważyć. The Hacker News relacjonuje argument Wardle’a, że polecenia pochodzą z Muse, zwykłej podpisanej aplikacji, a nie z czegoś, co wygląda jak złośliwe oprogramowanie; The Register odnotowuje tę samą obawę jego słowami, że produkt EDR nie potrafi rozróżnić, czy polecenie pochodzi od użytkownika, agenta czy atakującego.

Wardle wskazuje również przyczynę. The Register donosi, że Apple udostępnia dyktowanie na urządzeniu i że według jego oceny luka nie istniałaby, gdyby Meta użyła tego API; sugeruje, że Meta zdecydowała się tego nie robić, ponieważ chce danych, i dodaje: „Uważam, że pewna ich zachłanność na dane użytkowników niejako otwiera drzwi, zwiększa powierzchnię ataku”. To jego wnioskowanie o motywach Meta, a nie udokumentowany fakt, i Meta nie odpowiedziała na nie w materiałach przeanalizowanych tutaj.

Ujawnienie, hotfix i spór o etykietę

Wardle ujawnił sprawę publicznie, nie informując wcześniej Meta. The Hacker News podaje, że zdecydował się na pełne ujawnienie, aby użytkownicy zrozumieli ryzyko, a także dlatego, że często jest to najszybsza droga do naprawy. The Register, który przeprowadził z nim wywiad, twierdzi, że Meta nie odpowiedziała natychmiast na jego prośbę o komentarz.

Odpowiedź przyszła następnego dnia i miała dołączoną charakterystykę. W poście w mediach społecznościowych z 22 września David Singleton z Meta Superintelligence Labs powiedział, że aplikacja Muse została zaktualizowana: „Był to lokalny atak polegający na eskalacji uprawnień, a nie zdalne wykorzystanie luki. Wykorzystanie go do wyrządzenia szkody wymaga zatem złośliwego kodu już działającego na maszynie użytkownika na jego koncie użytkownika, więc praktyczne ryzyko dla użytkowników aplikacji Muse Mac było dość niskie”. W poście dodano: „Niemniej jednak wydaliśmy poprawkę hotfix dla aplikacji, aby rozwiązać problem”.

W jednym wąskim punkcie obie strony się nie zgadzają, a spór dotyczy klasyfikacji, a nie mechanizmu. Stwierdzenie Singletona opiera się na wymogu istnienia lokalnego kodu. Wardle powiedział The Hacker News, że zdalny atakujący wciąż mógłby do tego doprowadzić dzięki sztuczce ClickFix — schematowi, który nakłania użytkownika do wklejenia pojedynczego polecenia w Terminalu, bez niczego do pobrania lub zainstalowania — co zapewniłoby lokalne wykonanie potrzebne exploitowi. Żadne źródło przejrzane na potrzeby tego artykułu nie donosi, żeby ktokolwiek faktycznie to zrobił, a droga przez ClickFix jest zademonstrowaną możliwością, a nie zaobserwowaną kampanią.

To, co zmienia hotfix, nie jest publiczne. The Hacker News poinformował, że nie mógł potwierdzić, czemu służy ta zmiana, oraz że Meta nie opublikowała biuletynu bezpieczeństwa; zapis archiwum również odnotowuje, że nie wydano żadnego biuletynu. Użytkownik Muse ma zatem tylko słowo Meta, że problem został rozwiązany, i żaden dokument opisujący, w jaki sposób.

Co jest ustalone, a co nie

Archiwum ocenia ten rekord na poziomie pewności A — dobrze udokumentowany, ze zgodnymi źródłami pierwotnymi — i nie oznacza go jako spornego. Ta ocena nie jest twierdzeniem, że doszło do szkody: w rekordzie rzeczywista szkoda oznaczona jest jako fałsz, a nic w przejrzanych materiałach nie opisuje zaatakowanego użytkownika, skradzionego konta ani utraconego pliku. Dowodami są proof-of-concept badacza, jego własne demonstracje oraz oświadczenie dostawcy.

• Ustalono: aplikacja Muse na macOS zawierała nieudokumentowaną preferencję o nazwie endo_voyager_dictation_endpoint, która kontrolowała, dokąd trafiało dyktowanie, a proces działający jako zalogowany użytkownik mógł ją nadpisać bez podwyższonych uprawnień — według repozytorium Wardle'a i obu serwisów.

• Ustalono: przekierowanie tego punktu końcowego powodowało wysłanie nagrania dyktowanego głosu i transkrypcji na adres kontrolowany przez atakującego, a token uwierzytelniający Muse był przesyłany wraz z nimi, według The Hacker News.

• Ustalono: uzyskany w ten sposób token mógł sterować Muse na innych urządzeniach zalogowanych na to samo konto; Wardle zademonstrował raportowanie lokalizacji, skanowanie Bluetooth i listę poleceń inteligentnego domu na własnym iPhone'ie, według The Hacker News.

• Ustalono: atak wymagał wykonania kodu jako użytkownik, nie przełamał izolacji aplikacji macOS i nie naruszył separacji chmury Meta, według The Hacker News i repozytorium Wardle'a.

• Ustalono: Wardle ujawnił to bez wcześniejszego powiadomienia Meta, a Meta poinformowała 22 września, że wydała hotfix, według The Register i The Hacker News.

• Nie ustalono: co zmienił hotfix, czy dana preferencja nadal istnieje w bieżących kompilacjach oraz czy ścieżka ClickFix ją przetrwa. W przeanalizowanym materiale nie pojawia się żadna informacja doradcza, wpis w changelogu ani CVE opisujące tę poprawkę.

• Nie ustalono: czy ktokolwiek był celem ataku w rzeczywistym środowisku oraz czy luka była osiągalna na jakiejkolwiek platformie innej niż aplikacja macOS. Wszystkie demonstracje opisane w materiale zostały przeprowadzone na własnych maszynach Wardle’a.

• Nie ustalono: niezależne odtworzenie. Obie redakcje poinformowały o tym odkryciu, a The Register przeprowadził z Wardle’em wywiad telefoniczny, ale żadna strona trzecia nie opublikowała własnego testu tego przekierowania, a Meta nie opisała tej wady własnymi słowami poza klasyfikacją Singletona.

Tymczasowa porada i co można uogólnić

Ponieważ poprawka nie została potwierdzona, The Hacker News opublikował krótką listę środków ostrożności dla użytkowników komputerów Mac, którą warto zapisać, ponieważ precyzyjnie określa zakres narażenia. Zamknij lub usuń Muse, co całkowicie zamyka tę ścieżkę. Przejrzyj aplikacje i uprawnienia, które ma Muse, i odbierz wszystko, czego nie potrzebuje, aby przejęty agent dziedziczył mniej. Traktuj konto Muse i połączone z nim konta jako ujawnione, jeśli Mac może już być przejęty, i zmień te hasła. Unikaj wprowadzania głosowego w Muse, które jest konkretnym wyzwalaczem, na który czeka proof-of-concept. I nie uruchamiaj poleceń, które strona internetowa lub wiadomość każe ci wkleić do Terminala, ponieważ tak zaczyna się ścieżka ClickFix.

Możliwy do przeniesienia wniosek jest mniejszy niż „AI jest niebezpieczne” i ostrzejszy niż „załataj swoje aplikacje”. Przydatność agenta i promień jego rażenia to ta sama liczba: uprawnienia, które pozwalają Muse czytać pliki i wysyłać wiadomości, są uprawnieniami, które atakujący dziedziczy, sterując nim, a żadna kontrola, którą przeszedł, nie została przełamana. macOS utrzymał swoją granicę aplikacji, chmura Meta zachowała swoją separację, a token nie został wyciągnięty z pęku kluczy. Preferencja, która powinna była być obojętna, okazała się nośna i znajdowała się poza każdą warstwą zbudowaną do ochrony danych, na które wskazywała. Własne podsumowanie Wardle’a dotyczące kompromisu projektowego, udzielone The Register, jest tym, które przetrwa łatkę: „Są super wygodne i super wzmacniające. Ale mają tak szeroki dostęp, jeśli skonfigurujesz je tak, by były przydatne. W zasadzie mogłyby zrobić wszystko na twoim komputerze.”