GHSA-fwww-cp23-7f5g Yamcs's WebSocket subscription handlers omit the privilege checks their REST siblings enforce

• Maven org.yamcs:yamcs-core: < 5.12.8 → fixed in 5.12.8 • Maven org.yamcs:yamcs-core: >= 5.13.0, < 5.13.2 → fixed in 5.13.2

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.