Ticktick CLI (Full Edition)

• Outcome: Review
• Latest audit: Sep 10, 2026 · 5:36 PM UTC
• Version: 1.0.3

Overview

The skill is mostly aligned with controlling TickTick through its CLI, but it needs Review because it handles sensitive TickTick credentials and full-account data without enough safeguards.

Review before installing. Use this only if you are comfortable giving the TickTick CLI account-level access. Do not paste access tokens, passwords, client secrets, auth codes, or raw sync output into chat; store secrets in a local secret store or a tightly protected .env file, keep it out of git, and prefer pinned/verified package installation where possible.

A.I.G

Vulnerability Patterns

• Insecure Dependencies: Introduces malicious components through unsafe dependency sources
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions
• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review

Findings (2)

T08 · Insecure Dependencies

Warning

• Location: references/setup-and-auth.md:40
• Finding: Unpinned Third-Party Package Installation## Vulnerability Details **File Location**: `references/setup-and-auth.md:40-48` **Vulnerability Type**: Unpinned dependency installation from a mutable package repository **Risk Level**: Medium ### Vulnerable Code ```markdown ## Install Recovery (if CLI missing) - Ask for explicit user permission before install/environment changes. - Prefer isolated install: - Existing virtualenv if active - Otherwise local `.venv`: - `python3 -m venv .venv` - `.venv/bin/python -m pip install --upgrade pip` - `.venv/bin/python -m pip install --upgrade ticktick-cli` ``` ### Technical Analysis The recovery procedure installs the latest available release of `ticktick-cli` and upgrades `pip` without specifying reviewed versions or package integrity hashes. Although installation occurs in an isolated virtual environment and requires user permission, isolation does not protect the invoking user's data from code executed by a malicious package. Python packages can execute installation or runtime code with the privileges of the user running `pip` or invoking the installed CLI. Because the selected artifacts can change after this Skill has been reviewed, compromise of the package, its dependencies, or the package distribution account could introduce unreviewed executable code. This is a supply-chain weakness rather than evidence that the named package is currently malicious. ### Attack Path 1. The `ticktick` executable is unavailable and the original command fails. 2. The Skill enters its documented installation recovery procedure. 3. The user approves the environment change. 4. The Agent runs an unpinned `pip install --upgrade ticktick-cli`. 5. A compromised or unexpectedly modified current package release is downloaded and installed. 6. Malicious package code executes during installation or when the CLI is subsequently invoked. 7. The code runs under the invoking user's account and may access TickTick credent ...[truncated 757 chars]
• Remediation: ## Remediation Suggestions 1. Pin `ticktick-cli` and all transitive dependencies to versions that have been reviewed and tested. 2. Use a locked requirements file containing cryptographic hashes, for example with `pip install --require-hashes -r requirements.txt`. 3. Avoid automatically upgrading `pip`; use a separately reviewed and pinned installer version where an upgrade is necessary. 4. Obtain packages only from an explicitly configured trusted index. 5. Consider distributing a verified artifact or using a reproducible installation process. 6. Retain the existing requirements for explicit user approval and virtual-environment isolation. 7. Document how users can inspect the exact package version and artifact hashes before approving installation.

T09 · Insecure Skill Coding Practices

Warning

• Location: references/setup-and-auth.md:17
• Finding: Plaintext TickTick Credential and Access-Token Handling## Vulnerability Details **File Location**: `references/setup-and-auth.md:17-25` **Additional Locations**: `references/setup-and-auth.md:28-35,50-54`; `references/troubleshooting.md:31-37,50-52` **Vulnerability Type**: Plaintext storage and insecure transfer of sensitive authentication material **Risk Level**: Medium ### Vulnerable Code ```dotenv ## Required `.env` TICKTICK_CLIENT_ID= TICKTICK_CLIENT_SECRET= TICKTICK_REDIRECT_URI=http://127.0.0.1:8080/callback TICKTICK_ACCESS_TOKEN= TICKTICK_USERNAME= TICKTICK_PASSWORD= ``` The associated authentication workflow states: ```markdown ## Happy Path 1. Ensure CLI is available. 2. Fill `.env` with all required values except `TICKTICK_ACCESS_TOKEN`. 3. Run OAuth: - Desktop: `ticktick auth` - Headless/SSH: `ticktick auth --manual` 4. Save returned token to `TICKTICK_ACCESS_TOKEN`. 5. Verify: - `ticktick projects list --json` - `ticktick tasks today --json` ``` The manual recovery procedure also states: ```markdown ## Manual OAuth Reliability - Start manual auth only when user is ready to approve immediately. - Paste the auth `code` right away; codes can expire quickly. - If interactive prompt cannot be kept stable, have user run `ticktick auth --manual` themselves and provide the resulting access token. ``` ### Technical Analysis The documented workflow places an OAuth client secret, access token, username, and password together in a plaintext `.env` file. It does not require restrictive file permissions, exclusion from version control, encryption at rest, or a dedicated credential store. The fallback recommendation to have the user “provide the resulting access token” may also cause a bearer token to be entered into an Agent conversation. Such a token can consequently be retained in chat transcripts, service logs, debugging records, or other session storage. `SKILL.md` correctly instructs the Agent not to print secre ...[truncated 1962 chars]
• Remediation: ## Remediation Suggestions 1. Prefer an operating-system credential manager or another encrypted secret store instead of a project-local `.env` file. 2. If `.env` remains supported: - Require file permissions equivalent to `0600`. - Require the parent directory to be inaccessible to untrusted users. - Add `.env` and related secret files to `.gitignore`. - Provide only a redacted `.env.example` template. - Warn against copying the file into tickets, logs, or backups. 3. Do not ask users to provide access tokens through chat or Agent interactions. Have users complete authentication locally and save the token directly into the approved credential store. 4. Ensure subprocess output, shell history, diagnostic logs, and error messages redact tokens, passwords, authorization codes, and client secrets. 5. Use the narrowest available OAuth scopes and short token lifetimes. 6. Document token revocation and credential-rotation procedures for suspected exposure. 7. Avoid exposing secrets as command-line arguments, because they may be visible in process listings or shell history. 8. Preserve the existing prohibition against displaying secrets in user-visible output and extend it to all logs and persisted Agent state.

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (4)

Credential Access

High

• Category: Privilege Escalation

Content

- Start manual auth only when user is ready to approve immediately.
- Paste the auth `code` right away; codes can expire quickly.
- If interactive prompt cannot be kept stable, have user run `ticktick auth --manual` themselves and provide the resulting access token.

• Confidence: 92% confidence
• Finding: The instruction to have the user 'provide the resulting access token' encourages disclosure of a bearer credential back through the agent interaction channel. Access tokens can typically be replayed to access the user's TickTick account, so requesting or transmitting them in chat/logged workflow significantly increases credential exposure risk.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The guide instructs users to store highly sensitive OAuth client secrets, access tokens, usernames, and passwords in a plain `.env` file, but gives no safeguards about restricting file permissions, avoiding commits, or using a secret store. In a setup/auth skill, this omission is materially risky because users are being coached through credential handling and may persist long-lived secrets insecurely on disk.

Missing User Warnings

Medium

• Confidence: 90% confidence
• Finding: The troubleshooting guidance tells the user to provide a fresh auth code or token during recovery flows but does not warn that these values are sensitive secrets that should not be pasted into chat, logs, or other insecure channels. In a CLI support skill, this omission can lead to credential disclosure to the agent runtime, transcripts, shell history, or other observers, enabling unauthorized access to the user's TickTick account.

Missing User Warnings

Medium

• Confidence: 92% confidence
• Finding: The documentation explicitly notes that `ticktick sync --json` emits a raw full-account sync payload, which is likely to contain highly sensitive account data, but it provides no privacy warning, redaction guidance, or handling constraints. In an agent skill context, this increases the chance that a user or downstream agent will retrieve, display, log, or share the full payload during troubleshooting, causing unintended exposure of personal or account-wide data.