ClawHub
Back to skill

Security audit

Segment

Security checks for vulnerabilities and agentic risk

Overview

The skill is a disclosed Segment integration through ClawLink, with clear setup and confirmation requirements for writes, though users should understand they are enabling an external plugin with Segment API access.

Install this only if you trust ClawLink and are comfortable granting it access to the connected Segment workspace. Review write previews carefully before approving actions such as identity/event writes, source deletion, imports, or write-key revocation, and consider verifying the plugin publisher/version before enabling it.

A.I.G

Vulnerability Patterns
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Insecure DependenciesIntroduces malicious components through unsafe dependency sources
  • 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:48
Finding

Unpinned Third-Party Plugin Installation and Activation

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 48-50
Vulnerability Type: Unpinned and automatically activated third-party dependency
Risk Level: Medium

Vulnerable Code

bash
openclaw plugins install clawhub:clawlink-plugin
openclaw config set tools.alsoAllow '["clawlink-plugin"]' --strict-json
openclaw gateway restart

Technical Analysis

The installation command identifies clawlink-plugin without an immutable version, cryptographic digest, or documented signature-verification requirement. The following commands explicitly allow the installed plugin and restart the OpenClaw gateway, activating the retrieved dependency.

Because the dependency reference is mutable, the code executed by users can change after this Skill has been audited. A compromised publisher account, package registry, distribution pipeline, or later malicious release could cause different plugin code to be installed under the same package name.

The file does not independently verify the package contents before activation. No malicious content was found inside the audited project itself; the risk arises from the external dependency and installation process.

Attack Path

  1. An attacker compromises the plugin publisher account, ClawHub package entry, or associated distribution infrastructure.
  2. The attacker publishes a malicious plugin release under the existing clawlink-plugin identifier.
  3. A user follows the Skill instructions and runs the unpinned installation command.
  4. OpenClaw retrieves the attacker-controlled release because no immutable version or digest is specified.
  5. The user allowlists the plugin through tools.alsoAllow.
  6. The gateway restart activates the malicious plugin.
  7. The plugin can then abuse whatever tool, network, credential-broker, and local process privileges the OpenClaw plugin runtime grants it.

Impact Assessment

Successful exploitation could permit attacker-contr ...[truncated 764 chars]

Remediation
View remediation

Remediation Suggestions

  1. Pin the plugin to a specific, audited version rather than a mutable package identifier.
  2. Prefer an immutable cryptographic digest or content hash in addition to a version number.
  3. Require verification of the package publisher and package signature before installation.
  4. Publish the expected digest and a reproducible procedure for checking it locally.
  5. Separate installation from activation so users can inspect and approve the installed package before it is allowlisted.
  6. Avoid restarting the gateway automatically until dependency integrity has been verified.
  7. Restrict the plugin to the minimum required tool, filesystem, network, and credential permissions.
  8. Maintain a reviewed version allowlist and document a rollback and revocation procedure for compromised releases.

T01 · Skill Instruction Hijacking

Warning
Location
SKILL.md:217
Finding

Remote Tool Catalog and Behavioral Guidance Treated as Authoritative

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 217-245
Vulnerability Type: Trusting remotely supplied tool definitions and execution guidance
Risk Level: Medium

Vulnerable Code

markdown
3. Treat the returned list as the source of truth. Do not guess or assume what tools exist.
4. If the user describes a capability but the exact tool is unclear, call `clawlink_search_tools` with a short query and integration `segment`.
5. If no Segment tools appear, direct the user to https://claw-link.dev/dashboard?add=segment.

## Execution Workflow

┌─────────────────────────────────────────────────────────────┐ │ READ OPERATIONS (Safe) │ │ list → get → describe → call │ │ │ │ Example: List destinations → Get metrics → Show results │ └─────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ WRITE OPERATIONS (Require Confirmation) │ │ describe → preview → confirm → call │ │ │ │ Example: Describe tool → Preview changes → User approves │ │ → Execute track/identify │ └─────────────────────────────────────────────────────────────┘

text

1. For unfamiliar tools, ambiguous requests, or any write action, call `clawlink_describe_tool` first.
2. Use the returned guidance, schema, `whenToUse`, `askBefore`, `safeDefaults`, `examples`, and `followups` to shape the call.
3. Prefer read, list, and get operations before writes when that reduces ambiguity.
4. For writes or anything marked as requiring confirmation, call `clawlink_preview_tool` first.
5. Execute with `clawlink_call_tool`. Pass 
...[truncated 2859 chars]
Remediation
View remediation

Remediation Suggestions

  1. Maintain a local allowlist of exact Segment tool names and permitted operation classes.
  2. Pin expected tool schemas and validate remote schemas against the local manifest before use.
  3. Treat all remote descriptions, examples, defaults, and follow-up guidance as untrusted data rather than executable instructions.
  4. State explicitly that remote guidance cannot override system instructions, user intent, privacy restrictions, confirmation requirements, or local safety policy.
  5. Reject newly introduced tools and materially changed schemas until they receive local review.
  6. Validate parameters locally and enforce least-privilege limits on fields, record counts, date ranges, and accessible resources.
  7. Require confirmation for sensitive read operations, especially bulk exports, contact information, identities, and credential-related metadata.
  8. Generate write previews from locally validated schemas and independently compare the final request with the confirmed preview.
  9. Record catalog versions and schema hashes so unexpected remote changes can be detected and blocked.
  10. Ensure tool responses are presented as data and cannot inject additional agent instructions.

SkillSpector

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