T08 · Insecure Dependencies
- Location
SKILL.md:47- Finding
Unreviewed Third-Party Plugin Receives Credential-Backed Apify Access
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 47–49 and 71–77
Vulnerability Type: Insecure third-party dependency and credential intermediary
Risk Level: MediumVulnerable Code Snippets:
bash openclaw plugins install clawhub:clawlink-plugin openclaw config set tools.alsoAllow '["clawlink-plugin"]' --strict-json openclaw gateway restartmarkdown **No API key is required in chat.** ClawLink stores the API key securely and injects it into every Apify API request on the user's behalf. ### Getting Connected 1. Install the ClawLink plugin (see Install above). 2. Pair the plugin with `clawlink_begin_pairing` if it is not configured yet. 3. Open https://claw-link.dev/dashboard?add=apify and connect Apify.Technical Analysis
The Skill directs the user to install and explicitly allowlist an external plugin, restart the OpenClaw gateway to activate it, and connect an Apify credential through the third-party ClawLink service. The audited project contains no plugin source code, immutable version pin, integrity checksum, cryptographic signature, permission manifest, or update policy. Consequently, the behavior of the component receiving tool access and handling the credential cannot be verified from the reviewed artifact.
The plugin and hosted service form a supply-chain and trust-boundary dependency. ClawLink stores the user's Apify API key and injects it into requests, so compromise or malicious replacement of either component could expose all capabilities granted to that credential. Although the Skill requires confirmation for write operations, the reviewed file does not establish that these controls are enforced independently of the third-party component.
Attack Path
- An attacker compromises the plugin distribution channel, a future unpinned plugin release, or the hosted ClawLink service.
- The user follows the Skill instructions and installs the externally supplied ...[truncated 1247 chars]
- Remediation
View remediation
Remediation Suggestions
- Pin the plugin to a reviewed, immutable version rather than installing an unspecified current release.
- Publish or reference the exact plugin source corresponding to that version and provide cryptographic checksums or signed release metadata.
- Document the plugin's complete permission manifest, network destinations, credential-access behavior, update mechanism, and security review status.
- Prefer direct Apify authentication where practical. If credential brokerage is required, use narrowly scoped, independently revocable tokens instead of broadly privileged account credentials.
- Apply least privilege by limiting the credential to only the Apify resources and operations required for the user's workflow.
- Document credential encryption, retention, rotation, revocation, audit logging, incident response, and permanent deletion procedures for the hosted service.
- Enforce write and destructive-operation confirmation in a trusted layer outside plugin-controlled metadata or behavior.
- Provide users with a clear preview of requested permissions and third-party credential custody before installation and account connection.
- Monitor and log authenticated operations, alert on destructive actions or unusual compute consumption, and provide an immediate mechanism to revoke the integration.
