Memory LanceDB Setup

• Outcome: Review
• Latest audit: Sep 16, 2026 · 4:11 AM UTC
• Version: 1.0.0

Overview

This setup skill is purpose-aligned, but it under-discloses sensitive memory data flow and tells users to modify a global OpenClaw installation with unpinned packages and a direct patch script.

Review before installing. Use only non-secret memory content, do not store tokens or credentials in vector memory, consider a local embedding provider for confidential work, use a dedicated low-quota API key, avoid placing keys in shell history, pin npm package versions where possible, and back up the OpenClaw installation before running the patch script.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (3)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:37
• Finding: Unpinned npm dependencies are installed directly into the OpenClaw installation<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:37-46`; repeated in `references/troubleshooting.md:6-10` and `references/troubleshooting.md:19-26` **Vulnerability Type**: `T08: Insecure Dependencies` **Risk Level**: Medium ### Vulnerable Code ```bash ### 3. Install dependencies # Step 1: install main package in openclaw root cd /usr/local/lib/node_modules/openclaw npm install @lancedb/lancedb # Step 2: install platform-specific native binding in plugin dir cd /usr/local/lib/node_modules/openclaw/extensions/memory-lancedb npm install @lancedb/lancedb-darwin-arm64 # Apple Silicon (arm64) # npm install @lancedb/lancedb-darwin-x64 # Intel Mac # npm install @lancedb/lancedb-linux-x64-gnu # Linux x64 ``` The troubleshooting guide repeats the unpinned installation: ```bash cd /usr/local/lib/node_modules/openclaw npm install @lancedb/lancedb ``` ```bash cd /usr/local/lib/node_modules/openclaw/extensions/memory-lancedb npm install @lancedb/lancedb-darwin-arm64 python3 ~/.openclaw/workspace/skills/memory-lancedb-setup/references/patch_native.py openclaw gateway restart ``` ### Technical Analysis The installation commands do not specify reviewed package versions or integrity hashes. Consequently, npm resolves the packages to whatever versions are current at execution time. The commands also install them directly into a global OpenClaw application tree and an active extension directory. npm packages can contain lifecycle scripts that execute during installation. If the package, a transitive dependency, or the relevant registry account is compromised, installation can execute attacker-controlled code with the permissions of the user running npm. Even without malicious activity, an unexpected release may introduce incompatible or vulnerable behavior into OpenClaw. The use of official-looking package names reduces dependency-confusion risk but does not protect against registry-account compromise, malicious updates, or unreviewed transitive depen ...[truncated 1133 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Pin every direct package to an exact reviewed version, for example: ```bash npm install --save-exact @lancedb/lancedb@<reviewed-version> npm install --save-exact @lancedb/lancedb-darwin-arm64@<reviewed-version> ``` 2. Commit and enforce a lockfile so that transitive dependency versions and integrity values remain reproducible. 3. Prefer `npm ci` against a reviewed lockfile rather than resolving current versions with `npm install`. 4. Review package provenance, publisher history, release signatures, and dependency changes before updating. 5. Disable lifecycle scripts with `--ignore-scripts` when the packages can function without them. If scripts are required, review them before installation. 6. Run installation with the least-privileged account capable of maintaining OpenClaw; do not use administrative elevation unless strictly necessary. 7. Document a tested compatibility matrix of OpenClaw, LanceDB, and architecture-specific binding versions. 8. Apply the same version pins to every command repeated in `references/troubleshooting.md`. ]]>

T09 · Insecure Skill Coding Practices

Warning

• Location: SKILL.md:25
• Finding: Embedding API key is exposed through a command-line argument and persisted without documented protections<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:25-32` **Vulnerability Type**: `T09: Insecure Skill Coding Practices` **Risk Level**: Medium ### Vulnerable Code ```bash ### 2. Configure the plugin openclaw config set plugins.entries.memory-lancedb.enabled true openclaw config set plugins.entries.memory-lancedb.config.embedding.baseUrl "https://generativelanguage.googleapis.com/v1beta/openai/" openclaw config set plugins.entries.memory-lancedb.config.embedding.model "text-embedding-004" openclaw config set plugins.entries.memory-lancedb.config.embedding.apiKey "YOUR_API_KEY" openclaw config set plugins.entries.memory-lancedb.config.embedding.dimensions 768 ``` ### Technical Analysis The instructions encourage users to replace `YOUR_API_KEY` with a real credential directly in a shell command. This can expose the key through shell history and, depending on the operating system and process-inspection permissions, through the process argument list while the command is running. The command also persists the key in OpenClaw configuration. The Skill does not document whether the configuration is encrypted, what filesystem permissions protect it, whether it is included in logs or support bundles, or how the credential should be rotated. This omission creates a risk that the secret will be retained in plaintext or copied into backups and diagnostic artifacts. ### Attack Path 1. A user inserts a real embedding API key into the documented command. 2. The shell records the complete command in its history file. 3. OpenClaw persists the supplied key in its configuration. 4. A local user, process, backup operator, diagnostic collector, or support-bundle recipient obtains access to the history or configuration. 5. The party extracts the key and submits requests to the provider under the victim's account. ### Impact Assessment Exposure allows unauthorized use of the embedding-provider account within the permissions and quotas assigned to the key. Potenti ...[truncated 335 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Do not place the API key directly in a command-line argument. 2. Use OpenClaw's supported secret-management facility, an operating-system keychain, or a dedicated secret manager. 3. If OpenClaw supports environment-variable references, configure a reference rather than the secret value itself: ```bash export EMBEDDING_API_KEY='<secret>' # Configure OpenClaw to resolve the key from EMBEDDING_API_KEY. ``` 4. If interactive entry is supported, read the key without terminal echo and pass it over standard input rather than through process arguments. 5. Ensure any configuration file containing the credential is owned by the OpenClaw account and readable only by that account, such as mode `0600` on applicable Unix-like systems. 6. Exclude secrets from logs, crash reports, support bundles, and unencrypted backups. 7. Document credential rotation and revocation procedures. 8. Advise users who already followed the command to remove the command from shell history and rotate the exposed key. 9. Use a dedicated, least-privileged API key with restrictive quotas and provider-side usage monitoring. ]]>

other

Warning

• Location: SKILL.md:61
• Finding: Sensitive memory content may be disclosed to an external embedding provider<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:9`, `SKILL.md:27-31`, and `SKILL.md:61-68` **Vulnerability Type**: `other: Sensitive Data Disclosure` **Risk Level**: Medium ### Vulnerable Code The Skill describes storage as local: ```text Enables semantic vector memory in OpenClaw: memories stored with `memory_store` are embedded and indexed locally, then recalled on-demand via `memory_recall` — no full-context load. ``` It configures an external Google embedding endpoint: ```bash openclaw config set plugins.entries.memory-lancedb.enabled true openclaw config set plugins.entries.memory-lancedb.config.embedding.baseUrl "https://generativelanguage.googleapis.com/v1beta/openai/" openclaw config set plugins.entries.memory-lancedb.config.embedding.model "text-embedding-004" openclaw config set plugins.entries.memory-lancedb.config.embedding.apiKey "YOUR_API_KEY" openclaw config set plugins.entries.memory-lancedb.config.embedding.dimensions 768 ``` It then recommends migrating potentially sensitive operational information: ```text If MEMORY.md is large, migrate key facts to the vector store and shrink MEMORY.md to a 20-30 line index. Group by topic and call `memory_store` for each: - Identity & permissions - Execution rules - Project configurations (cron IDs, doc tokens) - Technical knowledge (API quirks, field names) - Workflows and SOPs ``` ### Technical Analysis The vector database may be local, but producing embeddings through the configured Google endpoint requires memory text to be transmitted to that external service. The statement that memories are “embedded and indexed locally” can therefore create an incomplete impression of the data flow: indexing may occur locally, while embedding generation is remote. The migration guidance explicitly identifies identity and permission information, execution rules, cron identifiers, and document tokens as candidate content. Document tokens or similar credentials should not be sent to an embeddin ...[truncated 1584 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions 1. Explicitly disclose that memory text is transmitted to the configured external embedding provider before vectors are stored locally. 2. Revise the documentation to distinguish local vector storage from remote embedding generation. 3. Prohibit storing or embedding credentials, API keys, document tokens, session identifiers, private keys, and other authentication material. 4. Replace the recommendation to migrate “doc tokens” with a recommendation to store non-secret aliases or references to a protected secret manager. 5. Add a mandatory redaction step before migration and provide examples of safe transformations: ```text Unsafe: Production document token is abc123... Safer: Production document credential is stored under secret-manager entry DOC_PROD. ``` 6. Offer and document a fully local embedding model for confidential deployments. 7. Require users to review the embedding provider's data-use, logging, regional processing, and retention policies. 8. Minimize transmitted content and apply data-classification rules before invoking `memory_store`. 9. Add controls that reject likely secrets using credential-pattern detection, while noting that automated detection is not sufficient by itself. 10. Advise users to rotate any live tokens that were previously embedded or transmitted. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Rogue Agent: Self-Modification, Session Persistence
• Taint Tracking: Direct Taint Flow, Variable-Mediated Taint Flow, Credential Exfiltration Chain
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands

Findings (4)

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The skill explicitly configures an external embedding endpoint and encourages storing semantic memory without warning that stored memories will be transmitted to a third-party API for embedding. In this context, memory content may contain sensitive project data, credentials, operational rules, or personal information, so users could unknowingly exfiltrate local memory contents to an external provider.

Session Persistence

Medium

• Category: Rogue Agent

Content

### 1. Get a Gemini API Key (free)

Go to [aistudio.google.com](https://aistudio.google.com) → Get API key → Create API key.

### 2. Configure the plugin

• Confidence: 60% confidence
• Finding: 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.

Missing User Warnings

Medium

• Confidence: 91% confidence
• Finding: The script unconditionally modifies a dependency file under /usr/local, which is typically a privileged/shared installation path, without confirmation, backup, integrity verification, or ownership checks. In an agent/skill context, automatic mutation of globally installed code is risky because it can silently alter runtime behavior, break package integrity, and affect other users or processes on the host.

Tainted flow: 'patched' from pathlib.Path.read_text (line 62, file read) → pathlib.Path.write_text (file write)

Medium

• Category: Data Flow

Content

sys.exit(1)

    patched = content.replace(OLD, NEW)
    NATIVE_JS.write_text(patched)
    print("Patched successfully. Run: openclaw gateway restart")

if __name__ == "__main__":

• Confidence: 65% confidence
• Finding: Data from a source is assigned to a variable that is later passed to a sink, creating a variable-mediated taint flow.

Static analysis

No suspicious patterns detected.