CVE-2026-105792 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, 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 calls SessionManager.get_result() to acquire the same lock again when the task name maps to a session. An authenticated caller who knows or creates a mapped task name can therefore block the request indefinitely, and in the default single-process server configuration the blocked event-loop thread prevents other HTTP, WebSocket, and dependent background interactions. Unknown task names do not reach the nested call and are not affected. This issue is fixed in version 3.0.9.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
The vulnerability identified in Microsoft UFO prior to version 3.0.9 represents a classic Reentrant Locking flaw that leads to Denial of Service conditions within the application's server architecture. The core technical defect resides in the implementation of the SessionManager class, specifically within the get_result_by_task method located in ufo/server/services/session_manager.py. This function is responsible for handling requests directed at the /api/task_result/{task_name} endpoint. When a request arrives with a task name that maps to an existing session, the code attempts to acquire a non-reentrant lock associated with that specific session object. The critical error occurs immediately after this initial acquisition, as the method subsequently calls SessionManager.get_result(), which internally attempts to acquire the exact same non-reentrant lock again on the same thread and context.
In standard concurrency models, particularly those utilizing asynchronous event loops common in modern Python web frameworks like FastAPI or Starlette, locks are designed to prevent race conditions by ensuring mutual exclusion. However, a non-reentrant lock does not allow the same thread that already holds it to acquire it again without first releasing it. Because the calling function and the called method operate within the same execution context on the event loop thread, this nested acquisition results in an immediate deadlock. The thread blocks indefinitely waiting for a condition that can never be met because it is holding the very resource required to proceed. This behavior effectively freezes the processing of requests associated with that specific session lock.
The operational impact of this vulnerability is severe within the default single-process server configuration provided by Microsoft UFO. Since the event loop operates on a single thread, blocking one request prevents the execution of all other concurrent operations managed by that same loop. Consequently, not only does the targeted HTTP request hang indefinitely, but it also stalls WebSocket connections and dependent background tasks that rely on the same event loop for processing. This creates a cascading failure where an authenticated user can effectively take down the entire service instance simply by triggering this specific endpoint with a known or created task name mapped to a session. The vulnerability is strictly limited to cases where the task name maps to an existing session; requests involving unknown task names bypass the nested call and remain unaffected, limiting the scope of exploitation but not its severity for targeted sessions.
From a classification perspective, this issue aligns with CWE-833, Deadlock, which describes situations where two or more processes are each waiting for the other to release a resource, resulting in all processes being permanently blocked. In terms of attack vectors and techniques, this vulnerability can be mapped to MITRE ATT&CK technique T1499, Endpoint Denial of Service, specifically under sub-techniques involving application exhaustion or service disruption through logical flaws rather than resource consumption attacks like flooding. The attacker leverages a logic error in synchronization primitives to achieve availability impact without requiring elevated privileges beyond standard authentication.
Mitigation for this vulnerability requires an immediate upgrade to Microsoft UFO version 3.0.9, where the locking mechanism has been corrected to prevent nested acquisition on non-reentrant locks. For organizations unable to patch immediately due to dependency constraints or testing requirements, alternative mitigation strategies should focus on isolating session management from the main event loop if possible, although this may require significant architectural changes. Implementing a timeout mechanism for lock acquisition can also help mitigate indefinite blocking by allowing the system to fail fast rather than hang indefinitely, though this is less robust than fixing the root cause in the codebase. Security teams should audit other areas of the application that utilize session management and locking primitives to ensure similar reentrant issues do not exist elsewhere in the framework's server-side logic.