GHSA-7648-jmwf-vw7j CVE-2026-116674
systeminformation has prototype pollution in `networkStats()` via the interface name
- Severity
- 6.5 / 10
- Medium · CVSS 3.1
- Exploit chance (EPSS)
- 0.29%
- Chance of exploitation in the next 30 days. Higher than 21.29% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-1321 Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
- Fix
5.33.13- Upgrade systeminformation to this version or later
Description
Summary
networkStats() keeps a per interface cache for computing rx_sec / tx_sec between calls.
The cache is a plain JavaScript object and is indexed with the interface name the caller
supplied. Passing the name __proto__ makes every cache write land on Object.prototype
instead of the cache, polluting every object in the Node.js process.
An application is affected if it passes untrusted input as the ifaces argument of
si.networkStats() and runs on FreeBSD, OpenBSD or NetBSD.
Details
The vulnerable code
lib/network.js declares the cache as a plain object:
const _network = {};
calcNetworkSpeed() writes into it, keyed by the interface name:
} else {
if (!_network[iface]) {
_network[iface] = {};
}
_network[iface].rx_bytes = rx_bytes;
_network[iface].tx_bytes = tx_bytes;
_network[iface].rx_sec = null;
_network[iface].tx_sec = null;
_network[iface].ms = Date.now();
_network[iface].last_ms = 0;
_network[iface].operstate = operstate;
}
With iface === '__proto__' this misbehaves twice:
_network['__proto__']does not read a missing own property — it invokes the inherited__proto__getter and returnsObject.prototype, which is truthy. Theif (!_network[iface])guard therefore never creates the{}placeholder.- Each following assignment writes onto
Object.prototype.
After one call, rx_bytes, tx_bytes, rx_sec, tx_sec, ms, last_ms and operstate
are visible on every object in the process. A second call takes the other branch
(_network['__proto__'].ms is now truthy) and keeps them updated.
Why the existing sanitizing does not help
The interface name does pass through util.sanitizeString(iface, true) before it is used as
the cache key. That function is a shell metacharacter filter, built to stop command
injection in the netstat / ifconfig invocations — a different threat. Property names made
of letters and underscores are legitimate interface names and pass through untouched:
"a;id" -> "aid"
"a$(id)" -> "aid"
"a|id" -> "aid"
"a`id`" -> "aid"
"__proto__" -> "__proto__" <-- unchanged
"constructor" -> "constructor" <-- unchanged
The sanitizer is doing its job; the gap is that no layer treats the value as an object key.
Reachability
The cache write is guarded incidentally on three of four platform branches. These guards exist for unrelated reasons and are not a deliberate defence:
| Platform | Code path | Reachable with an arbitrary name? |
|---|---|---|
| Linux / Android | fs.existsSync('/sys/class/net/' + ifaceSanitized) |
No — a non-existent interface returns early |
| macOS | requires netstat to emit a data row beyond the header |
No — verified on macOS 27, Object.prototype stays clean |
| Windows | if (rx_bytes && tx_bytes) — requires a real adapter match |
No |
| FreeBSD / OpenBSD / NetBSD | if (!error) { …; result = calcNetworkSpeed(ifaceSanitized, …) } |
Yes — the call sits outside the parsing loop, so any successful netstat exit reaches it, and netstat -ibndI <unknown> prints only its header and exits 0 |
The important part is not that three platforms happen to be safe, but that nothing in the design prevents the write. Any future platform branch without such a guard reopens the issue, which is why the fix is applied at the cache rather than at the call sites.
Age
The pattern predates the v5 line — git log -S "_network[iface] = {}" traces it back to a
refactoring before v3.42.5. The v3 and v4 lines are end of life; the advisory covers v5.
Impact
The attacker controls which attributes appear on Object.prototype but not their values —
those come from the interface statistics (rx_bytes, ms, operstate …). The attribute
names are fixed by the library, so this is not an arbitrary-key pollution primitive.
The consequences are therefore application specific and arise from name collisions:
- Any application code that tests
if (obj.operstate),if (obj.ms)or similar on an object that should not have those properties now takes the wrong branch. for…inloops over plain objects gain seven extra enumerable keys, which can corrupt serialisation, configuration merging or validation logic.- Libraries that use
{}as a lookup map and check membership withinor truthiness can return values for keys that were never inserted.
No path to remote code execution is known, and the values cannot be chosen by the attacker.
Proof of concept
The underlying primitive (any platform)
const { calcNetworkSpeed } = require('systeminformation/lib/network.js'); // internal
const cache = {}; // the declaration used by the library
calcNetworkSpeed('__proto__', 1, 2, 'up', 0, 0, 0, 0);
console.log({}.rx_bytes); // 1
console.log({}.operstate); // 'up'
console.log(Object.prototype.hasOwnProperty('rx_bytes')); // true
End to end through the public API (FreeBSD / OpenBSD / NetBSD)
const si = require('systeminformation');
(async () => {
console.log('before:', {}.operstate); // undefined
await si.networkStats('__proto__'); // an attacker supplied interface name
console.log('after :', {}.operstate); // 'up' -> Object.prototype is polluted
})();
On Linux, macOS and Windows the same call returns an empty result set and leaves
Object.prototype untouched, for the reasons in the Reachability table.
Patch
lib/network.js — give the cache a null prototype, so __proto__ becomes an ordinary own
property instead of a setter into the prototype chain:
-const _network = {};
+const _network = Object.create(null);
This is the smallest change that fixes the class of problem rather than one reachable path:
- It is independent of the platform branches, so no guard has to be added or maintained.
- It keeps behaviour identical for every legitimate interface name —
Object.keys(), member reads and writes all work unchanged on a null prototype object. - It matches the pattern already used elsewhere in the codebase
(
lib/filesystem.js:114-115,lib/graphics.js:1060,lib/graphics.js:1087). Object.createis ES5.1, well below the declaredengines.node >= 10.0.0.
After the patch the hostile name is stored as a normal cache entry:
const cache = Object.create(null);
// ... cache['__proto__'] holds the stats object, Object.prototype is untouched
Workarounds
For users who cannot upgrade immediately, either of these is sufficient:
- Validate the interface name before calling — accept only names returned by
si.networkInterfaces(), or reject the names__proto__,constructorandprototype. - Never pass untrusted input as the
ifacesargument. Passing'*'or omitting the argument is unaffected, because those names come from the system rather than the caller.
Freezing Object.prototype (Object.freeze(Object.prototype)) also prevents the write, but it
has wide-reaching side effects on other dependencies and is not recommended as a general
mitigation.
Affected versions
All 5.x releases up to and including 5.33.12. Earlier major lines contain the same pattern
but are end of life.
What was verified, and what was not
Verified on this machine (macOS 27, Node 24):
- the pollution primitive, by calling the cache write with
iface = '__proto__'; - that
util.sanitizeString('__proto__', true)returns the string unchanged, while shell metacharacters are stripped; - that unpatched v5 on macOS does not pollute through the public API;
- that
netstat -bdnI <unknown-interface>prints only its header and exits0; - that the patch stores the hostile key as an own property and leaves
Object.prototypeclean.
Not verified, because no such host was available:
- end to end exploitation on FreeBSD, OpenBSD or NetBSD. That conclusion is derived from
reading the BSD branch of
networkStatsSingle()— where thecalcNetworkSpeed()call sits outside the row parsing loop and is reached whenevernetstatexits successfully — combined with the observednetstatexit behaviour above. Worth confirming on a BSD host before publishing, since the affected-platform list depends on it.
Affected versions
npm
| Package | Vulnerable | Fixed in |
|---|---|---|
| systeminformation | < 5.33.13 |
5.33.13 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
systeminformation npm → 5.33.13
- npm
npm install systeminformation@5.33.13- yarn
yarn add systeminformation@5.33.13- pnpm
pnpm add systeminformation@5.33.13
Severity breakdown
CVSS 3.1 6.5
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:L
- Attack vector
- Network
- Attack complexity
- High
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- High
- Availability
- Low
Weakness
CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
The product receives input from an upstream component that specifies attributes that are to be initialized or updated in an object, but it does not properly control modifications of attributes of the object prototype.
How to prevent it
- Implementation: By freezing the object prototype first (for example, Object.freeze(Object.prototype)), modification of the prototype becomes impossible.
- Architecture and Design: By blocking modifications of attributes that resolve to object prototype, such as proto or prototype, this weakness can be mitigated.
- Implementation: When handling untrusted objects, validating using a schema can be used.
- Implementation: By using an object without prototypes (via Object.create(null) ), adding object prototype attributes by accessing the prototype via the special attributes becomes impossible, mitigating this weakness.
- Implementation: Map can be used instead of objects in most cases. If Map methods are used instead of object attributes, it is not possible to access the object prototype or modify it.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| CVE-2021-21315 Command Injection Vulnerability | High Known exploited | Also affects systeminformation |
| GHSA-3f7j-7jwc-fxfj systeminformation vulnerable to Windows command injection in services() through Unicode quotation marks | High | Also affects systeminformation |
| GHSA-4vjg-vx72-qq4g systeminformation has path traversal in Linux networkStats() that allows symlink-based file disclosure outside /sys/class/net | Low | Also affects systeminformation |
| GHSA-5xpp-75jx-m839 systeminformation: OS command injection in networkInterfaces() via interfaces(5) source-directive path on Linux | High | Also affects systeminformation |
| GHSA-hvx9-hwr7-wjj9 Systeminformation vulnerable to Linux command injection in networkInterfaces() via unsanitized NetworkManager connection profile name | High | Also affects systeminformation |
| GHSA-5vv4-hvf7-2h46 Command Injection via Unsanitized `locate` Output in `versions()` — systeminformation | High | Also affects systeminformation |
| GHSA-9c88-49p5-5ggf Systeminformation has a Command Injection via unsanitized interface parameter in wifi.js retry path | High | Also affects systeminformation |
| GHSA-wphj-fx3q-84ch systeminformation has a Command Injection vulnerability in fsSize() function on Windows | High | Also affects systeminformation |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor