T02 · Agent Memory Poisoning
- Location
scripts/forge.py:535- Finding
Untrusted Repair Reports Can Poison Cross-Project Agent Memory
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
Forge is a coherent repair-automation skill, but users should review it carefully because it persists model-generated repair patterns across projects and can automatically run a repository-provided Python checker.
Install only if you are comfortable with an automated repair workflow that writes project state, creates task/result files, may direct agents to edit and test code, and advertises auto-commit behavior. Avoid using it on untrusted repositories unless you disable or remove automatic doc-sync checker execution and isolate or review cross-project reflections before they are reused.
scripts/forge.py:535Untrusted Repair Reports Can Poison Cross-Project Agent Memory
scripts/forge.py:836Summary Generation Automatically Executes Repository-Controlled Python Code
Skill manipulates agent memory, state, or stored context. Memory corruption can alter personality, override safety rules, or cause unpredictable behavior.
| `status` | Show current progress |
| `check` | Pre-commit safety check (protected files, deletions) |
| `summary` | Generate completion report |
| `reset` | Clear state |
## How It Works
The protocol explicitly states that a PASS result leads to an automatic commit, but it does not require an explicit user-facing warning or consent before modifying repository history. In this context, the skill is designed to make autonomous code changes, so silent or insufficiently disclosed commit behavior can cause unauthorized state changes, hide risky edits behind automation, and increase operational and supply-chain risk.
The skill clearly instructs use of shell execution and project file creation/modification, but it does not declare an explicit tool scope such as allowed tools or permissions. That omission weakens containment and review because an agent may infer broad shell and filesystem authority without user-visible boundaries, which is especially risky in a skill that orchestrates automated repair loops and commits changes.
The skill advertises auto-commit behavior on success, but does not give a prominent warning or require explicit consent before creating git commits. In an automated multi-step repair workflow, this can cause repository state changes that users did not intend, potentially persisting faulty or policy-violating changes and complicating rollback or audit trails.
The template explicitly requires dynamic validation by actually running code and using real data, but it does not include any safety constraints, sandboxing requirements, or warnings about effects on production systems and sensitive data. In a repair-orchestration skill, this increases the chance that an inspector agent executes untrusted or recently modified code in a live or data-bearing environment, causing data corruption, leakage, or unintended side effects.
The skill instructions and operational text are entirely in Chinese, with no indication that users may choose another language or that the locale restriction is required for a region-specific purpose. This can violate language/locale policy when a skill imposes a language without opt-in.
The trigger conditions include broad natural-language activations such as user requests to "fix X" / "resolve X", which can cause the skill to launch on ambiguous, everyday phrasing without explicit confirmation of scope. In a skill that performs automated repair loops and can proceed to commits, overbroad activation increases the chance of unintended code modification workflows being started from casual or underspecified requests.
This Python file contains user-facing natural-language instructions and CLI messaging entirely in Chinese, including the top-level description and usage guidance. The skill does not indicate that language is configurable or that users may opt into another locale, which can violate a language/locale policy requiring user choice.
The skill persists model-generated repair patterns outside the target workdir into a shared cross-project store and later re-injects them into future repair prompts. That creates a cross-project prompt/data contamination channel where one malicious or sensitive project can influence later runs or leak project-specific knowledge despite the attempted heuristic generalization.
subprocess module calls execute external commands. Without careful input validation, this enables command injection.
try:
# Get staged changes
diff_result = subprocess.run(
["git", "diff", "--cached", "--name-only"],
capture_output=True, text=True, cwd=str(workdir)
)
subprocess module calls execute external commands. Without careful input validation, this enables command injection.
if not changed:
# Check unstaged too
diff_result = subprocess.run(
["git", "diff", "--name-only"],
capture_output=True, text=True, cwd=str(workdir)
)
subprocess module calls execute external commands. Without careful input validation, this enables command injection.
result["violations"] = [f"受保护文件被修改: {v}" for v in violations]
# Check deletions
del_result = subprocess.run(
["git", "diff", "--diff-filter=D", "--name-only"],
capture_output=True, text=True, cwd=str(workdir)
)
subprocess module calls execute external commands. Without careful input validation, this enables command injection.
result["violations"].append(f"文件被删除: {', '.join(deleted)}")
# Check change size
stat_result = subprocess.run(
["git", "diff", "--stat"],
capture_output=True, text=True, cwd=str(workdir)
)
This logic discovers and runs a repository-local script unrelated to core repair orchestration, effectively granting arbitrary code execution to the analyzed project during a summary/doc-sync step. Because the tool is meant to operate on potentially untrusted codebases, automatically executing helper code from that codebase is especially dangerous in context.
The script executes a project-local helper from the target workdir, which means untrusted repository contents can cause arbitrary code execution when summary/doc-sync checks are run. In a repair orchestrator that may be pointed at many external projects, treating repo-local Python as trusted materially expands the attack surface beyond simple file inspection.
checker = workdir / "scripts" / "tools" / "doc-sync-checker.py"
if checker.exists():
try:
result = subprocess.run(
[sys.executable, str(checker), "--json"],
capture_output=True, text=True, cwd=str(workdir), timeout=30
)
The skill title and multiple operational examples are presented in Chinese, including task descriptions and workflow sections, but the document does not state that language is optional or user-selectable. This can violate language/locale policy when a skill effectively assumes a specific language without user opt-in.
All user-facing instructions in the file are in Chinese, and there is no indication that the user can opt into another language or that the locale restriction is intentionally scoped. This can violate language/locale policy when a skill forces a specific language without user choice.
No suspicious patterns detected.