T09 · Insecure Skill Coding Practices
- Location
hooks/memory-system/handler.js:29- Finding
Shell Command Injection Through OPENCLAW_USER_ID During Agent Bootstrap
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This memory skill does what it advertises, but it has serious privacy and safety gaps around remote embeddings, automatic persistent memory, identity handling, and setup-time credential storage.
Install only after reviewing the privacy model and setup script. Treat stored memories as sensitive data, assume memory and search text may be sent to Zhipu AI, avoid using the automatic extractor on private content without review, remove the hard-coded default user identity, fix the shell command construction, and do not store API keys in ~/.bashrc.
hooks/memory-system/handler.js:29Shell Command Injection Through OPENCLAW_USER_ID During Agent Bootstrap
skills/memory/auto_memory.py:89Persistent Cross-Session Prompt Injection Through Automatically Stored Memory
skills/memory/lancedb_memory.py:193LanceDB Filter Injection Can Break User Isolation
hooks/memory-system/handler.js:28Hard-Coded Default User Identity Can Expose Another User's Memories
skills/memory/lancedb_memory.py:36Memory and Search Content Is Transmitted to an External Embedding Service Contrary to Privacy Claims
enable.sh:37Setup Script Stores the API Key in Plaintext and Allows Shell Profile Injection
requirements.txt:4Automatically Installed Dependencies Are Not Reproducibly Pinned
skills/memory/session_start.py:57Session Start Utility Can Overwrite Arbitrary Files Accessible to the Process
The documentation states that memory data is 'never uploaded to any server', yet the skill also documents use of a remote Zhipu AI embedding API. Generating embeddings for memory content typically requires sending that content, or a substantial representation of it, to the external provider, so the privacy claim is materially misleading and may cause users to expose sensitive data under false assumptions.
The automatic memory extraction feature analyzes arbitrary user messages and saves extracted content as memories, yet the docs provide no warning that user inputs may be automatically interpreted, retained, and reused. This is more dangerous than manual storage because developers may enable passive collection by default, causing unnoticed capture of sensitive information and later prompt-context leakage.
The documented rm -rf memory_lancedb/ command is a destructive shell operation that can be copied directly by users. In skill context, this is more dangerous because it is presented as the prescribed way to manage memory deletion, normalizing unsafe command execution and risking irreversible data loss if the working directory or path is wrong.
A: 目前不支持直接删除,可以清理整个数据库:
rm -rf memory_lancedb/
YARA rule matched a known malware signature (reverse shell, backdoor, ransomware, C2 framework, or info stealer).
law_lance
### 2. 创建虚拟环境
```bash
python3 -m venv venv
source venv/bin/activate # Linux/macOS
# 或
venv\Scripts\activate # Windows
pip install -r requirements.txt
获取智谱 AI API Key: https://open.bigmodel.cn/
# 临时设置
export ZHIPU_API_KEY="your-key-here"
# 永久设置(添加到 ~/.bashrc)
echo 'export ZHIPU_API_KEY="your-key-here"' >> ~/.bashrc
source ~/.bashrc
python3 skill.py stats
如果显示统计信息,说明安装成功!
# 方法 1: 使用启用脚本
bash enable.sh
# 方法 2: OpenClaw 命令
openclaw hooks enable memory-system
python3 --version # 需要 3.8+
如果版本过低,请升级 Python。
# 升级 pip
pip install --upgrade pip
# 使用国内镜像
pip install -r requirements.txt -i https://pypi.tun
YARA rule matched a known malware signature (reverse shell, backdoor, ransomware, C2 framework, or info stealer).
Y" ]; then
echo ""
echo "⚠️ ZHIPU_API_KEY not set"
echo ""
echo "Please get your API key from: https://open.bigmodel.cn/"
echo "Then add to ~/.bashrc:"
echo ""
echo " export ZHIPU_API_KEY='your-key-here'"
echo ""
echo "Or set it now:"
read -p "Enter ZHIPU_API_KEY: " api_key
if [ -n "$api_key" ]; then
export ZHIPU_API_KEY="$api_key"
echo "export ZHIPU_API_KEY='$api_key'" >> ~/.bashrc
fi
fi
# Test memory system
echo ""
echo "🧪 Testing memory system..."
if python3 skill.py stats > /dev/null 2>&1; then
echo "✅ Memory System is ready!"
else
echo "❌ Memory system test failed"
exit 1
fi
echo ""
echo "=============================="
echo "✅ Setup Complete!"
echo ""
echo "Next steps:"
echo " 1. Set ZHIPU_API_KEY (if not set)"
echo " 2. Run: python3 skill.py profile"
echo " 3. Add memory: python3 skill.py add --content '...' --type preference"
echo ""
The skill markets itself as local and privacy-safe while simultaneously requiring a third-party embedding service, without a clear warning that user memory content may leave the local environment. In a memory system, this is especially sensitive because stored content may include personal preferences, tasks, and background facts that users would reasonably expect to remain local.
The documentation explicitly describes storing user memories and building system prompts from them, but it does not warn about persistence, sensitivity, consent, retention, or privacy boundaries. In a memory-management skill, this omission can lead integrators to collect and reuse personal data in prompts without informing users, increasing the risk of privacy violations and inappropriate disclosure.
The FAQ states that all data remains local and is never uploaded, but elsewhere says embeddings require calling an external API. This is a misleading security/privacy claim that can cause users to expose sensitive memory content under false assumptions about data locality.
The documentation recommends a destructive rm -rf memory_lancedb/ command to delete memory data without a prominent warning about irreversible data loss. Users may execute it casually and wipe all stored memories or, depending on context and path confusion, delete unintended data.
The document describes retrieving user memory from LanceDB and injecting it into agent context at bootstrap without any notice about consent, data minimization, retention, or visibility boundaries. In a memory system, this can expose sensitive prior-user data to prompts, tools, logs, or downstream model providers, making privacy leakage a realistic risk.
Code scans file system directories looking for sensitive files. This could be reconnaissance for credential theft.
ls -la ~/.openclaw/hooks/memory-system/
应该包含:
The guide instructs users to add, auto-extract, export, and clean up persistent memory containing personal preferences, facts, and tasks, but provides no privacy notice, consent guidance, retention expectations, or deletion caveats. In a memory-management skill, this omission can lead to unintended storage or disclosure of sensitive user data and unsafe operational use by integrators.
The script presents itself as a routine setup helper, but it also persistently alters the user's shell startup file by appending an API key export to ~/.bashrc. That creates a lasting side effect involving sensitive data storage, and the change is not surfaced as a distinct security-relevant action requiring explicit informed consent.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
echo "✅ Python version: $(python3 --version)"
# Create virtual environment if not exists
if [ ! -d "venv" ]; then
echo "📦 Creating virtual environment..."
python3 -m venv venv
The script instructs the user to add the API key to ~/.bashrc, encouraging persistent storage of a sensitive credential across sessions. While common in developer tooling, persisting secrets in shell init files expands exposure and should be treated as a security-sensitive design choice.
echo "⚠️ ZHIPU_API_KEY not set"
echo ""
echo "Please get your API key from: https://open.bigmodel.cn/"
echo "Then add to ~/.bashrc:"
echo ""
echo " export ZHIPU_API_KEY='your-key-here'"
echo ""
The script reads a secret from the terminal and persists it to ~/.bashrc without warning the user that this stores the credential in plaintext on disk. Plaintext secret persistence increases the chance of accidental disclosure through backups, dotfile sync, shell history adjacent handling, local compromise, or overly broad file permissions.
This hook explicitly loads long-term user memory from a vector database and injects it into the system prompt during bootstrap, but the description provides no clear user-facing warning or consent language about this sensitive data flow. Because bootstrap occurs before normal workspace context is injected, the memory may influence all subsequent agent behavior and expose personal data more broadly than a user expects.
The environment variable description assumes a specific locale and user identity context (Chinese-language text and a default tied to a particular Feishu user ID) without indicating user choice or neutral defaults. This can lead to privacy, misbinding, or deployment errors where memory is fetched for the wrong user or where behavior is implicitly tailored to one language/community without consent.
The hook launches an external Python process using a shell-constructed command string and feeds it environment-derived inputs, including a user identifier and an API key. In a bootstrap hook this is more dangerous because it runs automatically and can execute attacker-controlled code if the workspace, virtualenv, script path, or environment are tampered with, creating a path to credential exposure or arbitrary code execution.
The hook explicitly passes ZHIPU_API_KEY into a subprocess without disclosure, scoping, or assurance that the called script is trusted. Because this executes during bootstrap and the script lives under workspace-controlled paths, a modified script can exfiltrate the secret or misuse it for external API calls without user awareness.
The auto_extract path automatically derives memories from a user message and immediately persists them via save_memories(extracted) with no consent prompt, dry-run mode, or visibility before storage. In a memory system, messages can contain sensitive personal, confidential, or regulated data, so silent persistence increases privacy risk and can store information the user did not intend to retain.
The cleanup command deletes expired memories immediately and returns only a success count, with no confirmation, preview, or safeguard against accidental invocation. While this is primarily an integrity/availability issue rather than a direct exploit path, it can still cause unintended data loss, especially if expiration policies are misconfigured or users do not realize cleanup is destructive.
The code persists extracted memories automatically once they are identified, with no confirmation, notice, or opt-in from the user. Because the extraction patterns target personal preferences, work details, and tasks, this can silently store sensitive or regulated personal data that the user did not intend to make persistent.
The conversation processor iterates through all user messages and automatically extracts and stores statements as persistent memory without sensitivity classification, minimization, or consent. In a memory skill context, this is especially risky because users may reveal personal identity, employment, plans, or other sensitive facts in ordinary conversation, and the system will retain them by default.
The test harness hard-codes a concrete user identifier, which can leak or normalize use of a real-looking account ID in source, logs, screenshots, or copied test environments. Even if only used in local testing, embedding identifiers in code increases the risk of unintended data access, privacy exposure, and unsafe reuse in production-like contexts.
Detected: suspicious.dangerous_exec