← Blog · · df00tech

Yamcs RCE via YAML Injection in createInstance Template Args (CVE-2026-55559)

breaking ghsa maven CVE-2026-55559

What happened

A GitHub Security Advisory (GHSA-73mf-m39p-wpm9) discloses a remote code execution vulnerability in org.yamcs:yamcs-core, tracked as CVE-2026-55559 (CVSS 9.8, PoC public). According to the advisory, templateArgs submitted to POST /api/instances or PATCH /api/instances/{instance} are written unescaped into the rendered instance configuration and then parsed as YAML. Because Yamcs instantiates each entry under services: by its declared class:, an attacker can inject a new services: block referencing org.yamcs.ProcessRunner to execute an arbitrary command on the host.

The advisory states the only existing filter (EscapeFilter) performs HTML escaping and does not neutralize newlines, colons, or indentation, so it does not block the injection. Exploitation requires the CreateInstances privilege — but the advisory notes that in a default configuration with no security.yaml, the guest user is superuser and the API is unauthenticated, meaning the flaw can be reachable with no authentication at all. A working proof-of-concept reverse-shell request is included in the advisory.

Why it matters for defenders

Yamcs is used as mission control / telemetry software, often in space and satellite ground-segment environments. Per the advisory, successful exploitation yields command execution as the Yamcs service account, which can expose the secretKey in etc/yamcs.yaml (allowing token forgery for any user, including superusers), other stored secrets (LDAP bind credentials, OIDC client secrets, TLS keys), and read/write access to telemetry and command history across every instance on the host. On deployments without security.yaml, or where the CreateInstances privilege is delegated to operators without shell access, this amounts to full host takeover from the API — with public exploit code already available, opportunistic scanning and exploitation risk should be treated as immediate.

What defenders should watch for

  • Inventory any internet- or network-reachable Yamcs deployments, and confirm whether security.yaml is configured (its absence means unauthenticated superuser access via the guest account, per the advisory).
  • Restrict or audit which accounts hold the CreateInstances privilege — the advisory notes this privilege alone is sufficient for exploitation, even under an authenticated configuration.
  • Monitor for POST /api/instances and PATCH /api/instances/{instance} requests, particularly those containing YAML-significant characters (newlines, colons, services:, or class references such as org.yamcs.ProcessRunner) inside JSON string fields — a strong indicator of this injection technique.
  • Watch for unexpected child processes spawned by the Yamcs service account, and for newly created Yamcs instances that were not initiated through normal operational workflows.
  • Apply vendor guidance or patches once available; the advisory notes the existing 5.12.7 algorithm-edit fix does not address this code path, so a separate remediation is needed.

Developing intel

This is a same-day, high-severity disclosure with public exploit code and no confirmed patch version referenced in the advisory at time of writing. Details may evolve as the vendor responds — see the original GitHub Security Advisory for the authoritative writeup: GHSA-73mf-m39p-wpm9.

Get new detections in your inbox

New ATT&CK coverage plus CISA KEV / CVE detection rules, roughly weekly. No spam, unsubscribe anytime.