CVE-2026-55559 is an improper neutralization vulnerability in Yamcs templated-instance creation and update workflows before 5.12.8 and from 5.13.0 through 5.13.1. User-controlled template arguments were inserted into rendered YAML without YAML-context escaping. The resulting configuration was parsed and loaded as an instance definition, allowing malicious multiline values to alter the YAML object structure. An attacker can add a service definition for Yamcs ProcessRunner and cause command execution under the Yamcs service account.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
The repository contains README.md (2,294 bytes) and a standalone Python 3 exploit, poc.py (7,083 bytes), using only standard-library modules. The README documents the vulnerability, example requests, remediation, and disclosure references. Its demo image references an asset absent from the supplied two-file inventory. The exploit targets unsanitized template rendering in reconfigureInstance(). According to the supplied documentation, the sibling createInstance() path was hardened for CVE-2026-55559, but reconfiguration retained template.process(). A malicious template argument breaks out of a quoted YAML scalar and introduces a services key. The documented duplicate-key behavior allows an injected org.yamcs.ProcessRunner to replace the service configuration and execute a shell command during automatic instance restart. The README identifies GHSA-wqq5-5w4p-m569 for this reconfiguration issue and states that version 5.13.6 fixes it. CVE-2026-55559 is a related original issue, not an independently established CVE assignment for this sibling vulnerability. The script optionally creates an instance, sends the injection as JSON, waits for restart, and checks either a local marker or whether the response contains the injected ProcessRunner class name. It supports configurable targets, template arguments, commands, and bearer authentication. It is an exploitation tool with verification logic, not merely a passive detector; no reverse shell, external callback, persistence, or exfiltration destination is supplied. Verification is imperfect: HTTP error responses can be labeled likely vulnerable because their status is not validated before the response heuristic. A missing or empty local marker is labeled safe despite possible execution or filesystem-access failures, while an existing marker is not checked for freshness. Commands and marker paths are interpolated without YAML or shell escaping. These limitations prevent the reported result from reliably establishing safety or vulnerability in all cases. Execution was not tested. Repository URL, git reference, and archive size were not supplied; empty metadata and zero size indicate unavailable values, not an empty repository.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
9 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.