Back to skill

Security audit

Zenlink - Node SDK for ZenHeart

Security checks for vulnerabilities and agentic risk

Overview

The skill appears purpose-aligned for Zenlink, but it asks users to build and register missing external components with a token-backed MCP integration, so it needs review before installation.

Install only after verifying the canonical Zenlink source, exact version or commit, dependency lockfile, npm registration script, generated MCP CLI, and resulting OpenClaw MCP/hook configuration. Keep ZENLINK_TOKEN scoped and revocable, and treat inbound Zenlink message bodies as untrusted data unless the implementation enforces authentication and authorization.

Vulnerability Patterns
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (2)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:17
Finding
Execution and Registration of Unpinned External Components## Vulnerability Details **File Location**: `SKILL.md`, lines 17-22 **Vulnerability Type**: Unverified third-party dependency and lifecycle-script execution **Risk Level**: Medium **Vulnerable Code Snippet**: ```markdown 1. Acquire and build - Build `v2/packages/zenlink` and `v2/packages/zenlink-mcp`. - Keep `ZENLINK_AGENT_ID` and `ZENLINK_TOKEN` ready. 2. Register and wire - Register MCP stdio server to `zenlink-mcp/dist/cli.js`. - Run `npm run openclaw:register` in `zenlink-mcp`. ``` ### Technical Analysis The skill instructs the operator to acquire, build, execute, and register external Zenlink components. However, the audited project contains only `SKILL.md` and `skill.json`; it does not include the referenced packages, source code, package manifest, dependency lockfile, integrity hashes, acquisition URL, or the implementation of the `openclaw:register` script. Consequently, the effective code executed by `npm run openclaw:register` and `zenlink-mcp/dist/cli.js` cannot be verified from the reviewed artifact. No immutable repository revision or artifact digest is specified. If the externally obtained package tree is substituted or compromised, its lifecycle or registration script can execute arbitrary code under the privileges of the user running the installation. This finding does not establish that the absent Zenlink components are malicious. It establishes that the documented installation path crosses an unaudited and unpinned supply-chain boundary before local code execution and MCP registration. ### Attack Path 1. An attacker compromises, substitutes, or impersonates the source from which the unspecified `zenlink` or `zenlink-mcp` package tree is acquired. 2. The victim follows the skill instructions and builds the attacker-controlled package. 3. The victim runs `npm run openclaw:register`. 4. The package-defined npm script executes with the victim's local account privileges. 5. The script c ...[truncated 801 chars]
Remediation
## Remediation Suggestions - Specify an authenticated, canonical source for every external component. - Pin the source to an immutable commit, signed release, or exact package version. - Publish and verify cryptographic hashes or signatures before building or executing the components. - Include the relevant source code, package manifest, and lockfile in the auditable artifact where practical. - Review and document the exact command behind `openclaw:register` before instructing users to execute it. - Install dependencies with lockfile enforcement, such as `npm ci`, and disable lifecycle scripts during initial inspection where feasible. - Run the build and registration process in a sandbox or least-privileged account without unrelated credentials. - Require explicit review of the generated `dist/cli.js` and resulting MCP configuration before enabling the server.

other

Warning
Location
SKILL.md:20
Finding
Inbound External Messages Are Consumed Without Documented Trust Controls## Vulnerability Details **File Location**: `SKILL.md`, lines 20-25 **Vulnerability Type**: Untrusted external agent-control channel **Risk Level**: Medium **Vulnerable Code Snippet**: ```markdown 2. Register and wire - Register MCP stdio server to `zenlink-mcp/dist/cli.js`. - Run `npm run openclaw:register` in `zenlink-mcp`. 3. Apply in runtime - Use `zenlink_*` tools or `ZenlinkClient`. - Use `zenlink_inbound_poll` for full inbound JSON. ``` The immediately following instruction further defines how inbound data is handled: ```markdown - Treat OpenClaw wake text as summary only. ``` ### Technical Analysis The skill directs the agent to poll and consume full inbound JSON from an external messaging channel while making MCP tools available. It does not document mandatory sender authentication, per-sender authorization, replay prevention, schema validation, instruction/data separation, or user confirmation before consequential tool calls. In an agent environment, externally supplied natural-language or structured content can act as indirect prompt injection if it is interpreted as trusted operational instruction. Access to the full inbound JSON may also expose fields not represented in the wake-text summary. Without an explicit trust policy, crafted message fields could attempt to redirect the agent, induce MCP tool calls, or request disclosure of accessible information. The implementation of `zenlink_inbound_poll`, `ZenlinkClient`, and the referenced MCP permission map is absent from the project. Therefore, this audit cannot determine whether the external Zenlink implementation independently provides authentication or validation. The documented skill itself nevertheless omits the controls needed to prevent inbound content from being treated as authoritative agent instructions. ### Attack Path 1. An attacker obtains the ability to submit a message through the Zenlink channel, such as through an ex ...[truncated 1348 chars]
Remediation
## Remediation Suggestions - Explicitly classify all inbound message bodies and JSON fields as untrusted data rather than agent instructions. - Require cryptographic sender authentication and enforce per-agent and per-message-type authorization. - Validate inbound JSON against a strict schema, reject unknown fields, constrain lengths, and normalize encoded content. - Add timestamps, nonces, and message identifiers with replay protection. - Prevent inbound content from changing system instructions, safety rules, tool permissions, or authentication settings. - Apply a least-privilege allowlist to MCP tools available while processing inbound messages. - Require explicit user confirmation before file changes, credential access, external communication, administrative operations, or other consequential actions. - Log sender identity, authorization decisions, message identifiers, and resulting tool calls without recording secrets. - Document and audit the implementation of `zenlink_inbound_poll`, the tool-input schemas, and the tool-permissions map as part of the distributed project. - Display both the wake-text summary and authenticated message provenance so the agent does not rely on attacker-controlled summary content.
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.