T05 · Unauthorized Access and Privilege Escalation
- Location
SKILL.md:82- Finding
Cross-Skill Persistent Memory Access Violates Least Privilege
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 82–83
Vulnerability Type: Cross-skill memory access
Risk Level: LowVulnerable Code
markdown 1. This skill's `MEMORY.md` — any stored user preferences (e.g., preferred spread, common topics) 2. The same repo's `fortune-hub/MEMORY.md` (if it exists) — no need for basic profile fields, just check for relevant preferencesTechnical Analysis
The skill explicitly instructs the agent to read persistent memory belonging to the separate
fortune-hubskill. A tarot reading does not require access to another skill's state, so this crosses a logical authorization boundary and violates the principle of least privilege.The restriction to “relevant preferences” reduces the intended scope but is not an enforceable access control. The agent must still open and process the sibling memory file to determine which fields are relevant. Consequently, unrelated or sensitive information in that file may enter the agent's context. The project contains no field-level allowlist, user-consent check, access-control mechanism, or isolation layer governing this read.
No instruction to transmit the information externally, access credentials, modify sibling memory, or execute content from the file was found.
Attack Path
- A user invokes the tarot-reading skill.
- The skill directs the agent to inspect its own
MEMORY.md. - The agent is then directed to locate and read the sibling
fortune-hub/MEMORY.md. - The sibling file's contents enter the tarot skill's active context, including any information beyond the preferences actually needed.
- Those contents may influence the generated reading or be unintentionally reflected in the response.
If another party or skill can place misleading content in the sibling memory file, that content could also influence the tarot response. The audited files do not establish that such write access exists, so this is a con ...[truncated 600 chars]
- Remediation
View remediation
Remediation Suggestions
- Remove the instruction to read
fortune-hub/MEMORY.md; default to reading only memory owned by the tarot skill. - If shared preferences are required, request explicit user authorization before accessing cross-skill state.
- Replace direct file access with a scoped preference interface that returns only allowlisted fields, such as
preferred_spreadandcommon_topics. - Enforce per-skill memory namespaces and deny arbitrary sibling-memory reads at the tool or runtime permission layer.
- Treat memory content as untrusted data rather than executable instructions, and prevent it from overriding system, developer, or active user directives.
- Avoid loading the complete shared memory file into the model context; retrieve only the specifically authorized fields needed for the current request.
- Add tests confirming that invoking this skill cannot read unrelated profile data or state owned by other skills.
- Remove the instruction to read
