fix(browser-runtime): prevent path traversal in SKILL_API filesystem bridge (CWE-22)

[sebastiondev]

Summary

The SKILL_API.fs.* bridge in packages/browser-runtime/src/lib/vm/skill-api.ts passes paths supplied by skill code directly to the zenfs filesystem mounted at /skills. Because no path validation occurs, a skill can read, overwrite, or delete files belonging to other installed skills by using .. segments or absolute paths — breaking the per-skill isolation that the QuickJS sandbox is intended to enforce.

• CWE: CWE-22 — Improper Limitation of a Pathname to a Restricted Directory
• Affected file: packages/browser-runtime/src/lib/vm/skill-api.ts
• Affected surface: all 14 fs methods exposed to skills (readFile, writeFile, readdir, exists, mkdir, rm, stat, plus the *Sync variants)
• Trust boundary: sandboxed skill code → host-side virtual filesystem

Data flow (before fix)

skill code (untrusted)
  → SKILL_API.fs.readFile("../other-skill/secrets.json")
  → zenfs.readFile("../other-skill/secrets.json")   // raw, unvalidated
  → reads /skills/other-skill/secrets.json

A malicious or compromised skill running under skillId evil could:

• fs.readFile("../victim/credentials.json") — read another skill's data
• fs.writeFile("/skills/victim/index.js", payload) — overwrite another skill's code
• fs.rm("../victim", { recursive: true }) — delete another skill entirely
• fs.readdir("/skills") — enumerate every installed skill

Fix

Introduce a resolveSafePath(skillId, userPath) helper and route every fs.* call through it before invoking zenfs.

The helper:

1. Rejects paths containing null bytes (defense against truncation tricks).
2. Resolves the user-supplied path against the skill's own root (/skills/<skillId>) using posix.resolve, which collapses ../. segments and absorbs absolute paths into the resolved string.
3. Verifies the resolved path is exactly skillRoot or starts with skillRoot + "/". The trailing slash is important — it prevents the sibling-prefix bypass where /skills/abc-evil would otherwise be accepted as "starting with" /skills/abc.
4. Throws a descriptive error otherwise.

All 14 fs methods (async + sync) are updated to call safePath(). There is no parallel code path that bypasses the helper.

const resolved = posixPath.resolve(skillRoot, userPath);
if (resolved !== skillRoot && !resolved.startsWith(`${skillRoot}/`)) {
  throw new Error(`[SKILL_API] Path traversal denied: "${userPath}" ...`);
}

Tests

Added 25 new unit tests in skill-api.test.ts covering:

• Plain .. traversal (../other/file, ../../etc/passwd)
• Absolute-path injection (/skills/other, /etc/passwd)
• Mixed segments (sub/../../other)
• Sibling-prefix bypass attempts (/skills/<id>-evil/...)
• Null-byte injection
• Legitimate in-scope paths (relative and absolute forms of the skill's own files)
• Coverage of every fs method, including the *Sync variants

Full test suite (npm run preflight) passes locally, including pre-existing tests.

Security analysis

Why this is exploitable. Skills are explicitly designed to run untrusted third-party code in QuickJS, and the per-skill /skills/<skillId>/ directory is the isolation boundary that callers rely on. The fs bridge previously passed paths through verbatim, so any skill could enumerate or mutate any other skill's files using standard path traversal — no exotic primitives required.

Preconditions. The user installs or runs a malicious skill. This is precisely the threat model the QuickJS sandbox exists to contain; treating it as a precondition would defeat the purpose of the sandbox. The fix is what makes cross-skill isolation actually hold.

What the fix prevents. Cross-skill read, write, and delete; enumeration of installed skills via /skills; escapes to arbitrary virtual-FS paths. It does not change behavior for legitimate in-scope paths.

Adversarial review

Before submitting, we tried to disprove this. We checked whether zenfs itself enforces a chroot-style boundary on the /skills mount (it doesn't — it's a generic filesystem), whether the QuickJS marshalling layer normalizes or restricts paths (it forwards them as plain strings), and whether installation flows somehow prevent a skill from issuing arbitrary fs calls (they don't — the bridge is the only gate). We also confirmed there isn't a separate vetting/signing step that would make malicious skills out-of-scope; skills are user-installable and the sandbox is the documented trust boundary. The traversal is therefore reachable from the intended attacker model and not mitigated elsewhere.

cc @lewiswigmore