T09 · Insecure Skill Coding Practices
- Location
SKILL.md:288- Finding
Path Traversal Through Attacker-Controlled Fan Record Names
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 288–291, 319, and 373–376
Vulnerability Type: Path traversal in file read and write operations
Risk Level: MediumRelevant Skill Instructions
Faithful English translation of the security-relevant instructions:
text 1. Locate {config.paths.chats}/{nickname}.md using the nickname. 2. If no nickname is supplied, read {config.paths.chats}/_overview.md. 3. For a new person, create a record and derive the nickname from "source + the first few characters of the original message." Store one record per person at: {config.paths.chats}/{nickname}.md Write the reply verbatim to: {config.paths.replies}/YYYY-MM-DD-{nickname}-RoundN.txtTechnical Analysis
The Skill directs the agent to derive a fan nickname partly from externally supplied message content and then interpolate that nickname directly into filesystem paths. It does not require normalization, separator removal, basename enforcement, or verification that the resolved path remains inside the configured chat or reply directory.
A fan is an independent external party in this workflow. Consequently, content supplied by that fan crosses a trust boundary when it is converted from conversational data into a filesystem path used under the account owner's agent permissions.
A nickname containing path separators or traversal components such as
../../MEMORYcould cause the resulting path to resolve outsideconfig.paths.chatsorconfig.paths.replies. The forced.mdor.txtextension limits the set of target filenames but does not prevent directory traversal. The instructions also require later reads and updates of these derived paths, making the unsafe path reachable through the documented workflow.No evidence indicates that the project author deliberately intended this behavior. It is therefore classified as an exploitable coding flaw rather than malicious persistence or intention ...[truncated 1715 chars]
- Remediation
View remediation
Remediation Suggestions
- Assign each fan an internally generated opaque identifier and use that identifier, rather than message content, as the filesystem basename.
- If readable names are required, apply a strict allowlist such as ASCII letters, digits, underscores, and hyphens.
- Reject absolute paths, path separators,
.and..components, control characters, null bytes, and platform-specific reserved names. - Resolve the configured base directory and candidate destination to canonical absolute paths before every read or write.
- Verify that the resolved destination is a descendant of the configured base directory; abort if containment validation fails.
- Maintain an internal mapping between display names and safe record identifiers rather than reconstructing paths from display text.
- Use collision-safe file creation and avoid silently replacing an existing record belonging to another fan.
- Apply the same validation to chat records, overview updates, reply drafts, clipboard source paths, and every later operation that reuses the nickname.