CVE-2026-105793

W Microsoft UFO przed wersją 3.0.9, endpoint /api/task_result/{task_name} wywołuje SessionManager.get_result_by_task() w pliku ufo/server/services/session_manager.py, który pozyskuje nieodnawialny lock i ponownie go próbuje, gdy nazwa zadania mapuje się na sesję. Uwierzytelniony atakujący może zablokować żądanie na czas nieokreślony, a w domyślnej konfiguracji jednego procesu zablokowany wątek uniemożliwia obsługę innych żądań HTTP, WebSocket i zależnych działań.

Narzędzie run_shell w komponencie CommandLineExecutor w Microsoft UFO przed wersją 3.0.9 waliduje tylko pierwszy token parametru bash_command i zezwala na explorer.exe. W systemie Windows explorer.exe przekazuje kolejny argument ścieżki do ShellExecute, co pozwala na uruchomienie dowolnego pliku wykonywalnego lub skryptu jako użytkownik pulpitu, mimo że podproces używa shell=False.

Microsoft UFO przed wersją 3.0.9 zawiera podatność związaną z uwierzytelnioną rejestracją urządzenia przez /api/devices, która może dostarczyć kontrolowany przez atakującego punkt końcowy WebSocket, podczas gdy aip/transport/websocket.py stosuje pinned_addresses tylko do początkowego miejsca docelowego. Pinned websockets.connect() klient podąża za przekierowaniami między domenami i otwiera nowe połączenie TCP przed walidacją IP peer przez Galaxy, co pozwala na żądania uaktualnienia WebSocket do wewnętrznych hostów dostępnych z serwera. Potwierdzony wpływ to wewnętrzne połączenie i żądanie uaktualnienia, bez ustanawiania dowolnych metod HTTP, ujawniania treści odpowiedzi, ukończonej sesji AIP ani dostępu do metadanych chmury. Problem naprawiono w wersji 3.0.9.

W narzędziu execute_command w Microsoft UFO (plik linux_mcp_server.py) polecenia sort i uniq są traktowane jako tylko do odczytu, mimo że ich opcje pozwalają na zapis do plików. Uwierzytelniony użytkownik może użyć sort -o lub drugiego argumentu uniq, aby tworzyć lub nadpisywać pliki z uprawnieniami procesu serwera UFO, bez użycia metaznaków powłoki. Podatność naprawiono w wersji 3.0.9.

Microsoft UFO przed wersją 3.0.10 zawiera podatność w narzędziach type_text i launch_app, gdzie parametry tekst i nazwa pakietu są przekazywane do poleceń adb shell bez odpowiedniej walidacji. Atakujący z ważnym kluczem API Mobile MCP może wykonać dodatkowe polecenia na autoryzowanym urządzeniu jako użytkownik Android shell.

W frameworku Microsoft UFO przed wersją 3.0.7, handler COMMAND_RESULTS wywołuje funkcję get_or_create_session bez parametru owner_client_id, co pozwala uwierzytelnionemu klientowi na utworzenie sesji o dowolnej nazwie (np. constellation_task_id = f"{task_name}@{task_id}"). Może to prowadzić do odmowy dostępu prawowitemu właścicielowi lub wyczerpania pamięci przez tworzenie fikcyjnych sesji.

Framework Microsoft UFO przed wersją 3.0.8 udostępnia usługi MCP Streamable HTTP na portach TCP 8020 i 8021 bez uwierzytelnienia. Pozwala to nieuwierzytelnionemu zdalnemu atakującemu na wywoływanie funkcji takich jak przechwytywanie ekranu, dotknięcia, przesunięcia, wpisywanie tekstu, uruchamianie aplikacji i modyfikowanie stanu urządzenia z podłączonym Androidem.

Microsoft UFO, framework open-source do inteligentnej automatyzacji, przed wersją 3.0.8 zawiera serwer MCP na localhost:8010, który nie waliduje nagłówków Host, Origin ani Sec-Fetch-Site. Strona internetowa kontrolowana przez atakującego może użyć DNS rebinding, aby uzyskać dostęp do lokalnego punktu /mcp, wyliczyć schematy narzędzi i wywołać execute_command z ważnym kluczem UFO_MCP_API_KEY, co pozwala na odczyt plików lub wykonanie dozwolonych poleceń systemowych jako użytkownik ofiary. Problem został naprawiony w wersji 3.0.8.

Framework Microsoft UFO przed wersją 3.0.8 nie blokuje prefiksów NAT64, 6to4 i Teredo oraz nie sprawdza ponownie osadzonych adresów IPv4, co pozwala zdalnemu atakującemu ominąć zabezpieczenie SSRF i uzyskać dostęp do metadanych chmury, wewnętrznych usług lub localhost.

W frameworku Microsoft UFO w wersjach od 3.0.0 do 3.0.6 wykryto podatność polegającą na braku autoryzacji na poziomie obiektu. Klient podłączony jako URZĄDZENIE do serwera WebSocket mógł wysłać żądanie DEVICE_INFO_REQUEST z identyfikatorem innego urządzenia i uzyskać jego dane systemowe.