T09 · Insecure Skill Coding Practices
- Location
SKILL.md:72- Finding
Unrestricted Caller-Controlled Persistence Path
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 72-76; additional usage example at lines 113-117
Vulnerability Type: Unrestricted file path and unsafe local persistence
Risk Level: MediumVulnerable Code Snippet
markdown ### 4. 本地持久化 保存记忆到磁盘文件,重启后可加载. - **参数**:`persistPath`(默认 `./memory-store.json`) - **用法**:`action: "save"` 保存,`action: "load"` 加载 - **输出**:持久化文件The caller-controlled path is subsequently demonstrated without any restrictions:
typescript await skills.memoryOrchestrator({ action: "save", persistPath: "./my-memory.json" });Technical Analysis
The Skill directs the Agent to save and load memory through a caller-supplied
persistPath, but it does not define any validation, canonicalization, allowlisted storage root, symlink defense, overwrite protection, or file-permission requirements.Consequently, an implementation that follows the documented behavior directly may accept absolute paths or traversal sequences such as
../../target-file. The documented load operation presents a corresponding unauthorized-read risk if arbitrary paths can be selected. Because the repository contains onlySKILL.mdand no implementation, the exact runtime behavior cannot be verified; the confirmed defect is that the security-sensitive persistence contract omits required path controls.Memory entries may contain user preferences or other conversation-derived information. The document also does not require encryption, restrictive file permissions, or filtering of sensitive content before plaintext JSON persistence.
Attack Path
- An attacker supplies an
action: "save"oraction: "load"request with a craftedpersistPath. - The path uses an absolute location, directory traversal, or a symlink under an otherwise allowed directory.
- The Agent follows the Skill instructions and performs the requested file operation without canonical path validation.
...[truncated 736 chars]
- An attacker supplies an
- Remediation
View remediation
Remediation Suggestions
- Store all memory files beneath a dedicated, application-controlled directory.
- Reject absolute paths, null bytes, device paths, and path components containing
... - Canonicalize both the storage root and requested destination, then verify that the destination remains beneath the approved root.
- Do not follow symbolic links; use platform-safe file APIs that prevent symlink races where available.
- Generate server-side filenames or validate identifiers against a strict allowlist instead of accepting arbitrary paths.
- Separate read and write authorization and only permit approved memory-store files to be loaded.
- Use atomic writes through a securely created temporary file followed by an atomic rename.
- Create files with restrictive permissions and document how sensitive memory content is protected or excluded.
- Refuse to overwrite existing unrelated files unless an explicit, validated replacement operation is requested.
