Listen to this Post
CVE-2026-55548 exposes a critical broken access control flaw in Yamcs, an open‑source mission control framework used by space agencies and satellite operators. The vulnerability resides in the `PacketsApi.exportPackets` endpoint (yamcs-core/src/main/java/org/yamcs/http/api/PacketsApi.java). Under normal operation, this endpoint is designed to export raw telemetry packets, but it must enforce object‑level `ReadPacket` privileges to ensure that users can only access packets they are authorised to see.
The root cause lies in how the endpoint handles the request’s packet name list. When a client submits an `ExportPacketsRequest` with an explicit list of packet names, the code calls `ctx.checkObjectPrivileges(ObjectPrivilegeType.ReadPacket, nameSet)` to verify that the authenticated user has the `ReadPacket` privilege for each named packet. However, if the request omits the packet names entirely – i.e., the `nameSet` is empty – the `checkObjectPrivileges` call receives an empty set and silently passes without throwing any exception. This is the first fatal flaw: the authorisation check is effectively skipped when no names are provided.
Because the privilege check succeeded (trivially) on an empty set, the endpoint proceeds to build the database query. The code constructs a SQL `SELECT FROM tm` statement. Normally, when packet names are supplied, a `WHERE pname IN (…)` clause is added to filter the results. But with an empty name list, no such filter is applied – the query returns every telemetry packet stored in the archive, regardless of whether the user has any right to view them.
The second flaw compounds the first: the `onTuple` handler that streams each retrieved packet back to the client does not perform any per‑row authorisation check. Even if a user lacks `ReadPacket` privileges for specific packets, the system streams them unconditionally. There is no additional filter or post‑query validation. As a result, a low‑privileged or even zero‑privilege authenticated user (e.g., a guest account with no explicit object privileges) can issue a single HTTP request to `/api/packets/export` with an empty `name` field and dump the entire raw telemetry packet archive.
The impact is severe: telemetry packets often contain sensitive mission data, spacecraft health status, command acknowledgements, and potentially proprietary or classified information. By bypassing the role‑based access control (RBAC) model, an attacker can exfiltrate massive amounts of historical and real‑time telemetry, undermining confidentiality and enabling further reconnaissance. The vulnerability is present in all Yamcs versions prior to 5.12.8 and prior to 5.13.2. The fixes in these releases enforce per‑packet `ReadPacket` checks during the export process, ensuring that each packet is authorised before it is streamed.
The CVSSv3.1 score assigned by GitHub, Inc. is 4.3 (Medium) with the vector AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N. The weakness is mapped to CWE‑284 (Improper Access Control) and CWE‑862 (Missing Authorization). The NVD has not yet provided its own CVSS assessment, but the CNA’s score reflects the network‑accessible, low‑complexity nature of the attack, requiring only low‑privileged authentication, with a limited confidentiality impact (no integrity or availability loss).
DailyCVE Form:
Platform: ……. Yamcs
Version: …….. <5.12.8,<5.13.2
Vulnerability :…… Missing Authorization
Severity: ……. 4.3 (Medium)
date: ………. 2026-07-16
Prediction: Patch available now
What Undercode Say:
Analytics – The vulnerability was discovered through a code review of the `PacketsApi.exportPackets` method. The attack vector is trivial: an authenticated user can send a crafted `ExportPacketsRequest` with an empty `name` list. The absence of a `WHERE` clause in the generated SQL and the lack of per‑row checks allow full archive exfiltration. The flaw is reminiscent of classic “missing authorization” bugs where empty input bypasses security logic. The CVSS score of 4.3 underestimates the real‑world impact because telemetry data often has high sensitivity; however, the score is based on the official metrics.
Bash Commands & Codes – To test for the vulnerability, an attacker can use `curl` to call the export endpoint with an empty packet name list:
Export all packets without specifying any names (vulnerable)
curl -X POST "http://<yamcs-host>:8090/api/packets/export" \
-H "Authorization: Bearer <low-privilege-token>" \
-H "Content-Type: application/json" \
-d '{"name": []}' \
--output telemetry_dump.bin
Alternatively, using the Yamcs CLI (if available) with an empty filter:
Using yamcs CLI (if patched, this will fail with 403) yamcs packets export --instance <instance> --name "" --output dump.bin
A successful exploit will return a stream of raw TM packets (in Protobuf or binary format) without any authorisation errors. To verify the fix, the same request on a patched system (≥5.12.8 or ≥5.13.2) should return an HTTP 403 Forbidden or an empty result set when the user lacks privileges.
Exploit:
An attacker with any valid set of credentials (even the default `guest` account, which often has `superuser=false` but still holds an authentication token) can exploit this vulnerability. The steps are:
1. Authenticate to the Yamcs instance (e.g., via `/auth/token` endpoint) to obtain a bearer token.
2. Craft a POST request to `/api/packets/export` with a JSON body containing an empty `”name”: []` array.
3. Receive the server‑side streamed response – the endpoint will execute `SELECT FROM tm` and stream every packet in the archive.
4. Parse the raw telemetry data (often encoded as `TmPacketData` protobuf messages) to extract mission‑critical information.
Because the endpoint uses chunked transfer encoding, the attacker can download the entire archive without triggering size limits. No special privileges are required – the guest or any low‑privileged user can perform this attack.
Protection:
- Upgrade immediately to Yamcs version 5.12.8 or 5.13.2 (or any later release). These versions include the fix that enforces per‑packet `ReadPacket` checks inside
exportPackets. - If upgrading is not possible, apply the following workaround:
- Modify the `PacketsApi.java` source to ensure that if `nameSet` is empty, the endpoint either throws an `AccessDeniedException` or automatically applies a restrictive filter (e.g., only packets the user has explicit `ReadPacket` privileges for).
- Alternatively, disable the `exportPackets` endpoint entirely by removing or commenting out its route in the API configuration (though this may break legitimate functionality).
- Review your RBAC policies: ensure that the default `guest` account does not have any object privileges and that all users are assigned the minimum necessary permissions.
- Monitor logs for unusual `exportPackets` requests with empty `name` fields – this can indicate an attempted exploit.
Impact:
- Confidentiality Breach: An attacker can exfiltrate the entire raw telemetry packet archive, exposing sensitive mission data, spacecraft status, and potentially proprietary algorithms or command sequences.
- Bypass of RBAC: The vulnerability completely bypasses the intended object‑level privilege model, rendering role‑based access controls ineffective for packet data.
- Reconnaissance: Leaked telemetry can be used to understand system behaviour, identify weak points, or plan further attacks (e.g., command injection or mission disruption).
- Reputational and Operational Damage: For organisations using Yamcs in operational space missions, a data leak of this magnitude could compromise mission integrity, violate data protection regulations, and erode trust in the system.
- No Direct Integrity/Availability Impact: The flaw only affects confidentiality; however, the exposed data can be a stepping stone to more destructive attacks.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: nvd.nist.gov
Extra Source Hub:
Undercode
