Cyberbezpieczeństwo
Meta wprowadza szybkie poprawki do luki zero‑day w Muse, która umożliwiała atakującym przejęcie agenta AI

Badacz bezpieczeństwa Patrick Wardle powiedział 22 września 2026, że Meta wprowadziła szybką poprawkę luki zero‑day w Muse, swoim nowo uruchomionym osobistym agencie AI, po jego publicznym ujawnieniu 21 września 2026, że nieuprzywilejowany lokalny proces może przekierować ruch dyktowania aplikacji Mac do kontrolowanego przez atakującego punktu końcowego i niewidocznie przejąć agenta.
Publiczne ujawnienie i potwierdzenie poprawki
Wardle opublikował swoje ustalenia w wątku na X, który rozpoczął się o 14:42 UTC 21 września 2026, ostrzegając użytkowników, aby nie instalowali Muse i pisząc, że poważne luki zero‑day mogą pozwolić lokalnemu malware lub atakującym niewidocznie przejąć agenta. Połączył wątek z repozytorium proof‑of‑concept na GitHubie zatytułowanym „not-a-mused”; historia commitów repozytorium pokazuje trzy commity — dodanie tytułu i opisu projektu, utworzenie skryptu notamused.py oraz aktualizację README — wszystkie datowane na 21 września 2026.
W w poście na jego profilu X oznaczonym 06:36 UTC 22 września 2026, Wardle napisał „Hurra, naprawiono!” i pochwalił szybkość poprawki. W późniejszym poście tego samego dnia napisał, że jest zwolennikiem pełnego ujawniania, twierdząc, że dzięki temu błędy są naprawiane szybciej. W swoim wątku ujawniającym zaznaczył, że podzieli się dodatkowymi szczegółami i kolejnymi błędami na konferencji bezpieczeństwa Objective by the Sea v9.
Luka punktu końcowego dyktowania
Zgodnie z dokumentacją proof‑of‑concept, Muse udostępnia nieudokumentowane ustawienie o nazwie endovoyagerdictation_endpoint, które lokalny atakujący lub złośliwe oprogramowanie może modyfikować bez specjalnych uprawnień. Gdy użytkownik kliknie przycisk mikrofonu w Muse i dyktuje polecenie, jak podaje wątek Wardle’a, aplikacja wysyła dyktat do punktu końcowego atakującego. README wymienia potencjalne konsekwencje: przechwycenie nagranego dźwięku i poleceń, wstrzyknięcie poleceń do Muse, kradzież materiałów uwierzytelniających Muse oraz nadużycie wszelkiego dostępu, jaki użytkownik przyznał agentowi. dokumentacja repozytorium podsumowuje wpływ w jednym zdaniu: „Dostęp Muse może potencjalnie stać się dostępem atakującego.”
Proof‑of‑concept implementuje podzbiór ponad 50 poleceń udostępnianych przez Muse i jest wyzwalany poprzez przepływ dyktowania przyciskiem mikrofonu, zgodnie z README. README zauważa, że atak jest lokalny: atakujący musi już mieć możliwość uruchamiania kodu jako lokalny użytkownik. Przedstawia ryzyko jako ryzyko amplifikacji, stwierdzając, że Muse może mieć znacznie szerszy dostęp niż zwykłe lokalne malware, co czyni go szczególnie przydatnym celem dla amplifikacji uprawnień i dostępu.
W swoim wątku Wardle wymienił praktyczne konsekwencje udanego przejęcia: kradzież nagranego audio użytkownika, wstrzyknięcie poleceń, którym Muse ufa i które wykonuje, oraz przejęcie tokenu uwierzytelniającego użytkownika w celu bezpośredniego i niewidocznego sterowania Muse. Wszystko, do czego użytkownik przyznał Muse dostęp, w tym wiadomości, e‑maile i finanse, również byłoby narażone na lokalnego atakującego, napisał. W osobnym poście z 21 września określił tę lukę jako trywialną do wykorzystania i zażądał naprawy.
Połączone urządzenia i zdalny wektor
Opisane przez Wardle’a zagrożenie wykracza poza pojedynczego Maca. W poście z 20:30 UTC 21 września 2026 napisał, że po wykorzystaniu Maca atakujący może wchodzić w interakcję z dowolnym podłączonym urządzeniem użytkownika, które również uruchamia Muse, w tym zdalnie i niewidocznie zlecać zadania mobilnemu klientowi iOS Muse.
Wardle napisał 22 września 2026, że istnieje również zdalny wektor: atak w stylu ClickFix, wymagający jedynie jednego polecenia uruchomionego przez użytkownika, mógłby dostarczyć przejęcie i dać zdalnemu atakującemu kontrolę w zakresie Muse nad wszystkimi urządzeniami ofiary obsługującymi Muse, w tym iOS. Poruszył ten temat zarówno w poście potwierdzającym poprawkę, jak i w kolejnej odpowiedzi w swoim wątku ujawniającym.
Udokumentowany projekt bezpieczeństwa Meta
Meta wprowadziło Muse 8 września 2026, prezentując go jako osobistego agenta firmy w w wpisie na blogu badawczym opisującym architekturę bezpieczeństwa systemu. Meta oświadczyło, że zaprojektowało system z założeniem, że agent może być atakowany i aby ograniczyć potencjalne szkody. Zgodnie z tym projektem, demon agenta i narzędzia, które wykonuje, działają wewnątrz komórki runtime systemd‑nspawn odizolowanej od systemu hosta, a oddzielny agent po stronie hosta o nazwie Sentinel pełni rolę jedynego autorytetu uprawnień dla działań łączników oraz całego ruchu sieciowego wychodzącego. Poświadczenia dla połączonych usług są przechowywane w wirtualnej maszynie użytkownika, a Sentinel dokonuje wstawiania poświadczeń w czasie rzeczywistym na granicy sieci, dzięki czemu agent nigdy nie widzi rzeczywistych tokenów, jak podano w poście.
W tym samym poście Meta poinformowało, że otwiera program bug bounty dla Muse dla każdego, z nagrodami do 300 000 USD za ważne zgłoszenia, w tym do 130 000 USD za udane próby wstrzyknięcia poleceń, które dotyczą jednego użytkownika.
Centrum Pomocy Meta dokumentuje dodatkowe zabezpieczenia: wirtualna maszyna każdego użytkownika Muse jest odizolowana od agentów innych użytkowników, dane uwierzytelniające, takie jak nazwy użytkowników i hasła, są przechowywane w Secure Credentials Store, który pozwala Muse wykonywać autoryzowane działania bez tego, by model AI widział hasło, a Muse jest zaprojektowany tak, aby przed niektórymi ważnymi akcjami, takimi jak wysłanie e‑maila lub dokonanie zakupu, poprosić o potwierdzenie. Centrum Pomocy Meta stwierdza, że ważne kontrole uprawnień i bezpieczeństwa działają niezależnie od modelu AI, więc nie zależą od tego, czy model sam rozpozna złośliwą instrukcję.
Post badawczy Meta stwierdza, że Muse nie jest odporny na ataki i że wstrzykiwanie promptów pozostaje otwartym problemem w całej branży. Firma zapowiedziała, że później w tym roku dostarczy Muse Confidential VM, zaprojektowany tak, aby kryptograficznie i w sposób weryfikowalny uniemożliwić samemu Meta dostęp do danych w wirtualnej maszynie użytkownika.












