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

Content

View full analysis

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

View 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

Content

View full analysis

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

View 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
• 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.

Content

Scanner excerpt · SKILL.md (reported line 103)May include surrounding context.

md

## 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.

Missing User Warnings

Medium

• Category: Not specified by scanner
• 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.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.