T08 · Insecure Dependencies
- Location
SKILL.md:46- Finding
Unpinned External Plugin Receives OAuth-Backed Intercom Access
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 46-48
Vulnerability Type: Unpinned third-party plugin installation and supply-chain exposure
Risk Level: MediumVulnerable Code
bash openclaw plugins install clawhub:clawlink-plugin openclaw config set tools.alsoAllow '["clawlink-plugin"]' --strict-json openclaw gateway restartRelated trust and credential-flow statements appear at
SKILL.md:32,SKILL.md:70, andSKILL.md:76:text 5. Proxy Requests No API key is required in chat. ClawLink stores the OAuth token securely and injects it into every Intercom API request on the user's behalf. Open https://claw-link.dev/dashboard?add=intercom and connect Intercom (requires an active Intercom workspace).Technical Analysis
The installation command references
clawhub:clawlink-pluginwithout an immutable version, release digest, or other integrity constraint. The subsequent configuration explicitly permits the plugin as an OpenClaw tool and restarts the gateway so that the installed component becomes active.This creates a supply-chain trust boundary that cannot be fully audited from the submitted project. The project contains only
SKILL.md; the plugin implementation and hosted ClawLink service are external. Consequently, the behavior reviewed in this repository does not establish that the component installed in the future will be identical to the component intended by the documentation.The exposure is significant because ClawLink is described as storing the user's OAuth token and injecting it into proxied Intercom requests. The documented tool catalog includes access to customer conversations, contacts, companies, tickets, call transcripts, data exports, help-center content, and destructive operations. Although the Skill requires confirmation for write operations, an altered external plugin or backend may not reliably enforce those instructions.
This finding does not ...[truncated 1867 chars]
- Remediation
View remediation
Remediation Suggestions
- Pin the plugin to a specific immutable release version rather than installing a mutable package name.
- Verify the downloaded artifact using a publisher signature and a documented cryptographic digest before installation.
- Configure installation to fail closed if the signature, version, or digest does not match the reviewed artifact.
- Publish or bundle the plugin source corresponding to the pinned release so its credential handling, network behavior, and confirmation enforcement can be independently audited.
- Document the exact Intercom OAuth scopes requested and remove all scopes not required for the user's selected operations.
- Separate read-only and write-capable authorization profiles where supported, with read-only access as the default.
- Require explicit, independently enforced authorization for destructive or externally visible actions rather than relying solely on natural-language Skill instructions.
- Document token retention, encryption, logging, subprocess access, administrator access, revocation, and incident-response practices for the hosted service.
- Provide clear instructions for revoking the Intercom connection, uninstalling the plugin, and removing it from
tools.alsoAllow. - Use signed releases, protected publisher accounts, reproducible builds, dependency locking, and automated supply-chain scanning throughout the plugin release process.
