CVE-2026-105789

In Microsoft UFO before version 3.0.9, the /api/task_result/{task_name} endpoint calls SessionManager.get_result_by_task() in ufo/server/services/session_manager.py, which acquires a non-reentrant lock and then attempts to acquire the same lock again when the task name maps to a session. An authenticated attacker can block the request indefinitely, and in the default single-process configuration, the blocked event-loop thread prevents other HTTP, WebSocket, and dependent background interactions.

The run_shell tool in the CommandLineExecutor component of Microsoft UFO before 3.0.9 validates only the first token of the bash_command parameter and permits explorer.exe. On Windows, explorer.exe delegates its following path argument to ShellExecute, allowing an attacker-influenced agent call to launch an arbitrary executable or script as the desktop user even though the subprocess uses shell=False.

Microsoft UFO prior to 3.0.9 has a vulnerability where authenticated device registration through /api/devices can supply a permitted attacker-controlled WebSocket endpoint while aip/transport/websocket.py applies pinned_addresses only to the initial destination. The pinned websockets.connect() client follows cross-origin redirects and opens a new TCP connection before Galaxy performs its post-handshake peer-IP validation, allowing WebSocket upgrade requests to internal hosts reachable from the server. The confirmed impact is the internal connection and handshake request, and does not establish arbitrary HTTP methods, response-body disclosure, a completed AIP session, or cloud metadata access. This issue is fixed in version 3.0.9.

Microsoft UFO prior to 3.0.10 contains a vulnerability in the type_text and launch_app tools where text and package_name parameters are passed to adb shell commands without proper validation. An attacker with a valid Mobile MCP API key can execute additional commands on an authorized device as the Android shell user.

In the Microsoft UFO framework before version 3.0.7, the COMMAND_RESULTS handler calls get_or_create_session without owner_client_id, allowing an authenticated client to create a session with an arbitrary name (e.g., constellation_task_id = f"{task_name}@{task_id}"). This can lead to denial of service for the legitimate owner or memory exhaustion from phantom sessions.

Microsoft UFO prior to version 3.0.9 contains a command injection vulnerability in the press_key tool in ufo/client/mcp/http_servers/mobile_mcp_server.py. The key_code parameter is passed to `adb shell input keyevent`, and the adb client joins arguments into a remote command string, allowing an authenticated Mobile MCP caller to execute additional commands as the Android shell user on an authorized connected device. This requires a valid UFO_MCP_API_KEY, adb on the host, and a reachable authorized device.

Microsoft UFO framework before version 3.0.8 exposes Streamable HTTP MCP services on TCP ports 8020 and 8021 without authentication. This allows an unauthenticated remote attacker to invoke functions such as screenshot capture, taps, swipes, text typing, app launching, and modifying device state on an ADB-connected Android device.

Microsoft UFO, an open-source framework for intelligent automation, prior to version 3.0.8, contains an MCP server on localhost:8010 that does not validate Host, Origin, or Sec-Fetch-Site headers. An attacker-controlled web page can use DNS rebinding to reach the local /mcp endpoint, enumerate tool schemas, and invoke execute_command with a valid UFO_MCP_API_KEY, allowing reading files or executing allowed OS commands as the victim's user. This issue is fixed in version 3.0.8.

Microsoft UFO framework before version 3.0.8 does not block NAT64, 6to4, and Teredo prefixes and does not re-check embedded IPv4 addresses, allowing a remote attacker to bypass the SSRF guard and reach cloud metadata, internal services, or localhost.

In Microsoft UFO framework versions 3.0.0 through 3.0.6, a vulnerability was found due to missing object-level authorization. A client connected as a DEVICE to the WebSocket server could send a DEVICE_INFO_REQUEST with another device's target_id and obtain its system information.