Yamcs is a mission control framework. Prior to 5.12.8 and 5.13.2, Yamcs inserts templateArgs from POST /api/instances and PATCH /api/instances/{instance} into YAML through VarStatement.append in yamcs-core/src/main/java/org/yamcs/templating/VarStatement.java without YAML-context escaping. The rendered configuration is parsed by YamcsServer.createInstance and loaded by YamcsServerInstance, allowing an attacker to inject a services entry for org.yamcs.ProcessRunner. Deployments without security.yaml expose the operation through the guest superuser, while secured deployments require SystemPrivilege.CreateInstances. Successful exploitation executes commands as the Yamcs service account. This issue is fixed in versions 5.12.8 and 5.13.2.
Security readout for executives and security teams
Plain-English summary
A remote attacker may take control of vulnerable Yamcs mission-control servers by supplying crafted instance settings. Unsecured deployments are especially exposed because guest access can receive superuser capability. Successful exploitation runs commands with the Yamcs service account, potentially compromising sensitive data, configurations, and service availability.
Executive priority
Prioritize immediate remediation for internet-accessible or unsecured Yamcs systems. Schedule rapid upgrades for all other affected deployments because a privileged account could still achieve command execution. If compromise is suspected, isolate the service and initiate incident response before returning it to operation.
Technical view
Yamcs interpolates createInstance and updateInstance template arguments into YAML without context-appropriate escaping. The resulting configuration can introduce an org.yamcs.ProcessRunner service, producing command execution when Yamcs parses and loads the instance. The vulnerable interfaces are POST /api/instances and PATCH /api/instances/{instance}.
Likely exposure
Yamcs versions below 5.12.8 and versions 5.13.0 through 5.13.1 are affected. Without security.yaml, guest superuser access exposes the operation remotely. Secured deployments remain exposed to accounts holding SystemPrivilege.CreateInstances. Network accessibility of the instance-management API materially increases risk.
Exploitation context
The CVSS 3.1 score is 9.8, reflecting network-reachable, low-complexity execution without credentials on unsecured deployments. The source bundle marks this CVE as absent from KEV and provides no evidence of active exploitation. Authenticated abuse remains possible where CreateInstances is granted.
Researcher notes
The reported trust-boundary failure occurs in VarStatement.append before YamcsServer.createInstance parses and YamcsServerInstance loads the rendered YAML. The named injection target is the services configuration using org.yamcs.ProcessRunner. The listed fixes are commits 549f295 and 7192da1. No exploit procedure or observed attack campaign is established by the supplied sources.
Mitigation direction
Upgrade Yamcs 5.12 deployments to 5.12.8 or later.
Upgrade Yamcs 5.13 deployments to 5.13.2 or later.
Ensure security.yaml is configured; do not expose guest superuser operation.
Restrict SystemPrivilege.CreateInstances to essential administrators until upgrades are complete.
Limit network access to instance-management interfaces while remediation is pending.
Validation and detection
Inventory every Yamcs deployment and record its exact version.
Confirm security.yaml exists and guest users lack superuser capability.
Review which accounts possess SystemPrivilege.CreateInstances and remove unnecessary grants.
Review available audit records for unexpected instance creation or modification requests.
Investigate unexplained processes running under the Yamcs service account.
After upgrading, confirm each deployment reports a fixed or later version.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-1336: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
Code execution and unsafe deserialization weaknesses often justify reviewing execution behavior and process telemetry. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references code or command execution, so execution technique review may help defensive triage. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
1CVSS vectors
3Timeline events
1ADP providers
6Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: pocAutomatable: yesTechnical Impact: total
CVSS vector scores
1 official score
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.