Network-AI EUVD-2026-115002

Exploitation requires that the consuming application actually invoke InputSanitizer.sanitizePath(inputPath, basePath) from the network-ai/security export as its terminal path validation, with the attacker controlling inputPath and basePath set to the sandbox root. The specific triggering condition is a sibling directory whose leading component shares a string prefix with the base directory name (e.g. base /data/project with sibling /data/project-evil or /data/project2), supplied in absolute or relative (../project-evil/...) form - that sibling path must exist (or, for the write primitive, be creatable) on the filesystem for a useful operation to occur. Limiting factors: classic ../../../etc/passwd traversal is still correctly rejected, so only prefix-sharing sibling layouts are exploitable; the demonstrated primitive is file read/directory listing (write is argued by the advisory as an expected use of the helper but is not demonstrated); and the PR:N/AV:N reachability is only realized if the consumer exposes the helper to untrusted network input without its own authentication or anchored re-check.

The CVSS 4.0 base score of 8.7 is driven by the most favorable attacker metrics (AV:N/AC:L/AT:N/PR:N/UI:N) with high confidentiality impact (VC:H), which on paper reads as a high-priority remote, unauthenticated issue. However, these metrics describe the helper in isolation: InputSanitizer.sanitizePath() is a library validation function, so whether an attacker can actually reach it unauthenticated over the network, and with attacker-controlled inputPath, depends entirely on how the consuming application exposes it - a fact the CVSS vector cannot capture. Against that, the softer signals point to lower urgency: there is no CISA KEV listing and no EPSS score was provided (so exploitation probability is unquantified here), and vuln.today's decision label is this_week rather than act_now/emergency. A public PoC reference exists in the GHSA advisory, but it reproduces the containment logic in a standalone script rather than exploiting a live deployment, so it demonstrates the defect, not weaponized in-the-wild use. Net: this is a genuine, well-evidenced path-containment bug with a high nominal score, but its real-world priority is moderated by a niche single-author npm package footprint, the absence of active-exploitation and EPSS signals, and the fact that exploitability is consumer-dependent. One signal conflict must be flagged: the CVE/description state a fix in 5.15.5 while the GHSA advisory body states security.ts was never modified and no release addresses this code path - fix availability is contradictory and should be verified with the vendor before relying on an upgrade.

An application uses network-ai's exported InputSanitizer.sanitizePath() as the terminal check to confine file operations to a sandbox base such as /data/project, and accepts a user-supplied path. An attacker submits a sibling path whose directory name shares a string prefix with the base (e.g. /data/project-evil/secret.txt or ../project-evil/secret.txt); the unanchored startsWith check passes, and the caller reads or lists files outside the intended base directory. A public PoC reference in the advisory reproduces this bypass logic, though it is not verified as working exploit code against a live product.