What's the vulnerability?

Inside the versions() function, when detecting the PostgreSQL version on Linux, the code does this:

// 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().

Root Cause Analysis

One Command

Verify with pruva-verify

Run the Pruva CLI to automatically fetch and execute the reproduction script.

pruva-verify REPRO-2026-00100
or pruva-verify GHSA-5vv4-hvf7-2h46
or pruva-verify CVE-2026-26318
Install: curl -fsSL https://pruva.dev/install.sh | sh

Or Run Manually

1

Download the script

curl -O https://pruva.dev/api/v1/reproductions/REPRO-2026-00100/artifacts/repro/reproduction_steps.sh
2

Make executable

chmod +x reproduction_steps.sh
3

Run the script

./reproduction_steps.sh
Run in a VM, container, or disposable environment. This exploits a real vulnerability.

How Pruva Reproduced This

Watch the AI agent's step-by-step process.

Loading session...