CVE-2026-44632 - Yamcs Janino expression RCE

Yamcs exposed a server-side code injection path in the algorithm evaluation engine behind org.yamcs.algorithms.JavaExprAlgorithmExecutionFactory. A user with mission-database mutation authority could change algorithm text that Yamcs then compiled and evaluated through Janino, turning an application-level configuration privilege into operating-system command execution on the Yamcs host.

This is a privileged-user RCE, not a public unauthenticated endpoint. The important remediation work is therefore twofold: consume the patched Yamcs runtime, and prove that only the smallest necessary operator group can mutate mission database algorithms in each deployed instance.

When to use it

Use this recipe when a repository builds, deploys, configures, or wraps Yamcs, especially where mission-database algorithms can be changed through REST APIs, admin UIs, operator runbooks, service accounts, lab environments, or customer deployments. It is a dependency-remediation and privilege-audit recipe for Janino-backed algorithm evaluation.

Do not use it to inject Java snippets, replay public exploit requests, or exercise command execution against a live Yamcs processor.

Inputs

  • Maven/Gradle manifests, lockfiles, plugin descriptors, Dockerfiles, Compose, Helm, Kubernetes, Terraform, Ansible, SBOMs, dependency reports, and operator runbooks that may pin org.yamcs:yamcs-core or a Yamcs distribution.
  • Mission database bundles, XTCE/config templates, algorithm override flows, active processor configuration, admin UI/API gateway routes, and wrapper services that can mutate algorithms.
  • Principal inventory for SystemPrivilege.ChangeMissionDatabase, including operators, developers, CI, support users, customers, tenants, demos, contractors, shared accounts, and service accounts.
  • Exposure evidence for Yamcs admin routes and processors: network boundary, authentication, token lifetime, audit logs, change tickets, and deployment environment.
  • Branch-aware version policy showing whether the target should land on 5.13.0+ or the patched 5.12.7+ train.

Affected versions

The vendor advisory lists two patched release trains. Treat this as a branch aware check instead of a naive numeric comparison:

Package Vulnerable versions Fixed versions
org.yamcs:yamcs-core affected 5.12 releases before 5.12.7; affected pre-5.13.0 releases on the main train 5.12.7, 5.13.0

Prefer 5.13.0+ for forward upgrades. If the deployment must remain on the 5.12 train, verify that every controlled artifact resolves exactly 5.12.7 or newer on that train.

Indicator-of-exposure

  • The repository depends on, vendors, builds, or deploys org.yamcs:yamcs-core on an affected version.
  • Yamcs is reachable through a REST API, reverse proxy, operator network, lab network, mission environment, demo system, or managed deployment.
  • The deployment enables authentication tokens or service accounts with SystemPrivilege.ChangeMissionDatabase.
  • Mission database algorithm definitions, XTCE/config files, templates, plugin code, or deployment docs reference Java expression algorithms, algorithm overrides, active processors, or MDB mutation endpoints.
  • The Yamcs process has access to spacecraft, telemetry, command, credential, filesystem, database, or internal-network resources that would matter if host-level code execution occurred.

Quick checks:

rg -n "yamcs|yamcs-core|JavaExprAlgorithmExecutionFactory|ChangeMissionDatabase|MissionDatabase|algorithm|algorithms|mdb|processor|janino|xtce" .
mvn -q dependency:tree -Dincludes=org.yamcs:yamcs-core
gradle dependencies --configuration runtimeClasspath | rg "yamcs-core|org\\.yamcs"
rg -n "yamcs|YAMCS|ChangeMissionDatabase|algorithm|mdb|processor|janino|xtce" Dockerfile* docker-compose*.yml compose*.yml charts k8s deploy config .github .

Windows:

rg -n "yamcs|yamcs-core|JavaExprAlgorithmExecutionFactory|ChangeMissionDatabase|MissionDatabase|algorithm|algorithms|mdb|processor|janino|xtce" .
mvn -q dependency:tree -Dincludes=org.yamcs:yamcs-core
gradle dependencies --configuration runtimeClasspath | rg "yamcs-core|org\\.yamcs"
rg -n "yamcs|YAMCS|ChangeMissionDatabase|algorithm|mdb|processor|janino|xtce" Dockerfile* docker-compose*.yml compose*.yml charts k8s deploy config .github .

Do not replay public proof-of-concept requests, inject Java snippets into a running Yamcs processor, trigger algorithm evaluation with command-capable payloads, or send callbacks to external infrastructure during triage.

Remediation strategy

  • Upgrade every controlled Yamcs dependency, image, deployment manifest, SBOM, and generated dependency report to 5.13.0+, or to 5.12.7+ only when the product is intentionally pinned to the 5.12 train.
  • Regenerate Maven/Gradle lockfiles, container image digests, deployment manifests, SBOMs, and scanner outputs that pin Yamcs.
  • Inventory all principals with SystemPrivilege.ChangeMissionDatabase. Remove the privilege from routine users, automation tokens, shared lab accounts, CI accounts, and service accounts that do not need live algorithm mutation.
  • Add safe authorization tests around repository-owned Yamcs wrappers, gateways, provisioning code, or admin UI routes that can mutate MDB algorithms.
  • Prefer immutable reviewed mission database bundles for production. If live overrides are required, require explicit operator approval, auditable change tickets, and short-lived credentials.
  • Review Yamcs audit logs and reverse-proxy logs for unexpected algorithm mutation attempts if affected versions were reachable by broad operator or tenant groups.

The prompt

Model context: this prompt was generated by GPT 5.5 Extra High reasoning.

You are remediating CVE-2026-44632 / GHSA-524g-x36v-9wm6, a critical Yamcs
server-side code injection issue in Janino-backed algorithm evaluation. Produce
exactly one output:

- A reviewer-ready PR/change request that upgrades Yamcs, refreshes generated
  artifacts, tightens mission-database mutation privileges, adds safe
  authorization and dependency checks, and documents operator cleanup, or
- TRIAGE.md if this repository does not control an affected Yamcs runtime,
  plugin, image, deployment, or mission-database mutation surface.

## Rules

- Scope only CVE-2026-44632 / GHSA-524g-x36v-9wm6 and directly related Yamcs
  dependency, deployment, mission-database, and algorithm-mutation controls.
- Treat authentication tokens, operator accounts, mission data, telemetry,
  command paths, spacecraft or lab identifiers, internal hostnames, filesystem
  contents, and environment variables as sensitive.
- Do not send exploit-shaped REST requests, inject Java source into algorithm
  text, trigger command execution, call external webhooks, or run live Janino
  payloads.
- Do not remove authentication, authorization, audit logging, or change-ticket
  requirements to make tests pass.
- Do not auto-merge.

## Steps

1. Inventory every repository-controlled Yamcs reference: Maven/Gradle
   manifests, lockfiles, plugin descriptors, Dockerfiles, Compose files, Helm
   charts, Kubernetes manifests, Terraform, Ansible, SBOMs, generated
   dependency reports, operator runbooks, XTCE bundles, mission database
   templates, admin UI routes, API gateways, and docs.
2. Determine every resolved `org.yamcs:yamcs-core` version. A target is
   vulnerable if it is on an affected 5.12 release before `5.12.7`, or on the
   affected main train before `5.13.0`.
3. Search for live mission-database mutation paths:
   `ChangeMissionDatabase`, algorithm overrides, Java expression algorithms,
   active processor configuration, MDB route wrappers, admin endpoints, shared
   operator tokens, and service accounts that can change algorithms.
4. Classify who can reach those mutation paths: mission operators, developers,
   CI, support users, customers, tenants, demos, contractors, or internet users.
5. If this repository does not control an affected Yamcs runtime or deployment,
   stop with `TRIAGE.md` listing checked files, resolved versions, owner if
   known, and required fixed version `5.13.0+` or `5.12.7+` on the 5.12 train.
6. Upgrade all controlled Yamcs runtimes. Refresh lockfiles, generated package
   metadata, container digests, SBOMs, dependency reports, deployment render
   output, and scanner suppressions.
7. Remove unnecessary `ChangeMissionDatabase` grants. For required grants,
   document the owning role, approval path, token lifetime, and audit signal.
8. Add safe regression coverage:
   - dependency policy rejects vulnerable Yamcs versions;
   - non-privileged users cannot mutate MDB algorithms through owned wrappers
     or gateways;
   - service accounts without explicit mission-database change authority are
     denied;
   - audit logs record authorized algorithm changes without logging secrets or
     algorithm payload contents;
   - deployment manifests do not expose Yamcs admin routes beyond the intended
     operator boundary.
9. Add a PR body section named `CVE-2026-44632 operator actions` that states:
   - Yamcs versions before and after;
   - which release train was selected;
   - every deployment, image, and mission database bundle updated;
   - every principal retaining `ChangeMissionDatabase`;
   - whether any tokens should be rotated;
   - which logs should be reviewed for unexpected algorithm mutation attempts;
   - which validation commands passed.
10. Run relevant validation: Maven/Gradle dependency resolution, unit tests,
    authorization tests, config render, container build, deployment schema
    validation, SBOM refresh, dependency/security scans, and any Yamcs wrapper
    integration tests that do not execute injected code.
11. Use PR title:
    `fix(sec): remediate CVE-2026-44632 in Yamcs`.

## Stop conditions

- No affected Yamcs runtime, plugin, image, or deployment is controlled by this
  repository.
- Yamcs is fully vendor-managed outside repository ownership; document owner,
  required fixed version, and temporary access-control containment.
- The upgrade requires a broader mission runtime migration outside the current
  change boundary.
- Verification would require live exploit traffic, live algorithm source
  injection, command execution, production mission data, or real operator
  tokens.
- Validation fails for unrelated pre-existing reasons; document those failures
  instead of broadening scope.

Verification - what the reviewer looks for

  • No controlled dependency, lockfile, image, SBOM, or deployment artifact resolves an affected Yamcs version.
  • ChangeMissionDatabase is limited to named, reviewed operator roles and short-lived credentials where possible.
  • Repository-owned wrappers, gateways, or UI paths deny algorithm mutation to non-privileged users.
  • The PR does not contain exploit requests, Java payloads, operator tokens, or mission/customer data.
  • Operator notes cover token rotation and log review when affected versions were reachable by broad user groups.

Watch for

  • Treating this as only a Maven bump while deployment images still pin an older Yamcs distribution.
  • Leaving shared operator or CI tokens with ChangeMissionDatabase.
  • Naive version checks that mark the patched 5.12.7 train as vulnerable only because 5.12.7 sorts below 5.13.0.
  • Tests that mutate real mission database algorithms or execute attacker-like Java code to prove the bug.

Output contract

Return one of:

  • A reviewer-ready PR/change request that upgrades Yamcs to 5.13.0+ or patched 5.12.7+, refreshes generated artifacts, reduces ChangeMissionDatabase grants, adds safe authorization/dependency checks, and documents operator log review and token rotation.
  • TRIAGE.md when no controlled affected Yamcs runtime, plugin, image, deployment, or mutation surface exists, or when Yamcs is fully vendor-managed outside repository ownership.

The output must list versions before/after, the selected release train, deployments and mission database bundles touched, every remaining mutation principal, validation commands, and operator actions. It must not contain Java payloads, exploit requests, operator tokens, mission/customer data, internal hostnames, or environment variables.

References