CVE-2026-105790 in UFO
Summary
by MITRE • 10/06/2026
Microsoft UFO is an open-source framework for intelligent automation across devices and platforms. Prior to 3.0.9, 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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified within Microsoft UFO prior to version 3.0.9 represents a significant flaw in the application’s WebSocket connection handling logic, specifically concerning how pinned addresses are validated during the upgrade process. As an open-source framework designed for intelligent automation across diverse devices and platforms, secure communication channels are paramount. The core technical deficiency lies in the implementation of the pin_addresses mechanism within the file aip/transport/websocket.py. While this security control is intended to restrict connections to pre-approved destinations, it was only applied to the initial destination address provided during device registration via the /api/devices endpoint. This incomplete validation scope creates a critical gap that authenticated attackers can exploit by supplying a permitted but attacker-controlled WebSocket endpoint as part of their registration payload.
The operational mechanics of this vulnerability rely on the behavior of the websockets.connect() client used within the framework. When establishing a connection, the client follows cross-origin redirects before finalizing the TCP handshake and upgrading to the WebSocket protocol. Crucially, Galaxy performs its post-handshake peer-IP validation only after these redirect operations have occurred. This timing discrepancy allows an attacker to leverage HTTP 3xx redirects to bypass the initial address pinning check. By directing the connection through a controlled intermediary or using DNS rebinding techniques in conjunction with valid but misleading endpoints, the client establishes a new TCP connection that appears legitimate during the handshake phase. Consequently, the framework proceeds with the WebSocket upgrade request to internal hosts that are reachable from the server’s network environment but were not explicitly authorized for direct communication.
The impact of this vulnerability is primarily limited to enabling unauthorized internal connections and facilitating initial handshake requests against services within the local network or cloud infrastructure accessible by the vulnerable server. It does not, however, result in arbitrary HTTP method execution, disclosure of sensitive response bodies, establishment of a complete Application Intelligence Platform session, or access to cloud metadata endpoints. This distinction is vital for risk assessment, as it indicates that while lateral movement and internal reconnaissance are possible, direct data exfiltration or full system compromise via this specific vector requires additional exploitation steps beyond the initial connection establishment. The vulnerability effectively serves as an entry point for network-level attacks against backend services rather than a direct application-layer breach of confidentiality or integrity at the session level.
From a standards perspective, this flaw aligns with CWE-295 Improper Certificate Validation and CWE-807 Reliance on Untrusted Inputs in Security Decision Code. The failure to validate the final destination IP address against the pinned list after following redirects is a classic example of relying on input validation at an incorrect stage of the request lifecycle. In terms of adversary tactics, this behavior facilitates ATT&CK technique T1557 Adversary-in-the-Middle or potentially T1046 Network Service Discovery if used to map internal services. The attacker utilizes the trusted application as a proxy to interact with internal assets that would otherwise be inaccessible from external networks, effectively bypassing network segmentation controls through protocol-level manipulation.
Mitigation for this vulnerability requires immediate upgrading to Microsoft UFO version 3.0.9 or later, where the pin_addresses logic has been corrected to apply strictly after all redirect resolutions and before any WebSocket upgrade requests are sent. For organizations unable to patch immediately due to dependency constraints, network-level controls such as strict firewall rules restricting outbound connections from the application server to only known internal endpoints can provide a compensating control. Additionally, implementing egress filtering that inspects HTTP headers for Location directives during redirects can help detect and block attempts to redirect WebSocket upgrades to unauthorized destinations. Continuous monitoring of outbound connection logs for unusual patterns or unexpected IP addresses associated with WebSocket traffic is also recommended to identify potential exploitation attempts in real-time.