T09 · Insecure Skill Coding Practices
Warning
- Location
SKILL.md:22- Finding
Unnecessary Plaintext Persistence and Cross-Skill Access to Full Birth Dates
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 22–27 and 87–103
Vulnerability Type: Plaintext storage and unnecessary exposure of personal data
Risk Level: MediumVulnerable Code
yaml data_access: - path: "MEMORY.md" purpose: "Read/write user's birthday and sun sign for personalized readings" operations: ["read", "write"] - path: "../fortune-hub/MEMORY.md" purpose: "Read shared user profile fields (birthday) to avoid re-asking — fortune-hub is the central profile hub for this multi-skill repository" operations: ["read"]markdown **Reading**: Before generating, check in this order: 1. This directory's `MEMORY.md` — use first 2. `fortune-hub/MEMORY.md` (sibling skill in the same repository) — fill in any missing profile fields If data is available, use it directly without asking again. **Writing**: If the user shares their birthday, write it to **this directory's** `MEMORY.md`: ```markdown # User Profile ## Basic Info - Birthday (Gregorian): YYYY-MM-DD - Sun Sign: [Sign Name] - Sign Period: Early / Middle / Latetext ### Technical Analysis The Skill directs the agent to persist a user's complete Gregorian birth date in a plaintext Markdown file. A full date of birth is identifying personal data, while the documented horoscope personalization logic generally requires only the month and day, derived zodiac sign, and sign-period classification. Retaining the birth year therefore exceeds the apparent minimum data necessary for the stated functionality. The configuration also authorizes reading birth-date information from a sibling Skill's `MEMORY.md`. This broadens the data-access boundary and increases the number of components that can access the profile. The instructions do not specify explicit consent before persistence, a retention period, a deletion procedure, filesystem access restrictions, or source-control exclusions. This is an ...[truncated 1532 chars]- Remediation
View remediation
Remediation Suggestions
- Apply data minimization by storing only the derived sun sign and sign-period classification. If birthday-based behavior is required, retain only month and day unless the year is demonstrably necessary.
- Obtain explicit, informed user consent before writing any profile information to persistent storage. Do not treat merely providing a birthday in conversation as consent to retain it.
- Make persistence opt-in and clearly state what fields will be stored, where they will be stored, and how long they will remain.
- Provide a documented command or workflow for viewing, correcting, and permanently deleting the stored profile.
- Avoid reading sibling Skill memory by default. Require explicit user authorization for cross-Skill profile sharing and restrict access to the minimum fields needed.
- Restrict filesystem permissions so memory files are readable only by the intended user or process.
- Add
MEMORY.mdand equivalent profile files to source-control ignore rules and exclude them from logs, generated artifacts, and unnecessary backups. - Define a retention period and automatically remove stale profile data.
- If a full date of birth must be retained, use an approved protected storage mechanism rather than an unprotected Markdown file.