T05 · Unauthorized Access and Privilege Escalation
- Location
SKILL.md:117- Finding
Automatic Persistent Memory Access and Initialization Without Explicit User Consent
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 117–123 and 164–172
Vulnerability Type: Persistent data access beyond the immediate task scope
Risk Level: MediumRelevant Skill Instructions:
markdown ## Memory System The framework includes a persistent memory system for cross-session continuity. ### Loading Memory At session start, load memory context: - Read `memory/MEMORY.md` for curated long-term facts - Read today's log: `memory/logs/YYYY-MM-DD.md` - Read yesterday's log for continuitymarkdown ## First Run Initialization On first session in a new environment: 1. Check if `memory/MEMORY.md` exists 2. If missing, create the folder structure: - `memory/logs/` - `data/` 3. Create `MEMORY.md` with template 4. Initialize SQLite databases for memory and activity trackingTechnical Analysis
The skill directs the agent to read persistent memory and recent activity logs automatically at session startup. It also directs the agent to create persistent memory files, directories, and SQLite databases when they do not already exist.
These actions are not conditioned on explicit user authorization, a demonstrated need for the current task, or a clearly defined filesystem boundary. Consequently, activating the skill for a general application-development task could cause the agent to access historical information unrelated to the current request. The loaded files could contain private user data, confidential project information, or untrusted content from earlier sessions.
The instructions also lack controls governing what information may be retained, how long it may be retained, and when it must be deleted. They do not explicitly prohibit storing credentials, tokens, raw conversations, or other sensitive information.
The audited file does not instruct the agent to exfiltrate memory, execute content loaded from memory, or write attacker-controlled rules into ...[truncated 1757 chars]
- Remediation
View remediation
Remediation Suggestions
- Require explicit, informed user consent before reading existing memory files or enabling cross-session persistence.
- Disable persistent memory by default and make it an opt-in capability for tasks that genuinely require continuity.
- Restrict all memory access to a canonicalized, user-approved, project-local directory. Reject path traversal, symbolic-link escapes, and paths outside that boundary.
- Request authorization separately before creating files, directories, or SQLite databases.
- Define an allowlisted schema for retained information and prohibit storage of credentials, API keys, authentication tokens, raw conversations, personal data, and unrelated project content.
- Apply data minimization, expiration periods, size limits, deletion controls, and an auditable record of memory reads and writes.
- Treat loaded memory as untrusted reference data. Never interpret its contents as system instructions, executable commands, or authorization to invoke tools.
- Load only memory entries explicitly associated with the active project and task rather than automatically loading current and previous daily logs.
- Document the exact files accessed, the reason for access, the retention period, and how users can inspect or delete stored information.
- Use restrictive filesystem permissions and parameterized SQLite operations in any future implementation of the documented memory system.
