T09 · Insecure Skill Coding Practices
- Location
guard.mjs:45- Finding
Protected-file overwrite through non-canonical shared-state paths
- Content
View full analysis
p.test(filePath)); } ``` ```js if (toolName === 'Write') { // Path-based shared state gets Write access (workspace files, harness memory). // Checked before exact-match so workspace TOOLS.md/MEMORY.md are writable. // Name-based shared state (SHARED_STATE_FILES) still goes through exact-match // to prevent accidental overwrites of SHARED-CONTEXT.md outside known paths. if (SHARED_STATE_PATHS.some(p => p.test(filePath))) { process.exit(0); } ``` ### Technical Analysis The hook applies regular-expression allowlists directly to the untrusted path string supplied in `tool_input.file_path`. It does not first normalize the path with `path.resolve()`, canonicalize existing paths with `realpathSync()`, or verify that the resulting target remains inside an authorized shared-state directory. The shared-state check occurs before exact protected-filename enforcement. Consequently, any raw path containing a permitted substring such as `.openclaw/workspace/` is allowed, even when `..` components cause the filesystem operation to resolve outside that directory. Similar discrepancies can arise from symbolic links placed inside an allowed directory. A path ...[truncated 1395 chars]- Remediation
View remediation
