CVE-2026-46544
Description
Microsoft UFO open-source framework for intelligent automation across devices and platforms. In 3.0.1-4-ge2626659, Microsoft UFO accepts client-supplied session_id values in WebSocket task messages and reuses an existing in-memory session object if that session_id already exists. If a prior session has completed and remains in memory with populated results, a different authenticated client can send a new TASK message using the same session_id. The server re-enters the existing session object and sends the stale stored result to the new requester through the normal send_task_end() callback path. This is an authenticated cross-client stale result replay issue. The issue requires that the attacker knows or can predict a live or recently completed session_id.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Microsoft UFO 3.0.1-4-ge2626659 accepts client-supplied session IDs, allowing an authenticated attacker to replay stale task results from another session.
Vulnerability
Microsoft UFO version 3.0.1-4-ge2626659, an open-source framework for intelligent automation, contains a session ID reuse vulnerability in its WebSocket task handling. The server accepts a session_id value directly from client messages without validation. If the provided session_id matches an existing in-memory session that has completed and retains results, the server re-enters that session object and sends the stale stored result to the new requester via the send_task_end() callback [1]. This occurs because all WebSocket clients share a global SessionManager and there is no ownership, creator, or client binding check before reusing a session [1].
Exploitation
An attacker must be an authenticated client of Microsoft UFO and know or predict a live or recently completed session_id [1]. In some UFO paths, session IDs are application identifiers rather than server-generated secrets, making prediction easier [1]. The attacker then sends a WebSocket TASK message that includes the target session_id. The server reuses the corresponding in-memory session object and delivers the stale result from the original session to the attacker [1]. No additional privileges or specific network position beyond authenticated WebSocket access are required.
Impact
A successful attack results in an authenticated cross-client stale result replay. The attacker gains access to potentially sensitive task results from another user's session, leading to unauthorized information disclosure [1]. The attacker does not escalate privileges but receives data intended for a different authenticated client [1].
Mitigation
Microsoft has not yet released a patched version as of the publication date (2026-05-27). The advisory recommends implementing ownership checks on session reuse, such as binding sessions to the originating client ID or generating server-side session IDs that are not client-controlled [1]. Users should apply any future patch from the vendor and consider monitoring WebSocket traffic for unexpected session ID reuse [1].
AI Insight generated on May 27, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2Patches
0No patches discovered yet.
Vulnerability mechanics
Root cause
"Missing client-ownership check on session reuse allows stale results to be replayed to a different authenticated requester."
Attack vector
An authenticated WebSocket client sends a TASK message with a `session_id` that matches a prior completed session still held in the shared in-memory store [ref_id=1]. The server reuses the existing session object and, because the session is already finished, sends the stale stored result to the new requester via the normal `send_task_end()` callback path [ref_id=1]. The attacker must know or predict a live or recently completed `session_id`; in some UFO paths these IDs are application identifiers (e.g. `constellation-demo@task_001`) rather than server-generated secrets, making them easier to guess [ref_id=1]. The attacker also needs a valid shared server authentication token, so this is an authenticated cross-client session isolation issue [ref_id=1].
Affected code
The vulnerability spans three components. `ufo/server/ws/handler.py` accepts a client-supplied `session_id` without validation [ref_id=1]. `ufo/server/services/session_manager.py` reuses an existing session object solely by `session_id` key, with no ownership or creator check [ref_id=1]. The same module does not remove completed sessions from `self.sessions`, allowing stale results to persist in memory [ref_id=1].
What the fix does
No patch is included in the bundle. The advisory recommends that the server should reject reuse of a `session_id` created by another client, or bind session reuse to the original authenticated creator or device [ref_id=1]. The root cause is that `SessionManager.get_or_create_session()` returns an existing session based only on `session_id` without verifying client identity, and completed sessions are never removed from `self.sessions` [ref_id=1]. A proper fix would add a creator/owner field to each session and check it on reuse, or clear finished sessions from the store immediately upon completion [ref_id=1].
Preconditions
- authAttacker must be an authenticated WebSocket client with a valid shared server token
- inputAttacker must know or predict a session_id that belongs to a prior completed session still in memory
- configA prior victim session must have completed and its results must remain in the shared in-memory session store
Reproduction
The bundle includes a full PoC script. Clone the UFO repo at commit `e2626659`, save the PoC as `/tmp/ufo_session_id_reuse_poc.py`, set `UFO_REPO_ROOT` to the checkout path, and run `python -B /tmp/ufo_session_id_reuse_poc.py`. The script stubs a completed session with victim results under a known `session_id`, then sends a TASK message reusing that ID from an attacker client. On success it prints `HIT: reused session_id caused the server to replay a prior session result to a new requester` followed by the leaked result [ref_id=1].
Generated on May 27, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
1News mentions
0No linked articles in our index yet.