T02 · Agent Memory Poisoning
- Location
SKILL.md:52- Finding
Unrestricted Persistence of Attacker-Controlled Instructions
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 52-64
Vulnerability Type: Persistent agent memory poisoning
Risk Level: HighVulnerable Code Snippet
markdown ### 2. WAL协议(写前日志) 扫描每条消息,在响应前写入状态: - 用户陈述偏好 → 写入记忆 → 再响应 - 用户做决策 → 写入记忆 → 再响应 - 用户给截止日期 → 写入记忆 → 再响应 - 用户纠正你 → 写入记忆 → 再响应 - 原因:若先响应再崩溃/压缩,上下文丢失;WAL保证持久性 ### 3. 工作缓冲区协议 维护工作缓冲区暂存中间状态: - 格式:当前任务、关键上下文、待办动作、近期决策 - 在响应前更新缓冲区,确保中断可恢复 - 缓冲区作为代理的"短期记忆",区别于长期记忆Technical Analysis
The Skill directs the agent to scan every message and automatically write user-provided preferences, decisions, deadlines, and corrections into memory before responding. It does not require explicit user consent, validate whether the content is safe to retain, distinguish data from executable behavioral instructions, or define trust boundaries for persistent entries.
An attacker can therefore present a malicious behavioral rule as a preference, decision, or correction. The WAL protocol causes that attacker-controlled rule to enter the working buffer or long-term memory. The Skill's documented compression-recovery behavior can later reload the poisoned content and treat it as authoritative context.
No executable implementation of the memory system is included in the project, so exploitation depends on the host agent implementing these instructions and providing persistent storage. The issue is nevertheless present in the Skill's prescribed behavior.
Attack Path
- An attacker submits a statement framed as a preference, decision, or correction, such as a rule instructing the agent to ignore future validation requirements.
- The WAL protocol classifies the statement as information that must be stored before the agent responds.
- The attacker-controlled rule is written to the working buffer or long-term memory without approval, sanitization, provenance-based trust evaluation, or expiration.
- In a later interaction or after context compr ...[truncated 873 chars]
- Remediation
View remediation
Remediation Suggestions
- Require explicit user confirmation before creating or modifying cross-session memory.
- Persist only narrowly typed data, such as display preferences, approved project decisions, and verified deadlines.
- Never store executable instructions, security-policy changes, tool-use directives, authentication information, or commands as ordinary preferences.
- Separate untrusted conversation-derived memories from trusted system policy and ensure memory content cannot override higher-priority instructions.
- Record provenance, author identity, creation time, intended scope, confidence, and expiration for every memory entry.
- Isolate memory by user, tenant, workspace, and project to prevent cross-context contamination.
- Add validation that detects prompt-injection patterns and rejects entries attempting to change safety controls or future agent behavior.
- Present proposed memory writes to the user for approval and provide review, correction, export, and deletion controls.
- Treat restored memory as untrusted reference data rather than authoritative instructions.
- Apply retention limits and periodically remove stale or unverified entries.
- Log memory creation and restoration events so poisoned entries can be traced and revoked.
- Add tests proving that malicious statements disguised as preferences or corrections cannot become persistent behavioral rules.