GHSA-fwww-cp23-7f5g: Medium severity maven/org.yamcs:yamcs-core vulnerability
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.
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
Event History
Frequently Asked Questions
Who can exploit this issue?
An authenticated principal with permission to establish the affected WebSocket subscriptions can exploit it. The advisory indicates that low privileges are sufficient, and the missing checks can expose data beyond the principal's intended REST API scope.
What data can be exposed through the affected subscriptions?
The packets subscription can disclose raw binary telemetry packets from all TM packets on the processor to a principal with only a narrow ReadPacket scope. The algorithm-status and mdb-changes subscriptions can also return information without the ReadAlgorithm and GetMissionDatabase checks required by their REST equivalents.
Are REST API requests affected in the same way?
No. The described authorization gaps are in the WebSocket subscription handlers; the corresponding REST endpoints enforce the relevant ReadPacket, ReadAlgorithm, or GetMissionDatabase privilege checks.
What should be changed to remediate the issue?
Apply the fix that makes each affected WebSocket handler enforce the same privilege check as its REST counterpart: ReadPacket for packets, ReadAlgorithm for algorithm status, and GetMissionDatabase for MDB changes.