Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-10-06T15:17:15.980Z",
  "pubdate": "2026-10-06T15:17:15.980Z",
  "executiveSummary": "A critical deadlock vulnerability exists in Microsoft UFO prior to version 3.0.9, rooted in the improper management of synchronization primitives within the session handling logic. The vulnerability resides in the /api/task_result/{task_name} endpoint, which utilizes a non-reentrant lock in a nested call pattern, leading to self-deadlock when processing valid task names.\nThis flaw allows an authenticated attacker to induce a persistent Denial-of-Service (DoS) condition. By targeting a known or user-created task name, an attacker can block the application's event-loop thread. Given the default single-process server configuration, this blockage halts all subsequent HTTP requests, WebSocket communications, and background task processing. The vulnerability is highly impactful as it effectively renders the entire application unresponsive, requiring a service restart to recover. Exploitation requires authenticated access to the API and knowledge of a valid task name mapped to a session.",
  "technicalDetails": "The vulnerability is located in ufo/server/services/session_manager.py within the SessionManager.get_result_by_task() function. The root cause is the usage of a non-reentrant lock (e.g., a standard threading.Lock) which does not permit the same thread to acquire the lock multiple times consecutively. The execution flow follows a sequence where the thread initially acquires the lock during the get_result_by_task() process. Subsequently, the code executes a nested call to SessionManager.get_result() while the initial lock remains held.\nUpon reaching the nested call, the logic attempts to acquire the exact same non-reentrant lock again to access the session data. Because the thread already holds the lock and the lock implementation is non-reentrant, the thread enters a state of indefinite blocking, waiting for itself to release the resource. This circular dependency creates a deadlock situation.\nThe attack flow requires an attacker to interact with the /api/task_result/{task_name} endpoint. The attacker must provide a task_name that resolves to an existing session within the SessionManager. If the provided task name is unknown or does not map to an active session, the code path does not trigger the nested function call, thus bypassing the deadlock. However, for any valid, mapped task name, the request handler thread will hang indefinitely.\nThe impact is severe in the default single-process deployment model of Microsoft UFO. Since the server relies on an event-loop architecture, the cessation of the main processing thread results in total service unavailability. All concurrent users are denied access to the API, and background processes dependent on this thread fail to execute. Because the thread remains in a blocked state, the service does not naturally recover, effectively necessitating a manual restart of the application process. Authentication is a prerequisite for exploitation, as the attacker must be capable of interacting with the API and potentially creating or identifying valid session-mapped task names."
}