CVE-2026-55545: Yamcs: WebSocket subscription handlers omit the privilege checks their REST siblings enforce
Asset / scope: Yamcs 5.12.7 WebSocket topics (packets, algorithm-status, mdb-changes)
Summary
Several WebSocket subscription handlers do not perform the privilege check that their REST counterparts enforce, so a principal subscribing over WebSocket receives data the REST API would have scoped or denied.
Root cause
- packets (PacketsApi.subscribePackets) performs no ReadPacket check, while the REST siblings do (listPackets:128, streamPackets:256, subscribeContainers:538). A principal with a narrow ReadPacket scope receives the raw binary of all TM packets on the processor. - algorithm-status (ProcessingApi.subscribeAlgorithmStatus) performs no check, while REST getAlgorithmStatus enforces checkObjectPrivileges(ReadAlgorithm, ...) (:467). - mdb-changes (MdbOverrideApi.subscribeMdbChanges) performs no check, while base MDB reads require GetMissionDatabase.
Remediation
Bring each WebSocket subscription handler to parity with its REST sibling's privilege check (ReadPacket, ReadAlgorithm, GetMissionDatabase). This is the same declarative fail-closed fix as Report 1.
Supporting material
Subsystem source audit of the WS-vs-REST authorization parity. Available on request.
--
Disclosure and credit
This was found by Cipher / Causal Security - https://causalsecurity.com/. We are coordinating disclosure via this report and request CVEs where you agree they qualify. We propose the 90-day window stated in your security policy. We might publish a write-up after a fix and the agreed window.
Other sources
Yamcs is a mission control framework. Prior to 5.12.8 and 5.13.2, Yamcs WebSocket subscription handlers fail to enforce the privileges required by equivalent REST endpoints. PacketsApi.subscribePackets exposes the packets WebSocket topic without ObjectPrivilegeType.ReadPacket, ProcessingApi.subscribeAlgorithmStatus exposes the algorithm-status WebSocket topic without ObjectPrivilegeType.ReadAlgorithm, and MdbOverrideApi.subscribeMdbChanges exposes the mdb-changes WebSocket topic without SystemPrivilege.GetMissionDatabase. A low-privilege authenticated user can receive telemetry packets, algorithm status, and mission database change information outside the assigned authorization scope. This issue is fixed in versions 5.12.8 and 5.13.2.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/org.yamcs:yamcs-coreto a version that resolves this vulnerability.Fixed in 5.13.2 - Upgrade
Upgrade
maven/org.yamcs:yamcs-coreto a version that resolves this vulnerability.Fixed in 5.12.8 - Upgrade
Upgrade
Yamcsto a version that resolves this vulnerability.Fixed in 5.12.8 - Upgrade
Upgrade
Yamcsto a version that resolves this vulnerability.Fixed in 5.13.2
Event History
Frequently Asked Questions
What level of access does an attacker need?
The attacker needs a low-privileged authenticated principal that can establish WebSocket subscriptions. No user interaction is required.
Which data could be exposed beyond the principal's intended permissions?
The packets subscription can expose raw binary telemetry packets from the processor even to a principal with only a narrow ReadPacket scope. The algorithm-status and mdb-changes subscriptions can also return data without the ReadAlgorithm and GetMissionDatabase checks enforced by comparable REST endpoints.
Are REST API permission checks sufficient to prevent this exposure?
No. The affected WebSocket handlers do not apply the corresponding REST privilege checks, so restricting access through the REST endpoints alone does not prevent unauthorized data disclosure over WebSocket.
What can be done if the handlers cannot immediately be fixed?
Restrict or disable access to the affected WebSocket subscription topics for principals that should not receive packet, algorithm-status, or mission-database data. The required code remediation is to enforce ReadPacket, ReadAlgorithm, and GetMissionDatabase checks in the corresponding subscription handlers.