Back to skill

Security audit

MuHaven RWA Portfolio (rehearsal)

Security checks for vulnerabilities and agentic risk

Overview

The skill is coherent for a MuHaven portfolio agent, but its financial authority is paired with installation and runtime documentation that weakens or overstates its security boundaries.

Install only if you are comfortable with MuHaven, its broker, and the host OpenClaw runtime having user-level execution exposure in the documented host_native setup. Prefer exact pinned runtime and CLI versions, an isolated OS account or container, and read-only mode unless you intend to stage buy, claim, or pause actions.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (2)

T09 · Insecure Skill Coding Practices

Error
Location
manifest.json:76
Finding
Security Controls Are Advisory Under the Documented Host-Native Runtime<![CDATA[ ## Vulnerability Details **File Location**: `manifest.json:76-81` **Additional Locations**: `SKILL.md:157-164`, `dist/index.cjs:55-57` **Vulnerability Type**: Security sandbox fail-open configuration **Risk Level**: High ### Complete Code Snippets From `manifest.json:76-81`: ```json "sandbox": { "runtime": "nemoclaw", "fallback": "host_native", "$comment_forward_compat": "Per OpenClaw issues #28298 (permissions schema) and #28360 (sandbox boot ABI). When the runtime doesn't recognize a field, it MUST treat unknown permissions as deny — not allow. Verified on NemoClaw 0.5.0 release notes.", "$comment_runtime_decision": "Operator runtime decision 2026-05-11 (c8aba6d) shifted §3 Path (a) A.4 from NemoClaw to plain OpenClaw via `npm install -g openclaw@latest`. The `runtime: nemoclaw` field above stays as the preferred runtime claim; `fallback: host_native` is what actually runs today. Sandbox + permissions become advisory in host_native mode. Promote to NemoClaw once the homelab is willing to host the NVIDIA OpenShell + GPU stack." }, ``` From `SKILL.md:157-164`: ```markdown 1. Install plain OpenClaw + ClawHub CLI globally: ```bash npm install -g openclaw@latest clawhub openclaw --version # confirm install clawhub --version ``` (Runtime decision 2026-05-11: plain OpenClaw under `sandbox.fallback: host_native`. NemoClaw remains the preferred runtime claim in `manifest.json` for forward-compat; today's deploy targets plain OpenClaw.) ``` From `dist/index.cjs:55-57`: ```js async function runOpenClawSkill() { process.env.MUHAVEN_OPENCLAW_SKILL_VERSION = resolveSkillVersion(); await mcp.runMcpStdioCli({ filterRegistry: selectOpenClawSubsetRegistry }); } ``` ### Technical Analysis The manifest declares deny-by-default network access, no filesystem access, and no process spawning. However, the documented and currently selected deployment falls back to `host_native`, where the project explicitly acknowledges t ...[truncated 2507 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Remove the production `host_native` fallback and fail closed when the required sandbox cannot be initialized. 2. Require a runtime that demonstrably enforces the manifest's network, filesystem, process, IPC, and telemetry restrictions before activating the skill. 3. Add a startup capability check that verifies enforcement and terminates if the runtime reports advisory-only permissions. 4. Do not describe the bin shim as providing deny-default behavior unless such controls are actually implemented and tested there. 5. Run the skill under a dedicated, unprivileged operating-system account with no access to unrelated user files. 6. Apply operating-system-level containment independently of OpenClaw, such as a container, seccomp profile, AppArmor/SELinux policy, restricted filesystem namespace, and enforceable outbound firewall rules. 7. Restrict broker IPC permissions to the dedicated runtime identity and authenticate every broker request. 8. Add integration tests that attempt prohibited filesystem reads, writes, process execution, and off-allowlist network requests. Release should fail unless every operation is blocked. 9. Clearly distinguish enforceable controls from advisory metadata in all installation and security documentation. ]]>

T08 · Insecure Dependencies

Warning
Location
SKILL.md:155
Finding
Installation Instructions Execute Mutable and Unpinned Global Packages<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:155-169` **Vulnerability Type**: Unsafe dependency installation and supply-chain exposure **Risk Level**: Medium ### Complete Code Snippet From `SKILL.md:155-169`: ```markdown ## How to install 1. Install plain OpenClaw + ClawHub CLI globally: ```bash npm install -g openclaw@latest clawhub openclaw --version # confirm install clawhub --version ``` (Runtime decision 2026-05-11: plain OpenClaw under `sandbox.fallback: host_native`. NemoClaw remains the preferred runtime claim in `manifest.json` for forward-compat; today's deploy targets plain OpenClaw.) 2. Install the broker daemon **separately as a global** so its bin lands on `$PATH` regardless of ClawHub's bin-handling: ```bash npm install -g @muhaven/mcp@0.1.2 ``` ### Technical Analysis The instructions install `openclaw@latest` and an unversioned `clawhub` package globally. Both specifications resolve through mutable registry state at installation time. An unversioned npm package normally resolves to its current default distribution tag, while `@latest` explicitly selects the mutable `latest` tag. Because these packages expose command-line executables and are installed globally, a compromised publisher account, malicious package release, registry incident, or unexpected breaking release can introduce code that executes outside the reviewed skill artifact. npm lifecycle scripts may also execute during installation unless separately disabled. The broker package is pinned to `@muhaven/mcp@0.1.2`, which is better than using a mutable tag. However, its implementation and transitive dependency graph were not included in the audited artifact, so its security-sensitive behavior could not be independently verified in this review. ### Attack Path 1. An attacker compromises the npm publisher account, release workflow, or package distribution channel for `openclaw` or `clawhub`. 2. The attacker publishes a ma ...[truncated 1601 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Replace `openclaw@latest` and unversioned `clawhub` with exact, tested versions. 2. Publish SHA-512 integrity values or a signed lock manifest for every installed package and verify them before execution. 3. Use Sigstore or equivalent provenance verification for the runtime, CLI, broker, and skill artifacts. 4. Prefer a signed, reproducible installation bundle over independent mutable global package installations. 5. Disable npm lifecycle scripts during installation where compatible, then explicitly run only audited setup steps. 6. Avoid administrative installation. Use an isolated package prefix, dedicated account, container, or package manager environment. 7. Pin and audit transitive dependencies of the externally supplied `@muhaven/mcp` broker package. 8. Add automated release checks that verify package name, exact version, publisher identity, provenance, integrity, and expected executable hashes. 9. Document a controlled upgrade process instead of instructing users to consume the newest release automatically. ]]>
Vulnerability Patterns
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • MCP Tool PoisoningHidden Instructions, Unicode Deception, Parameter Description Injection
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Findings (12)

Credential Access

High
Category
Privilege Escalation
Content
"stdio": "manifest_only"
    },
    "secrets": {
      "storage": "os_keychain",
      "deny_paste_ui": true,
      "references": [
        {
Confidence
70% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High
Category
Privilege Escalation
Content
"stdio": "manifest_only"
    },
    "secrets": {
      "storage": "os_keychain",
      "deny_paste_ui": true,
      "references": [
        {
Confidence
70% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Credential Access

High
Category
Privilege Escalation
Content
"stdio": "manifest_only"
    },
    "secrets": {
      "storage": "os_keychain",
      "deny_paste_ui": true,
      "references": [
        {
Confidence
70% confidence
Finding
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.

Intent-Code Divergence

Medium
Confidence
89% confidence
Finding
The documentation creates a misleading trust boundary by stating the skill 'only talks to the broker over Unix-socket / named-pipe IPC' while the manifest explicitly permits direct egress to https://api.muhaven.app and https://muhaven.app. Users or reviewers may rely on the docs to assume all sensitive flows are broker-mediated, when in reality the skill can directly communicate with remote MuHaven infrastructure, increasing the risk of unnoticed data transmission or architectural misunderstandings.

Unpinned Dependencies

Low
Category
Supply Chain
Content
"@muhaven/mcp": "0.1.2"
  },
  "devDependencies": {
    "@types/node": "^22.0.0",
    "rimraf": "^5.0.0",
    "tsup": "^8.5.1",
    "tsx": "^4.21.0",
Confidence
40% confidence
Finding
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.

Unpinned Dependencies

Low
Category
Supply Chain
Content
},
  "devDependencies": {
    "@types/node": "^22.0.0",
    "rimraf": "^5.0.0",
    "tsup": "^8.5.1",
    "tsx": "^4.21.0",
    "typescript": "^5.7.0",
Confidence
40% confidence
Finding
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.

Unpinned Dependencies

Low
Category
Supply Chain
Content
"devDependencies": {
    "@types/node": "^22.0.0",
    "rimraf": "^5.0.0",
    "tsup": "^8.5.1",
    "tsx": "^4.21.0",
    "typescript": "^5.7.0",
    "vitest": "^3.0.0"
Confidence
87% confidence
Finding
The unpinned tsup devDependency increases supply-chain risk because future installs may resolve to different releases, and this package family has at least one known advisory in some versions. While tsup is a build-time tool rather than a runtime dependency, compromised or vulnerable build tooling can still affect produced artifacts or developer environments.

Unverifiable Dependency: tsup has 1 known advisory(ies) (CVE-2024-53384 (tsup DOM Clobbering vulnerability)), but the manifest does not pin a version, so it is unknown whether the installed release is affected

Low
Category
Supply Chain
Confidence
90% confidence
Finding
This is a true supply-chain vulnerability risk because the manifest does not pin tsup, so installs may resolve to a version affected by a known advisory without the repository clearly documenting which version is actually used. Since tsup is build tooling, the primary exposure is to developers/CI and potentially to integrity of generated artifacts, not directly to end users at runtime.

Unpinned Dependencies

Low
Category
Supply Chain
Content
"@types/node": "^22.0.0",
    "rimraf": "^5.0.0",
    "tsup": "^8.5.1",
    "tsx": "^4.21.0",
    "typescript": "^5.7.0",
    "vitest": "^3.0.0"
  },
Confidence
40% confidence
Finding
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.

Unpinned Dependencies

Low
Category
Supply Chain
Content
"rimraf": "^5.0.0",
    "tsup": "^8.5.1",
    "tsx": "^4.21.0",
    "typescript": "^5.7.0",
    "vitest": "^3.0.0"
  },
  "engines": {
Confidence
40% confidence
Finding
Dependencies lack version pinning, allowing potential malicious package updates. Consider pinning versions.

Unpinned Dependencies

Low
Category
Supply Chain
Content
"tsup": "^8.5.1",
    "tsx": "^4.21.0",
    "typescript": "^5.7.0",
    "vitest": "^3.0.0"
  },
  "engines": {
    "node": ">=20.0.0"
Confidence
89% confidence
Finding
The unpinned vitest devDependency introduces supply-chain uncertainty, and the package has multiple advisories affecting some versions. Even though vitest is used in testing rather than production runtime, vulnerable test tooling can expose developer or CI environments, especially if UI/server features or mock-related functionality are used.

Unverifiable Dependency: vitest has 3 known advisory(ies) (CVE-2026-47429 (When Vitest UI server is listening, arbitrary file can be read and executed); CVE-2026-84373 (Vitest: Path Traversal / Arbitrary File Read via @vitest/mocker Redirect Mock); CVE-2025-24964 (Vitest allows Remote Code Execution when accessing a malicious website while Vit)), but the manifest does not pin a version, so it is unknown whether the installed release is affected

Low
Category
Supply Chain
Confidence
92% confidence
Finding
This is a true vulnerability risk because vitest is not pinned and has multiple known advisories in some releases, including arbitrary file read and potential code execution scenarios in certain modes. Although vitest is a dev/test dependency, those impacts can materially affect developer workstations or CI runners if vulnerable features are enabled or malicious test content is encountered.

Static analysis

No suspicious patterns detected.