Quick answers
- Is CVE-2026-26318 exploited in the wild?
- No. Junglewise Threat Intelligence has no report of CVE-2026-26318 being exploited in the wild.
- How severe is CVE-2026-26318?
- High severity, with a CVSS score of 8.8, published 19 February 2026.
- Which products and versions are affected?
- systeminformation (npm) < 5.31.0, SEMVER:introduced=0,fixed=5.31.0; Red Hat Developer Hub 1.
- Is there a fix for CVE-2026-26318?
- Yes. systeminformation (npm): upgrade to 5.31.0 or later. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
- How is CVE-2026-26318 attacked?
- It is attacked with local access, in a software library.
- Am I affected by CVE-2026-26318?
- Check whether you run systeminformation (npm) or Red Hat Developer Hub at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.
How to fix
- systeminformation (npm): upgrade to 5.31.0 or later
npm install systeminformation@5.31.0
Technical details
The vulnerability exists in lib/osinfo.js within the versions() function. On Linux systems, the code executes `locate bin/postgres`, splits and sorts the output alphabetically, then concatenates the last result into a second exec() call: `exec(postgresqlBin[postgresqlBin.length - 1] + ' -V', ...)`. Because Linux filenames can contain semicolons and exec() passes strings through /bin/sh -c, a malicious filename like `/var/tmp/x;touch /tmp/pwned;/bin/postgres` will cause the shell to interpret the embedded command as a separate statement. The locate command reads from the system-wide plocate.db or mlocate.db database, which is automatically updated daily (via systemd timers or cron) and indexes all readable files on the filesystem. An attacker needs local file creation rights, the locate command to be installed, and a PostgreSQL binary already indexed for this to be exploitable. The code path is Linux-only and has no sanitization (sanitizeShellString() is not used). The fix in version 5.31.0 uses execFile() instead of exec() or adds proper path validation, preventing shell interpretation of filenames.
Affected products
- sebhildebrandt systeminformation <= 5.30.7
Identifiers
- CVE-2026-26318
- GHSA-5vv4-hvf7-2h46
Timeline
- 2026-02-18: disclosed: GHSA-5vv4-hvf7-2h46 published
- 2026-02-15: patched: Fix committed (version 5.31.0)
References
- https://github.com/sebhildebrandt/systeminformation/security/advisories/GHSA-5vv4-hvf7-2h46
- https://github.com/sebhildebrandt/systeminformation/commit/b67d3715eec881038ccbaace2f2711419ac3e107
- https://access.redhat.com/security/cve/CVE-2026-26318
- https://bugzilla.redhat.com/show_bug.cgi?id=2441124
- https://github.com/sebhildebrandt/systeminformation
- https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-26318.json