OpenClaw EverMemory Installer

• Outcome: Review
• Latest audit: Sep 12, 2026 · 12:53 AM UTC
• Version: 1.0.4

Overview

The skill matches its installer/publisher purpose, but some publish and verification scripts under-enforce their own safety checks for public release workflows.

Review the scripts before installing or publishing. Treat npm publishing as a public release, inspect the package contents first, run the documented release and benchmark gates manually, and do not rely on verify_install.sh alone as proof that the memory slot and skill readiness checks passed.

A.I.G

Vulnerability Patterns

• 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
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/verify_install.sh:9
• Finding: Mandatory installation verification failures are suppressed## Vulnerability Details **File Location**: `scripts/verify_install.sh`, lines 9–15 **Vulnerability Type**: Failure suppression and false-positive verification **Risk Level**: Medium ```bash echo "[INFO] Memory slot binding" openclaw config get plugins.slots.memory || true echo "[INFO] Skills readiness" openclaw skills check || true echo "[PASS] Verification completed." ``` ### Technical Analysis The script suppresses nonzero exit statuses from the memory-slot and skill-readiness checks by appending `|| true`. Because the script uses `set -e`, these expressions specifically override the intended fail-fast behavior. The memory-slot command also only retrieves the configured value; it does not verify that the value equals `evermemory`. The script then unconditionally prints a success message even if the slot query or skill-readiness check failed. Consequently, callers cannot rely on a successful exit status or the `[PASS]` message as evidence that all documented installation requirements were met. ### Attack Path 1. A faulty, incomplete, or tampered installation leaves `plugins.slots.memory` unset or bound to a different plugin. 2. Alternatively, the installed skill fails the `openclaw skills check` readiness validation. 3. An operator or deployment pipeline invokes `scripts/verify_install.sh`. 4. The relevant command returns a nonzero status. 5. `|| true` converts that failure into a successful shell expression. 6. The script continues and prints `[PASS] Verification completed.` 7. Downstream automation or an operator accepts the installation despite its invalid state. ### Impact Assessment This issue does not directly grant additional operating-system privileges. Its impact is on deployment integrity and assurance: an unbound memory slot, unavailable skill, or otherwise incomplete installation can be falsely approved for use. This may cause incorrect runtime behavior, loss of expected memory functionalit ...[truncated 66 chars]
• Remediation: ## Remediation Suggestions 1. Remove `|| true` from every mandatory verification command so failures propagate through `set -e`. 2. Capture and validate the memory-slot value explicitly rather than checking only whether it can be retrieved: ```bash memory_slot="$(openclaw config get plugins.slots.memory)" if [[ "$memory_slot" != "evermemory" ]]; then echo "[ERROR] Expected memory slot 'evermemory', found: $memory_slot" >&2 exit 1 fi ``` 3. Require `openclaw skills check` to return successfully: ```bash openclaw skills check ``` 4. Print the final `[PASS]` message only after every mandatory check has succeeded. 5. Add automated tests covering an unset slot, an incorrectly bound slot, and a failed skill-readiness check. Each case should produce a nonzero script exit status.

T09 · Insecure Skill Coding Practices

Warning

• Location: scripts/publish_skill.sh:64
• Finding: Skill publication bypasses documented mandatory release gates## Vulnerability Details **File Location**: `scripts/publish_skill.sh`, lines 64–75 **Vulnerability Type**: Missing pre-publication security and quality validation **Risk Level**: Medium ```bash echo "[INFO] Checking ClawHub login" if ! clawhub whoami >/dev/null 2>&1; then echo "[ERROR] Not logged in to ClawHub. Run: clawhub login" >&2 exit 1 fi echo "[INFO] Publishing skill from: $SKILL_DIR" clawhub publish "$SKILL_DIR" \ --slug "$SLUG" \ --name "$NAME" \ --version "$VERSION" \ --changelog "$CHANGELOG" \ --tags "$TAGS" ``` ### Technical Analysis The publication script verifies only that the caller is authenticated to ClawHub before invoking `clawhub publish`. It does not execute the mandatory release and benchmark checks described elsewhere in the project. `SKILL.md` states that publication must not proceed when `teams:release` fails. The playbook also identifies `npm run teams:dev`, `npm run teams:release`, and `npm run test:recall:benchmark` as mandatory quality gates, with a benchmark hard gate of at least 0.90. Because those checks are not enforced in the script immediately before publication, invoking the script directly bypasses the documented release policy. Authentication confirms the caller's identity but does not establish that the content is safe, functional, or release-ready. ### Attack Path 1. Skill content is modified in a way that causes a release gate or recall benchmark to fail, or the required tests are never executed. 2. A contributor or automation process with valid ClawHub publishing credentials invokes `scripts/publish_skill.sh`. 3. The script checks only `clawhub whoami`, which succeeds. 4. No release gate or benchmark validates the pending content. 5. `clawhub publish` uploads the unchecked skill. 6. Consumers can install a release that would have been rejected by the project's documented mandatory checks. This path requires access to modify the release cont ...[truncated 644 chars]
• Remediation: ## Remediation Suggestions 1. Execute all mandatory release gates in `publish_skill.sh` immediately before `clawhub publish`: ```bash cd "$ROOT_DIR" npm run teams:dev npm run teams:release npm run test:recall:benchmark ``` 2. Ensure the benchmark command exits nonzero when the score is below the documented hard threshold of 0.90. If it does not, parse and validate a machine-readable benchmark result explicitly. 3. Retain `set -euo pipefail` so any failed gate aborts publication. 4. Perform validation after selecting the exact content to publish, preventing changes between validation and publication. 5. Enforce the same checks in CI and protect the publication job so it runs only from an approved commit or immutable release artifact. 6. Emit a clear success message only after both validation and publication complete successfully, and preserve gate and publication logs for release auditing.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (2)

Autonomous Decision Making

Medium

• Category: Excessive Agency

Content

## Safety Rules

1. Never publish when `teams:release` fails.
2. Never force-enable plugin without checking `openclaw gateway status`.
3. Never claim publish succeeded without capturing command output and artifact path.
4. Prefer `--dry-run` first for npm publish.

• Confidence: 75% confidence
• Finding: Skill enables autonomous high-impact decisions without human-in-the-loop verification. Critical operations (destructive commands, financial transactions, data deletion) should require explicit user confirmation.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The playbook instructs users to run `npm publish --access public --tag latest` without explicitly warning that this will publish the package to the public npm registry. In an install/publish skill, omission of that warning increases the chance of accidental public release of proprietary or unreviewed code, which can lead to source exposure, credential misuse via bundled files, and unintended downstream consumption.

Static analysis

No suspicious patterns detected.