What is the CVSS score of CVE-2026-46544?

CVE-2026-46544 has a CVSS 3.1 base score of 5.3 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N. EPSS exploitation probability: 0.0%.

Microsoft UFO CVE-2026-46544

MEDIUM

Authorization Bypass Through User-Controlled Key (CWE-639)

2026-05-27 GitHub_M

Microsoft Authentication Bypass

5.3

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

5.3 MEDIUM

AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N

Attack Vector

Network

Attack Complexity

High

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Analysis Generated

May 27, 2026 - 22:54 vuln.today

CVE Published

May 27, 2026 - 21:53 nvd

MEDIUM 5.3

DescriptionGitHub Advisory

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.

AnalysisAI

Authenticated cross-client stale result replay in Microsoft UFO's WebSocket task handling allows a low-privileged attacker to retrieve another user's completed automation session output. The framework accepts client-supplied session_id values without verifying ownership, so a requester who knows or can predict a prior session's identifier can hijack its stored result via the normal send_task_end() callback path. No public exploit has been identified at time of analysis, and KEV listing is absent, but the High confidentiality impact (C:H) is significant given UFO orchestrates device automation tasks that may capture sensitive screen content, documents, or credentials.

Technical ContextAI

Microsoft UFO is an open-source Python-based agentic framework that automates tasks across Windows applications using LLM-driven agents; it exposes a WebSocket interface for clients to submit automation tasks as TASK messages. The vulnerability is rooted in CWE-639 (Authorization Bypass Through User-Controlled Key): the server uses a client-supplied session_id as a lookup key into an in-memory session store without enforcing ownership or binding sessions to the originating authenticated identity. When a prior session completes and its object remains resident in memory with populated result fields, any authenticated client that submits a TASK message carrying that same session_id causes the server to re-enter the stale object and dispatch its cached output through the standard send_task_end() path. The CPE string cpe:2.3:a:microsoft:ufo:*:*:*:*:*:*:*:* indicates the wildcard version range without a pinned fixed release confirmed in the provided data. The affected build is identified as 3.0.1-4-ge2626659 (a git-describe reference: tag 3.0.1, 4 commits ahead, at commit e2626659).

RemediationAI

The primary fix is to apply the patch referenced in GitHub Security Advisory GHSA-29gc-vqjp-7fqf (https://github.com/microsoft/UFO/security/advisories/GHSA-29gc-vqjp-7fqf); the exact patched release version is not independently confirmed from the available data - verify against the UFO GitHub releases page before upgrading. Until a patched version is deployed, operators should enforce session_id binding to the originating authenticated identity server-side, rejecting TASK messages whose session_id is owned by a different principal. As a compensating control, restrict WebSocket access to the UFO server to a single trusted user or service account per deployment instance, eliminating the cross-client scenario entirely; the trade-off is reduced multi-user concurrency. Alternatively, purge completed session objects from in-memory state immediately upon result delivery, preventing stale result replay; the trade-off is loss of result retrieval for late-joining legitimate clients. Deploying UFO behind an authenticating reverse proxy that injects a verified user identity header and validating it server-side adds a defence-in-depth layer without disrupting existing workflows.