Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
16 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Attack type: Unauthenticated remote Impact: Execution of arbitrary JavaScript in a user’s browser. Affected components: extension.matcher.ts:12, extension.component.ts:40, app.component.ts:134. Yamcs is vulnerable to cross-site scripting in the /ext URL endpoint. By inputting specially crafted code into the URL, an attacker can execute arbitrary JavaScript code in a user’s browser. This URL may be sent to a user via a phishing email. <img width="940" height="294" alt="image" src="https://github.com/user-attachments/assets/d886d65c-9bb5-4599-ac11-55db83aafc0e" / Steps to Reproduce: 1. Start a Yamcs instance. 2. Insert the following URL into the browser and press enter (change ‘myproject’ to the name of your instance): 3. You will receive an alert with the number ‘1’ in it. Recommendations: 1. Use document.createElement instead of innerHTML in extension.component.ts. 2. Validate the extension against registered plugin IDs. 3. Enforce a strict custom-element-name regex before mounting.
Recommended action: Upgrade to 5.13.2 or 5.12.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Yamcs compiles StreamSQL query expressions to Java at runtime with Janino. The LIKE operator inserts the user-supplied pattern into the generated Java unescaped, inside a "..." literal, so a pattern containing " breaks out and injects arbitrary Java (e.g. a static{} block that runs an OS command when the compiled filter class loads). Result: RCE as the OS user running Yamcs. The pattern is embedded raw whether it comes from a SQL string literal or a bound ? argument, so the sink is reachable from any endpoint that builds a LIKE from user input, at routine read-only privileges, not just executeSql: - POST /api/archive/{instance}:executeSql and :streamSql (privilege ControlArchiving) - POST /api/archive/{instance}/tables/{table}:readRows via the query field (privilege ReadTables) - GET /api/archive/{instance}/events?q= and the event export/stream variants (privilege ReadEvents) - listActivities q (privilege ReadActivities) The Events page search box feeds q directly.…
Recommended action: Upgrade to 5.13.2 or 5.12.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
templateArgs sent to POST /api/instances (and PATCH /api/instances/{instance}) are written into the rendered instance config as raw text, then parsed as YAML and loaded. Yamcs instantiates each services: entry by its class:, so injecting YAML through a template arg lets you add a services: entry for org.yamcs.ProcessRunner and run a command on the host. The args aren't escaped for YAML or validated server-side. Needs the CreateInstances privilege. With no security.yaml the guest user is superuser=true and the API is unauthenticated, so it's reachable without auth, same default exposure as CVE-2026-46562. The 5.12.7 algorithm-edit fix doesn't touch this path. Details VarStatement appends arg values with no escaping: The only filter, EscapeFilter, does HTML escaping (& < ' ") and leaves newlines, colons and indentation alone, so {{ x | escape }} doesn't help either. InstancesApi.createInstance forwards the args without checking them against the declared variables; the choices /…
Recommended action: Upgrade to 5.13.2 or 5.12.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Attack type: Unauthenticated remote Impact: Attackers can access any system files from the underlying host. Affected components: HttpRequestHandler.java, StaticFileHandler.java An Unauthenticated Directory Traversal vulnerability exists in Yamcs Steps to Reproduce: 1. Start Yamcs and login as a user 2. Paste the following URL in the browser and press enter: ``` http://localhost:8090//etc/passwd ``` 3. The `/etc/passwd` file will be downloaded. Acknowledgements This vulnerability was discovered by Abderrahim Dahmani while solving a STARPWN 2025 CTF challenge at DEFCON 33 offered by VisionSpace Technologies.
Recommended action: Upgrade to 5.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Attack type: Unauthenticated remote Impact: Attackers can execute arbitrary JavaScript in a user's browser, including obtaining a user's session token and refresh token. Affected components: authorize.html, AuthHandler.java, HandlerContext.java A Reflected Cross-Site Scripting vulnerability exists in Yamcs <=5.8.6, allowing an attacker to execute arbitrary JavaScript in a Yamcs user's browser. This vulnerability can be exploited to exfiltrate a logged-in user's access token and send it to a remote server, leading to the takeover of the user's account. Using a specially crafted URL, you are able to execute a JavaScript alert() call in the browser: <img width="1794" height="816" alt="image" src="https://github.com/user-attachments/assets/4a5b6aa4-bceb-4b3d-bc5d-3dac0895ff2e" / You then use JavaScript to obtain the user's cookies and display them in the alert: <img width="1794" height="1290" alt="image"…
Recommended action: Upgrade to 5.9.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The PacketsApi.exportPackets endpoint in Yamcs fails to properly enforce object-level privileges (ReadPacket) when an API request omits specific packet names. As a result, an attacker with a low-privileged account (or any authenticated user with zero privileges) can dump the entire archive of raw telemetry packets for a Yamcs instance. This leads to a massive Information Disclosure of sensitive mission telemetry, completely bypassing the intended Role-Based Access Control (RBAC) model. Vulnerability Details In yamcs-core/src/main/java/org/yamcs/http/api/PacketsApi.java, the exportPackets method processes requests to export raw packets from the tm (telemetry archive) table. The method attempts to verify privileges using ctx.checkObjectPrivileges(ObjectPrivilegeType.ReadPacket, nameSet). However, if the request.getNameList() is empty (i.e., the attacker does not specify any packet names to filter by), nameSet is empty. The checkObjectPrivileges method loops over this empty set…
Recommended action: Upgrade to 5.13.2 or 5.12.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Missing authorization checks on three IAM API endpoints (GET /api/roles, GET /api/roles/{name}, GET /api/privileges) allow any authenticated user — regardless of their assigned permissions — to enumerate the complete list of system privileges and role definitions. An attacker with only a low-privilege account (e.g., a read-only operator) can retrieve the full privilege taxonomy of the server, including the names and assignments of all administrator-level capabilities. This information directly enables targeted privilege escalation attacks. --- Details Three handler methods in IamApi.java serve sensitive security metadata without performing any authorization check: File: yamcs-core/src/main/java/org/yamcs/http/api/IamApi.java By contrast, all write operations and user-management endpoints in the same file correctly enforce authorization. For example: The three vulnerable endpoints share the same ControlAccess protection requirement as the user-management endpoints but were…
Recommended action: Upgrade to 5.13.2 or 5.12.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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,…
Recommended action: Upgrade to 5.13.2 or 5.12.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Multiple Missing Function Level Access Control vulnerabilities exist in the Yamcs Core API. These vulnerabilities allow any authenticated user, regardless of their assigned roles or privileges (e.g., an unprivileged "Guest"), to bypass intended access controls. An attacker can exploit these flaws to extract sensitive telemetry metadata, disrupt satellite communication link protocols (COP-1), and manipulate the global simulation time, severely impacting the confidentiality, integrity, and availability of the system. Details Yamcs utilizes a robust Role-Based Access Control (RBAC) model with SystemPrivilege and ObjectPrivilege to restrict administrative actions and data retrieval. However, three critical API controllers completely omit these authorization checks before executing internal business logic: 1. IndexesApi.java (Information Disclosure): Unlike PacketsApi.java, which filters results using ctx.user.hasObjectPrivilege(ObjectPrivilegeType.ReadPacket, packetName), methods…
Recommended action: Upgrade to 5.13.2 or 5.12.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Yamcs compiles StreamSQL expressions to Java on the fly with the Janino SimpleCompiler (no restrictive class-loading policy or expression sandbox). When a StreamSQL aggregate such as sum(...) is applied to a column, the column's name is interpolated unescaped into the generated Java source. Because Yamcs accepts arbitrary characters in a double-quoted column identifier and applies no validation when a column is created, an authenticated user with the ControlArchiving system privilege can craft a column name that injects arbitrary Java into the compiled aggregate and achieve Remote Code Execution on the Yamcs host via POST /api/archive/{instance}:executeSql. This is a second, independent Janino-RCE entry point sharing the root cause of CVE-2026-44632 (GHSA-524g-x36v-9wm6). The 5.13.0 / 5.12.7 fix for CVE-2026-44632 hardened only the algorithm-override path (JavaExprAlgorithmExecutionFactory, reached via MdbOverrideApi and gated by ChangeMissionDatabase). The StreamSQL…
Recommended action: Upgrade to 5.13.2 or 5.12.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Server-Side Code Injection vulnerability exists in the Yamcs script evaluation engine for Python algorithms. The application dynamically compiles and evaluates user-controlled algorithm text using Jython (via the JSR-223 ScriptEngine API) without enforcing a secure sandbox. An authenticated user with the ChangeMissionDatabase privilege can exploit this by overriding the algorithm logic through the REST API, achieving Remote Code Execution (RCE) on the underlying host operating system. Details The vulnerability lies in how Yamcs handles dynamic script evaluation. When a user updates an algorithm via the MDB (Mission Database) API (/api/mdb/{instance}/realtime/algorithms/{name}), the AlgorithmManager uses the ScriptAlgorithmExecutorFactory to instantiate a JSR-223 ScriptEngine (in this case, Jython/Python). Because Jython allows seamless interoperability with native Java classes, an attacker can import and execute arbitrary Java classes such as java.lang.Runtime. Any valid…
Recommended action: Upgrade to 5.12.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Remote Code Execution via Mission Database algorithm override Summary The Nashorn ScriptEngine used to evaluate user-supplied algorithm text in MdbOverrideApi.updateAlgorithm is constructed without a ClassFilter, allowing a user with the ChangeMissionDatabase privilege to execute arbitrary Java code on the Yamcs server. In Yamcs's default configuration (no security.yaml), the built-in guest user has superuser=true, so the vulnerability is reachable without authentication. Details Vulnerable file: yamcs-core/src/main/java/org/yamcs/algorithms/ScriptAlgorithmExecutorFactory.java NashornScriptEngineFactory.getScriptEngine() accepts an optional ClassFilter that restricts which classes JavaScript can reach via Java.type(...). Yamcs passes no filter, so attacker-supplied JavaScript can reach any Java class — for example, Java.type("java.lang.Runtime").getRuntime().exec(...) runs arbitrary OS commands inside the Yamcs JVM. The path from HTTP request to eval is:…
Recommended action: Upgrade to 5.12.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A Server-Side Code Injection vulnerability exists in the Yamcs algorithm evaluation engine (org.yamcs.algorithms.JavaExprAlgorithmExecutionFactory). The application dynamically compiles and evaluates user-controlled algorithm text without enforcing a secure sandbox. An authenticated user with the ChangeMissionDatabase privilege can exploit this to achieve Remote Code Execution (RCE) on the underlying host operating system via the Janino compiler. Proof of Concept (PoC) The vulnerability can be exploited by overriding an existing algorithm's text via the REST API and injecting a malicious Java payload that executes OS commands. Prerequisites: 1. A running Yamcs instance with an active processor (e.g., instance=myproject, processor=realtime). 2. An active authentication token for a user with the SystemPrivilege.ChangeMissionDatabase privilege. Steps to Reproduce: 1. Send an authenticated HTTP PATCH request to the MDB override endpoint to inject the malicious Java code into an…
Recommended action: Upgrade to 5.12.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The authentication endpoint POST /auth/token in yamcs-core lacks any form of rate limiting, account lockout, or failed attempt throttling. As a result, an unauthenticated remote attacker can perform unlimited password guessing attempts against any user account. This missing rate limiting vulnerability (CWE-307) significantly increases the risk of successful brute-force attacks. Root Cause File: yamcs-core/src/main/java/org/yamcs/http/auth/AuthHandler.java POST /auth/token has no rate limiting, no lockout after failed attempts, and no CAPTCHA. The handler processes unlimited authentication requests without any throttling mechanism: This is absent by default — the official quickstart and documentation contain no guidance on configuring rate limiting. Impact An attacker can make unlimited authentication attempts against any account. This enables efficient brute-force attacks against any account. Proof of Concept Confirmed: 20 attempts in 0.07 seconds, no rate limiting enforced.…
Recommended action: Upgrade to 5.12.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The IAM API endpoints (listUsers, getUser, listGroups, and getGroup) in yamcs-core do not enforce the required SystemPrivilege.ControlAccess check. As a result, any authenticated user (even those with low or no privileges) can enumerate all user accounts in the system, including their usernames, superuser status, and group memberships. This constitutes a broken access control vulnerability (CWE-862) that leaks sensitive user information. Root Cause File: yamcs-core/src/main/java/org/yamcs/http/api/IamApi.java:125,180,357,372 listUsers(), getUser(), listGroups(), and getGroup() do not require SystemPrivilege.ControlAccess. Any authenticated user — regardless of privileges — can enumerate all users, their superuser status, and group memberships: Compare with properly protected endpoints: Impact Any authenticated user can: 1. List all user accounts in the system 2. Identify which accounts have superuser privileges 3. Use this information to target privileged accounts Proof of…
Recommended action: Upgrade to 5.12.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An LDAP injection vulnerability exists in org.yamcs.security.LdapAuthModule when constructing search filters. The username parameter is inserted directly into the LDAP filter without proper RFC 4515 escaping. Root Cause File: yamcs-core/src/main/java/org/yamcs/security/LdapAuthModule.java:233 The username parameter is inserted directly into an LDAP search filter without RFC 4515 escaping: LDAP wildcard characters (, (, )) are accepted without sanitization. Impact With a known valid password, username= authenticates as the first user returned by the LDAP search — enabling horizontal privilege escalation between accounts sharing similar passwords or when the attacker knows one valid password. This affects deployments that use org.yamcs.security.LdapAuthModule in their etc/security.yaml configuration file. Proof of Concept Fix Apply RFC 4515 escaping before filter construction:
Recommended action: Upgrade to 5.12.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.