ClawHub
Back to skill

Security audit

滴答清单

Security checks for vulnerabilities and agentic risk

Overview

This skill is mostly coherent for managing Dida tasks, but it needs review because it tells users to install an unpinned global CLI and offers a plaintext command-line token login path without adequate warnings.

Review this skill before installing. Prefer the browser OAuth login flow, avoid pasting API tokens into chat or shell commands, and only use a direct token path if you can keep it out of history and logs. If installing the CLI, consider pinning a reviewed version and using an isolated or local install rather than a mutable global npm install.

A.I.G

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)

T08 · Insecure Dependencies

Warning
Location
SKILL.md:45
Finding

Unpinned Third-Party CLI Installed Globally

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 45-59
Vulnerability Type: Supply-chain exposure through an unpinned global npm dependency
Risk Level: Medium

Vulnerable Code

bash
# Check whether the CLI exists
dida --version

# Install globally if it is unavailable
npm install -g @suibiji/dida-cli

# Verify installation
dida --help
dida --version

Technical Analysis

The Skill directs the agent to install @suibiji/dida-cli globally without pinning an audited version or verifying package integrity. The project provides no checksum, lockfile, provenance requirement, or other mechanism for ensuring that the package retrieved at execution time is the version previously reviewed.

An npm package can execute package-controlled lifecycle scripts during installation. Global installation also makes its executable available broadly in the user's environment. Consequently, compromise of the package publisher, npm account, release process, or package contents could turn the documented installation step into user-level arbitrary code execution.

Installing a CLI is relevant to the declared task-management functionality, but global installation of a mutable, unverified release exceeds the minimum access necessary. A locally scoped, version-pinned, integrity-verified installation would reduce exposure.

Attack Path

  1. An attacker compromises the npm publisher account, package release process, or another component of the package supply chain.
  2. The attacker publishes a malicious release under @suibiji/dida-cli.
  3. The agent finds that dida is unavailable and follows the Skill instruction to execute npm install -g @suibiji/dida-cli.
  4. npm retrieves the current attacker-controlled release and may execute its lifecycle scripts.
  5. The malicious package runs with the privileges of the user performing the installation.
  6. It can access data available to that user, including local fil ...[truncated 546 chars]
Remediation
View remediation

Remediation Suggestions

  1. Verify that the package and npm scope are controlled by the expected, trusted service publisher.
  2. Pin an exact audited package version rather than installing the mutable latest release:
    bash
    npm install --global --ignore-scripts @suibiji/dida-cli@<audited-version>
  3. Record and verify package integrity and provenance through an approved lockfile, registry policy, signature, or checksum mechanism.
  4. Prefer a local, isolated installation over a global installation, and invoke it through a controlled path.
  5. Disable npm lifecycle scripts where the verified package does not require them.
  6. Review each package update before changing the pinned version.
  7. Run the CLI under an unprivileged account with access only to the files and credentials necessary for Dida operations.

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:84
Finding

Access Token Exposed Through a Command-Line Argument

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 84-90
Vulnerability Type: Sensitive credential exposure through command-line handling
Risk Level: Medium

Vulnerable Code

bash
# API token: Get your API token from Settings > Account > API Keys
dida auth token <token>   # set access token directly (for headless environments)

Technical Analysis

The documented headless authentication method requires the user to place an API token directly in the command line. After substitution, the plaintext token may be retained in shell history, terminal transcripts, automation logs, audit records, or process metadata. Other local users or monitoring processes may also be able to inspect command-line arguments while the command is running, depending on the operating system and process isolation settings.

An API token is a bearer credential. An attacker who obtains it may authenticate without knowing the user's password or completing the browser-based OAuth flow. The Skill does not instruct the agent to use hidden input, standard input, a protected credential file, an environment-specific secret mechanism, or history suppression.

Network transmission of authentication material to Dida is necessary for the declared functionality. Exposing that material through a process argument and shell history is not necessary and exceeds minimum-risk credential handling.

Attack Path

  1. The user replaces <token> with a valid Dida API token and runs the documented command.
  2. The shell records the complete command in its history, or an automation/terminal logging system captures it.
  3. Alternatively, a local observer inspects process command-line arguments while the command is active.
  4. An attacker with access to the resulting history, logs, or process metadata retrieves the bearer token.
  5. The attacker submits the token to the Dida service through a compatible client.
  6. The attacker reads ...[truncated 451 chars]
Remediation
View remediation

Remediation Suggestions

  1. Replace command-line token input with a hidden interactive prompt that does not echo or retain the credential.
  2. For headless use, accept the token through protected standard input or an operating-system credential store rather than a process argument.
  3. If a credential file is unavoidable, require restrictive permissions, validate ownership, avoid shared temporary directories, and securely remove the file after use.
  4. Explicitly warn users not to place secrets directly in shell commands, scripts, issue reports, or logs.
  5. Ensure application output and error handling redact access tokens.
  6. Document immediate token revocation and rotation procedures for suspected exposure.
  7. Prefer narrowly scoped, short-lived credentials where the service supports them.

SkillSpector

Vulnerability Patterns
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (3)

Natural-Language Policy Violations

High
Category
Not specified by scanner
Confidence
96% confidence
Finding

The description states the skill manages tasks and projects in 滴答清单, which is a specific non-user-selectable locale/product naming choice, but the file does not offer any language or locale choice or explain that this locale constraint is required. Under the policy, forcing a specific language/locale without opt-in should be flagged.

Content

No source excerpt is available for this finding.

Credential Access

High
Category
Privilege Escalation
Confidence
95% confidence
Finding

The documented dida auth token <token> flow involves handling an access token directly, which creates a credential exposure risk. If an agent captures or repeats the token, it could enable unauthorized access to the user's Dida account, and the risk is amplified because command-line arguments are often observable in logs, histories, and process inspection.

Content

Scanner excerpt · SKILL.md (reported line 88)May include surrounding context.

Alternative methods

API token: Get your API token from Settings > Account > API Keys:

bash
dida auth token <token>   # set access token directly (for headless environments)
  1. Confirm login status:

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
93% confidence
Finding

The skill explicitly instructs the agent/user to supply an API token directly on the command line, but it provides no warning that tokens are sensitive secrets that may be exposed through shell history, process lists, logs, transcripts, or agent telemetry. In an agent setting, this is especially risky because the model may echo, store, or mishandle the token while following the documented flow.

Content

No source excerpt is available for this finding.

Static analysis

No suspicious patterns detected.