CVE-2026-55511

Overview

Yamcs compiles StreamSQL expressions to Java on the fly with the Janino SimpleCompiler (no restrictive class-loading policy or expression sandbox). When a StreamSQL aggregate such as sum(...) is applied to a column, the column's name is interpolated unescaped into the generated Java source. Because Yamcs accepts arbitrary characters in a double-quoted column identifier and applies no validation when a column is created, an authenticated user with the ControlArchiving system privilege can craft a column name that injects arbitrary Java into the compiled aggregate and achieve Remote Code Execution on the Yamcs host via POST /api/archive/{instance}:executeSql.

This is a second, independent Janino-RCE entry point sharing the root cause of CVE-2026-44632 (GHSA-524g-x36v-9wm6). The 5.13.0 / 5.12.7 fix for CVE-2026-44632 hardened only the algorithm-override path (JavaExprAlgorithmExecutionFactory, reached via MdbOverrideApi and gated by ChangeMissionDatabase). The StreamSQL expression compiler (org.yamcs.yarch.streamsql) was not addressed and remains exploitable in 5.13.0 via a different privilege (ControlArchiving).

Impact

An authenticated Yamcs user holding SystemPrivilege.ControlArchiving can cause Yamcs to compile attacker-controlled Java source through the StreamSQL aggregate expression compiler reachable from POST /api/archive/{instance}:executeSql.

The injected code executes inside the Yamcs server JVM with the privileges of the Yamcs server process, bypassing the Yamcs authorization model. Because this is ordinary Java execution, dangerous JDK APIs such as filesystem access, process execution, reflection, and class loading are reachable unless externally sandboxed. This allows compromise of confidentiality, integrity, and availability of the Yamcs deployment: access to mission data and credentials available to the process, telemetry/archive tampering, denial of service, and lateral movement from the host environment.

ControlArchiving is the archive/table/stream management privilege — distinct from both superuser access and the ChangeMissionDatabase privilege used by the previously fixed algorithm-override Janino issue (CVE-2026-44632). Scope is scored as Changed because execution crosses from an authenticated Yamcs API privilege into arbitrary code execution under the server process / host OS authority, outside the privileges granted to the authenticated Yamcs user (consistent with the maintainer's S:C scoring of the sibling CVE-2026-44632).

Technical Details

The sink: unsandboxed Janino compilation of generated Java

org.yamcs.yarch.streamsql.CompilableAggregateExpression#getCompiledAggregate() builds a Java source string and compiles it with Janino, with no restrictive ClassLoader and no class/API allowlist:

// org/yamcs/yarch/streamsql/CompilableAggregateExpression.java:26-50
String className = "AggregateExpression" + counter.incrementAndGet();
StringBuilder code = new StringBuilder();
code.append("package org.yamcs.yarch;\n")
        .append("public class " + className + " implements CompiledAggregateExpression {\n");
aggregateFillCode_Declarations(code);
code.append("\tpublic void newData(Tuple tuple) {\n");
aggregateFillCode_newData(code);                  // <-- attacker-controlled column name lands here
code.append("\t}\n");
code.append("\tpublic Object getValue() {\n");
aggregateFillCode_getValue(code);
code.append("\t}\n");
...
SimpleCompiler compiler = new SimpleCompiler();   // generated source is compiled without a restrictive sandbox
compiler.cook(code.toString());                   // compiles attacker-influenced Java source

The injection: column name interpolated unescaped

SumExpression#aggregateFillCode_newData emits, inside newData(Tuple tuple), a declaration for each input column followed by sum += col<columnName>:

// org/yamcs/yarch/streamsql/funct/SumExpression.java:38-42
protected void aggregateFillCode_newData(StringBuilder code) throws StreamSqlException {
    fillCode_InputDefVars(inputDef.getColumnDefinitions(), code);   // emits the column declaration
    code.append("\t\tsum+=col" + children[0].getColumnName());      // emits the column identifier again
    code.append(";\n");
}

fillCode_InputDefVars interpolates the column name into a Java identifier with only sanitizeName applied, and again — raw — into a tuple.getColumn("...") string literal:

// org/yamcs/yarch/streamsql/Expression.java:134-145
String javaColIdentifier = "col" + sanitizeName(cd.getName());
...
code.append("\t\t" + dtype.javaType() + " " + javaColIdentifier +
        " =  (" + dtype.javaType() + ")tuple.getColumn(\"" + cd.getName() + "\");\n");

// Expression.java:237-238  — the ONLY transformation applied to the column name:
static String sanitizeName(String s) {
    return s.replace("/", "_").replace("-", "_");
}

sanitizeName maps only / and - to _. Every other character — ;, spaces, ( ) { } [ ], =, ., +, ,, digits — passes through verbatim into the generated Java.

The exploitable context is the Java identifier col<name>. The same method also emits the raw column name into a Java string literal used by tuple.getColumn("...") (Expression.java:140/144). This string-literal context is not required for the exploit shown here, but it should still be escaped with ValueExpression.escapeJavaString, because it is another instance of raw user-controlled text emitted into generated Java source (including Java escape-sequence edge cases) and is therefore an additional source-generation hazard, not a closed surface. (ValueExpression.escapeJavaString is correctly applied to value literals such as WHERE x = '...'; function names are separately whitelisted by FunctionExpressionFactory. The unfixed gap is the column identifier.)

Why the column name is fully attacker-controlled

The StreamSQL grammar accepts any character except newline / CR / double-quote in a double-quoted identifier, and returns the raw inner content:

// org/yamcs/yarch/streamsql/StreamSql.jj:237 and :931
< S_DOUBLE_QUOTED_IDENTIFIER: "\"" (~["\n","\r","\""])* "\"" >
<S_DOUBLE_QUOTED_IDENTIFIER> {String s1 = token.image; return s1.substring(1, s1.length() - 1);}

ObjectName() (used for column names in CREATE TABLE / CREATE STREAM) accepts this token, and neither org.yamcs.yarch.ColumnDefinition nor TupleDefinition.addColumn validates the characters of a column name (only a duplicate-name check). So CREATE TABLE evil("<arbitrary text>" double, ...) creates a column whose name is attacker-chosen text.

Why the bare-expression compiler is NOT exploitable, but the aggregate compiler IS

The general expression compiler Expression#compile() emits the column identifier in two contexts — a statement-context declaration and the return col<name>; expression. A payload carrying executable statements (;-separated) makes the code after the return unreachable, which Janino rejects ("Statement is unreachable"); a payload without ; cannot carry a side effect. That accidental barrier makes the bare-column path non-exploitable.

The aggregate path is different and exploitable: in SumExpression, both emissions of the column name live inside newData(Tuple tuple) — a void, statement-context method — and getValue() returns the accumulator sum, never the column. There is no expression-context return col<name> and no unconditional return before the injected statements, so a ;-separated, fully reachable payload compiles cleanly.

Reachability: executeSql reaches the aggregate compiler without the bare-path gate

POST /api/archive/{instance}:executeSql → TableApi.executeSql (gate ctx.checkSystemPrivilege(SystemPrivilege.ControlArchiving), TableApi.java:398-399) → ydb.execute(ydb.createStatement(statement)) → SelectExpression.compile().

Crucially, when an aggreg