CVE-2026-54140

W OpenHuman od wersji 0.53.15 do 0.57.5 na macOS plik core_process.rs publikuje w środowisku procesu token bearer OPENHUMAN_CORE_TOKEN, mimo że rdzeń działa jako zadanie w procesie. Inny proces tego samego użytkownika może odczytać to środowisko przez interfejs KERN_PROCARGS2 i odzyskać token wraz z hostem i portem.

W OpenHuman przed wersją 0.57.5 bramka zatwierdzeń używa tokena bearer JSON-RPC jako identyfikatora sesji zatwierdzenia. Powoduje to ujawnienie poświadczenia w zapisanych rekordach zatwierdzeń, zdarzeniach, logach debugowania i odpowiedziach RPC, także podczas normalnej pracy aplikacji desktopowej.

OpenHuman to otwartoźródłowy agent harness dostępny jako aplikacja desktopowa i biblioteka Rust. Przed wersją 0.56.0 na macOS runtime wstrzykiwany do obsługiwanego webview zdalnego konta, takiego jak Google Meet, pozwala JavaScriptowi strony wywołać getDisplayMedia bez aktywnej gestii użytkownika. Zamiast odrzucić żądanie, shim przechodzi do natywnego zachowania przechwytywania Chromium, a osadzone środowisko CEF może automatycznie wybrać główny wyświetlacz, ponieważ brakuje normalnego selektora mediów pulpitu. Jeśli OpenHuman ma już uprawnienie do nagrywania ekranu macOS, a atakujący uzyska wykonanie JavaScriptu w dozwolonym osadzonym origin, może uzyskać rzeczywisty strumień przechwytywania pulpitu bez nowej gestii użytkownika.

W OpenHuman przed wersją 0.57.13 synchronizacja w tle dla podłączonych usług, takich jak e-mail, Slack i Notion, przechowuje surową treść zewnętrzną i umieszcza ją w kontekście modelu autonomicznych agentów bez neutralizacji osadzonych instrukcji. ApprovalGate traktuje wywołania narzędzi bez kontekstu czatu jako wstępnie autoryzowaną automatyzację, więc treść autora atakującego może skłonić model do wywołania akcji Composio bez prośby o zatwierdzenie.

Lokalny endpoint WebSocket /ws/dictation w OpenHuman przed wersją 0.57.44 nie wymaga uwierzytelnienia klienta ani walidacji pochodzenia przeglądarki. Nieuwierzytelniony klient, w tym złośliwa strona internetowa mogąca dotrzeć do endpointu, może przesyłać audio i wywoływać kosztowne przetwarzanie mowy na tekst, a w starszych wersjach także wyczerpać pamięć procesu poprzez nieograniczony bufor.

OpenHuman w wersji przed 0.56.0 udostępnia lokalny endpoint SSE /events bez uwierzytelniania bearer i zezwala na dostęp cross-origin z przeglądarki. Wybór strumienia opiera się wyłącznie na identyfikatorze client_id podanym przez wywołującego, więc nieuwierzytelniony klient lokalny lub złośliwa strona internetowa może subskrybować cudzy strumień i odczytać odpowiedzi asystenta, treści wiadomości, nazwy i argumenty narzędzi oraz surowe wyniki narzędzi.

W OpenHuman przed wersją 0.56.0 serwer chroni żądania HTTP POST do /rpc za pomocą middleware bearer, ale udostępnia handlery Socket.IO rpc:request i chat:start bez równoważnego uwierzytelnienia transportowego lub na poziomie handlera. Lokalny nieuwierzytelniony klient może połączyć się z przestrzenią nazw Socket.IO i wysyłać żądania tą samą chronioną ścieżką kontrolera, która odrzuca brak bearer na /rpc.

W OpenHuman przed wersją 0.57.13 atakujący mogący wysyłać wiadomości do skonfigurowanego kanału zewnętrznego może zmusić agenta do utworzenia trwałych zadań cron powłoki bez zatwierdzenia przez człowieka. Walidacja poleceń pozwala też na wiodące przypisania zmiennych środowiskowych przekierowujące dozwolone polecenia do pomocniczych programów wykonywalnych.

W OpenHuman przed wersją 0.57.13 wiadomość bezpośrednia odebrana przez kanał Yuanbao jest przekształcana w żądanie AgentTurnRequest bez kontekstu interaktywnego zatwierdzenia. ApprovalGate traktuje brak APPROVAL_CHAT_CONTEXT jako turę nieinteraktywną i zezwala na wykonanie node_exec, mimo że domyślna polityka Supervised wymaga zatwierdzenia.

Lista dozwolonych poleceń narzędzia powłoki w SecurityPolicy agenta OpenHuman desktop do wersji 0.54.0 (domyślna polityka Supervised) może zostać ominięta, co umożliwia wykonanie dowolnych poleceń systemu operacyjnego z uprawnieniami użytkownika pulpitu.