CVE-2026-55548 in Yamcs
Summary
by MITRE • 07/16/2026
Yamcs is a mission control framework. Prior to 5.12.8 and 5.13.2, the PacketsApi.exportPackets endpoint in yamcs-core/src/main/java/org/yamcs/http/api/PacketsApi.java failed to enforce object-level ReadPacket privileges when a request omitted specific packet names: with an empty name list the ctx.checkObjectPrivileges(ObjectPrivilegeType.ReadPacket, nameSet) call passed over an empty set, no WHERE pname IN filter was applied to the resulting SELECT * FROM tm query, and the onTuple handler streamed every retrieved packet without any per-row authorization check, so a low-privileged or zero-privilege authenticated user could dump the entire raw telemetry packet archive and bypass the role-based access control model. This issue is fixed in versions 5.12.8 and 5.13.2, which enforce per-packet ReadPacket checks in exportPackets.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/16/2026
The vulnerability in Yamcs affects the PacketsApi.exportPackets endpoint where insufficient authorization controls allowed unauthorized data access through a privilege escalation flaw. This issue existed in versions prior to 5.12.8 and 5.13.2, creating a significant security risk within mission control systems that rely on proper access controls for telemetry data management. The root cause stems from improper object-level privilege enforcement when processing packet export requests that omit specific packet names.
The technical flaw manifests in the PacketsApi.java implementation where the authorization check ctx.checkObjectPrivileges(ObjectPrivilegeType.ReadPacket, nameSet) fails to properly validate access when nameSet is empty. This condition occurs when users submit export requests without specifying particular packet names, causing the system to pass an empty set to the privilege checking mechanism. Consequently, no WHERE clause with pname IN filter gets applied to the database query SELECT * FROM tm, resulting in unrestricted retrieval of all telemetry packets from the archive.
The operational impact of this vulnerability extends beyond simple data exposure, as it completely bypasses the role-based access control model that should protect sensitive mission telemetry. A low-privileged or zero-privilege authenticated user can exploit this flaw to dump the entire raw telemetry packet archive, effectively gaining access to all system telemetry regardless of their assigned permissions. This represents a critical failure in the principle of least privilege and could compromise mission security, especially in environments where telemetry data contains sensitive operational information.
The vulnerability aligns with CWE-284 Access Control Issues, specifically addressing insufficient authorization checks in object-level privileges. From an ATT&CK perspective, this maps to T1078 Valid Accounts and T1566 Phishing, as it enables unauthorized access through legitimate authenticated sessions. The flaw demonstrates a classic case of insecure direct object reference where the system fails to validate user permissions at each access point rather than relying on initial authentication checks.
The fix implemented in versions 5.12.8 and 5.13.2 addresses this by enforcing per-packet ReadPacket checks during export operations, ensuring that even when no specific packet names are provided, individual packet access is validated against user privileges. This remediation enforces proper authorization at the row level rather than the query level, preventing unauthorized bulk data extraction while maintaining system functionality for authorized users. The solution aligns with defensive programming practices and proper access control implementation as recommended in security standards governing mission-critical systems.