Emissary has an OS Command Injection via Unvalidated IN_FILE_ENDING / OUT_FILE_ENDING in Executrix
Date: 2026-04
Affected: maven/gov.nsa.emissary:emissary
Attack vector: command-injection
Category: vulnerability-disclosure
Severity: High
CVE: CVE-2026-35582
CWE: CWE-116
CWE-78
CVSS: 8.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H)

### Summary `Executrix.getCommand()` constructs shell commands by substituting temporary file paths directly into a `/bin/sh -c` string with no escaping. The `IN_FILE_ENDING` and `OUT_FILE_ENDING` configuration keys flow into those paths unmodified. A place author who sets either key to a shell metacharacter sequence achieves arbitrary OS command execution in the JVM's security context when the place processes any payload. No runtime privileges beyond place configuration authorship are required, and no API or network access is needed. This is a **framework-level defect** — `Executrix` provides no escaping mechanism and no validation on file ending values. Downstream implementors have no safe way to use the API as designed. --- ### Root Cause #### Step 1 — `IN_FILE_ENDING` flows into temp path construction without validation **[`TempFileNames.java:32-36`](src/main/java/emissary/util/shell/TempFileNames.java#L32-L36)** ```java public TempFileNames(String tmpDir, String placeName, String inFileEnding, String outFileEnding) { base = Long.toString(System.nanoTime()); tempDir = FileManipulator.mkTempFile(tmpDir, placeName); in = base + inFileEnding; // no sanitization out = base + outFileEnding; // no sanitization basePath = tempDir + File.separator + base; inputFilename = basePath + inFileEnding; // injected value lands here outputFilename = basePath + outFileEnding; // and here } ``` `inFileEnding` is concatenated direct


Mitigations:

Architectural layers (MAESTRO):