CVE-2026-46414: Microsoft UFO WebSocket Flaw

How to Detect It

Detection should focus on mismatches between the role and identity established during WebSocket registration and the values later supplied in task messages. A legitimate client that registers as a normal device should not subsequently submit tasks identifying itself as constellation. A device should not normally target unrelated peers without an authorized workflow explaining the relationship.

Review application and reverse-proxy logs for WebSocket registration, task submission, and client-registry replacement events. The exact log field names depend on the UFO deployment and logging configuration, so the following patterns are investigative indicators rather than guaranteed literal output:

client_type="constellation"
target_id="<device-not-associated-with-session>"
duplicate client_id
client registry replaced
WebSocket registration
TASK

A basic search across exported logs could begin with:

grep -E 'client_type="?constellation"?|duplicate[ _-]+client_id|registry.*replac|target_id' ufo*.log

For structured JSON logs, adapt the query to the actual schema. A SIEM rule should alert when the registered role differs from the task role, when a task target is not in the client’s authorized target set, or when a second WebSocket registers an already active client_id:

event.category = "websocket"
AND (
  task.client_type = "constellation"
  AND registration.client_type != "constellation"
  OR registration.client_id = prior_active_registration.client_id
  OR task.target_id NOT IN registration.authorized_targets
)

Network monitoring can identify unexpected clients reaching the WebSocket endpoint, but encrypted WebSocket traffic will limit payload inspection unless TLS is terminated at a controlled proxy. Record source address, authenticated session or token identifier where safe, connection time, client_id, registration role, task action, and target device. Avoid logging raw shared tokens.

During incident review, correlate:

• A new connection with an existing client_id.
• A role change that occurs only inside a task message.
• Tasks sent from a device that should not control the target.
• Unusual bursts of task messages across multiple devices.
• WebSocket connections originating outside the management network.
• Shared-token rotation or configuration changes preceding suspicious activity.

Mitigation and Patching

The immediate remediation is to apply the fixed UFO release or commit identified in Microsoft’s security advisory:

• GHSA-qgx6-cvhg-jw7p: https://github.com/microsoft/UFO/security/advisories/GHSA-qgx6-cvhg-jw7p

The supplied NVD data does not state a fixed version number. Do not invent or assume one. The vulnerable state explicitly identified by NVD is 3.0.1-4-ge2626659; administrators should compare their deployed revision with the advisory’s authoritative affected and patched metadata before declaring the issue resolved.

First inventory the installed source revision or package contents, then update using the project’s documented installation method. For a source checkout, a controlled workflow may look like:

git -C /path/to/UFO fetch --tags origin
git -C /path/to/UFO log -1 --oneline
# Check the advisory for the fixed tag or commit before running:
git -C /path/to/UFO checkout <FIXED_TAG_OR_COMMIT>
python -m pip install -e /path/to/UFO

Replace <FIXED_TAG_OR_COMMIT> only after confirming the value in Microsoft’s advisory. If UFO is managed through a package or internal build pipeline, promote the vendor-fixed package through staging, verify the resulting revision, and restart the affected control-plane services according to the deployment’s operational procedures.

Until the fixed version is verified, reduce exposure:

1. Restrict the WebSocket control plane to a dedicated management network or allowlist.
2. Block direct Internet access to the endpoint.
3. Limit the shared server token to authorized clients and rotate it if exposure is possible.
4. Separate device groups where practical to reduce peer-task impact.
5. Disable or stop the control-plane service if it is not required.
6. Preserve relevant logs before making changes if compromise is suspected.

The server-side fix should enforce role and target authorization from connection state and reject client-supplied escalation. It should also reject duplicate client_id registrations or require an explicit, authenticated replacement procedure. As a temporary defensive control, an authorization-aware proxy may be placed in front of the WebSocket endpoint, but a generic reverse proxy or network ACL will not correct forged task fields from an otherwise authorized client.

After patching, test the control plane with a non-privileged account or test client. Confirm that a normal device cannot submit a task declaring client_type="constellation", cannot target an unauthorized device, and cannot replace an existing registration by reusing its client_id. Rotate shared tokens when appropriate and verify that old tokens no longer establish sessions.

Security teams may also benefit from a documented tabletop exercise covering token compromise, unauthorized peer tasks, and control-plane isolation.

References

The primary vendor reference is Microsoft’s GitHub Security Advisory:

• GHSA-qgx6-cvhg-jw7p

The NVD record provides the CVE identifier, High severity rating, affected code state, and vulnerability description:

• NVD: CVE-2026-46414

CISA’s catalog can be used to verify KEV status. At the time of the supplied assessment, CVE-2026-46414 was not listed:

• CISA Known Exploited Vulnerabilities Catalog

For operational reporting, preserve the exact deployed UFO revision, the advisory’s fixed version or commit once confirmed, the retrieved NVD CVSS vector, token-rotation actions, and evidence that unauthorized role and target combinations are rejected.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.