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

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

Microsoft UFO CVE-2026-46416

MEDIUM

Improper Access Control (CWE-284)

2026-05-27 GitHub_M

Microsoft Authentication Bypass

6.3

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

6.3 MEDIUM

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

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

CVSS VectorGitHub Advisory

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

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

Low

Integrity

Low

Availability

Low

Lifecycle Timeline

Analysis Generated

May 27, 2026 - 22:55 vuln.today

CVE Published

May 27, 2026 - 21:56 nvd

MEDIUM 6.3

DescriptionGitHub Advisory

Microsoft UFO open-source framework for intelligent automation across devices and platforms. In 3.0.1-4-ge2626659, Microsoft UFO creates one shared UFOWebSocketHandler instance and reuses it for multiple authenticated WebSocket connections. The handler stores per-connection protocol objects in mutable instance fields. Each new WebSocket connection overwrites those fields. Later, message handlers send responses through the shared fields instead of through protocol objects bound to the originating connection. As a result, the most recently connected authenticated client can receive protocol responses that belong to another authenticated client.

AnalysisAI

Cross-connection response leakage in Microsoft UFO's WebSocket layer allows an authenticated low-privileged user to receive protocol responses intended for a different authenticated session. The flaw stems from a singleton UFOWebSocketHandler design where per-connection state is stored in shared mutable instance fields, causing each new connection to overwrite the previous connection's protocol object reference. No public exploit or CISA KEV listing exists at time of analysis, but the attack complexity is low and exploitation requires only standard authenticated access to the same UFO instance.

Technical ContextAI

Microsoft UFO is an open-source Python-based intelligent automation framework for multi-device orchestration, exposing a WebSocket API for real-time agent control. The affected component, UFOWebSocketHandler, is implemented as a singleton - a single shared instance servicing all incoming WebSocket connections. Per-connection protocol objects (which encapsulate the transport channel back to a specific client) are stored in mutable instance fields on this shared object rather than in connection-scoped locals or a per-connection map. CWE-284 (Improper Access Control) captures the root cause: access to a connection's response channel is not properly isolated from other connections. When client B connects after client A, client B's protocol object overwrites the shared field; subsequent responses triggered by client A's actions are then dispatched through client B's transport, exposing A's session data to B. The affected CPE is cpe:2.3:a:microsoft:ufo:*:*:*:*:*:*:*:*, with the specific version identified as 3.0.1-4-ge2626659 (a git-describe reference indicating 4 commits past the 3.0.1 tag at commit e2626659).

RemediationAI

The primary remediation is to consult and apply the fix referenced in GitHub Security Advisory GHSA-cwwh-p9rv-4pj4 (https://github.com/microsoft/UFO/security/advisories/GHSA-cwwh-p9rv-4pj4). An upstream fix available via PR or commit is referenced there; a released patched version has not been independently confirmed from the available data, so monitor the advisory for a tagged release. The architectural fix requires refactoring UFOWebSocketHandler from a singleton with mutable instance fields to either per-connection handler instances or a connection-keyed registry (e.g., a dict mapping connection ID to protocol object), ensuring responses are always dispatched through the protocol object bound to the originating connection rather than a shared field. As a compensating control where patching is not immediately possible, restrict UFO WebSocket endpoints to single-user access by enforcing a one-active-connection policy at the network or application layer - this eliminates the concurrent-connection precondition but disables multi-user functionality. Alternatively, deploy UFO in isolated per-user instances (e.g., separate processes or containers per user) so the shared handler never services more than one user's connections; this carries operational overhead but fully mitigates the cross-leakage risk.