dida365-ticktick-agent

• Outcome: Review
• Latest audit: Sep 11, 2026 · 4:41 AM UTC
• Version: 1.0.0

Overview

The skill matches its Dida365 task-management purpose, but it gives unsafe instructions for installing a global tool and handling account cookies and secrets.

Review before installing. Use a pinned, trusted version of the CLI if possible, avoid putting real cookies or OAuth secrets directly in shell commands or wrapper scripts, check where the CLI stores credentials, and rotate/revoke any cookie or secret that has been exposed in shell history, files, logs, backups, or repositories.

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 (3)

T08 · Insecure Dependencies

Warning

• Location: SKILL.md:15
• Finding: Unpinned Third-Party Package Installed Globally<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 15-19 **Vulnerability Type**: Unpinned global dependency installation **Risk Level**: Medium ### Vulnerable Code ```bash ## Installation ```bash npm install -g dida365-ai-tools ``` ``` ### Technical Analysis The Skill instructs users to install the latest available version of the third-party `dida365-ai-tools` npm package globally. It does not specify a reviewed version, integrity hash, lockfile, verified source repository, or package provenance. An npm package can execute lifecycle scripts during installation. Global installation also makes the package available throughout the user's environment and executes its CLI with the user's privileges. Because this project contains only documentation, the installed package's implementation, network destinations, credential-storage behavior, and lifecycle scripts cannot be audited from the supplied artifact. This represents an unsafe software supply-chain boundary rather than evidence that the named package is malicious. ### Attack Path 1. The package publisher account, npm package, or distribution process is compromised, or a future release introduces malicious behavior. 2. A user follows the documented command without pinning a specific reviewed version. 3. npm retrieves the current package release and may execute its installation lifecycle scripts. 4. The installed package subsequently receives the user's Dida365 session cookie or OAuth credentials through the documented authentication workflow. 5. Malicious package code can access those credentials, Dida365 task data, and other resources available to the user's local account. ### Impact Assessment Successful exploitation would execute code with the privileges of the user running npm or the CLI. The likely scope includes theft of the Dida365 session cookie and OAuth credentials, unauthorized access to task data, modification or completion of tasks, and access to other files and envir ...[truncated 183 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Pin the dependency to an explicitly reviewed version instead of installing the latest release. - Publish or reference the package's auditable source repository and verify that the npm package corresponds to that source. - Provide a lockfile, package integrity value, signed release, or other verifiable provenance information. - Review npm lifecycle scripts before installation and use `--ignore-scripts` when lifecycle execution is not required. - Prefer a project-local or isolated installation over a global installation. - Run the CLI under a dedicated least-privileged account or sandbox where practical. - Document package ownership, expected network destinations, credential-storage behavior, and a process for reviewing upgrades. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:40
• Finding: Dida365 Session Cookie Exposed Through Command-Line Arguments<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 40-44 **Vulnerability Type**: Sensitive authentication token passed through process arguments **Risk Level**: High ### Vulnerable Code ```bash ### Step 3: Save the Cookie ```bash dida365 auth cookie "your_cookie_value" ``` ``` The placeholder above represents the authentication-cookie value requested by the original instructions. ### Technical Analysis The documented authentication procedure passes a live Dida365 session cookie directly as a command-line argument. Command-line arguments may be recorded in shell history and can be exposed through process inspection, terminal logging, diagnostic collection, audit systems, or command telemetry. The Skill also states that the CLI saves the cookie but provides no information about the destination, encryption, file permissions, retention period, or revocation process. A Dida365 session cookie is an authentication bearer token: possession may be sufficient to impersonate the authenticated session without knowing the user's password. ### Attack Path 1. The user extracts the `t` session cookie from the authenticated Dida365 browser session. 2. The user runs the documented `dida365 auth cookie` command with the real cookie as an argument. 3. The command and cookie are retained in shell history, captured by logging, or temporarily exposed through local process-argument inspection. 4. A local user, support process, malware instance, history backup, or log reader obtains the cookie. 5. The attacker replays the bearer token against Dida365 while it remains valid. 6. The attacker accesses or modifies data available to the compromised account session. ### Impact Assessment An exposed cookie may enable unauthorized access to the victim's Dida365 account within the permissions and lifetime of the session. Potential impact includes viewing project and task information, creating tasks, completing tasks, synchronizing account data, and obtaining ot ...[truncated 213 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Do not accept session cookies as command-line arguments. - Read the cookie from masked standard input, an interactive secure prompt, or an operating-system credential manager. - Prefer an OAuth authorization flow that does not require users to manually extract browser session cookies. - If environment-based transfer is unavoidable, clearly explain its residual exposure and unset the variable immediately after use. - Store credentials in an operating-system keychain or encrypted credential store. - If file storage is necessary, enforce owner-only permissions and avoid plaintext storage. - Prevent authentication values from appearing in shell history, application logs, error messages, crash reports, or telemetry. - Document credential expiration, logout, revocation, deletion, and incident-response procedures. - Warn users to rotate or revoke a cookie immediately if it has been entered into an exposed command history. ]]>

T09 · Insecure Skill Coding Practices

Error

• Location: SKILL.md:96
• Finding: OAuth Credentials Embedded in a PATH Wrapper Script<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 96-103 **Vulnerability Type**: Plaintext credential storage and unsafe command wrapping **Risk Level**: High ### Vulnerable Code ```bash #!/bin/bash export DIDA365_CLIENT_ID="your_client_id" export DIDA365_CLIENT_SECRET="your_client_secret" dida365 "$@" ``` The English placeholders above correspond to the credential placeholders in the original wrapper example. ### Technical Analysis The suggested wrapper embeds the OAuth client ID and client secret directly in a plaintext executable file. The instructions do not require owner-only permissions, exclude the file from source control, or use an operating-system secret manager. Consequently, the secret may be exposed through filesystem access, backups, repository commits, endpoint indexing, or support bundles. The instructions additionally recommend saving the wrapper as `dida365`, adding it to `PATH`, and invoking `dida365 "$@"` from inside that wrapper. Depending on PATH order and shell command resolution, the inner invocation can resolve to the wrapper itself. This can cause recursive execution and resource exhaustion rather than invoking the intended CLI. It also creates ambiguity about which executable receives the credentials. No intentional tool replacement or attacker-controlled spoofing is demonstrated, so the primary classification is insecure secret handling rather than confirmed tool hijacking. ### Attack Path 1. The user creates the recommended wrapper and replaces the placeholders with valid OAuth credentials. 2. The credentials remain stored as plaintext in the script. 3. The wrapper is given permissive file permissions, included in a backup, committed to a repository, or otherwise read by another local principal. 4. The observer extracts the client ID and client secret. 5. The credentials are used against supported Dida365 authentication interfaces, subject to the application's configured permissions and provider cont ...[truncated 889 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Do not place OAuth secrets directly in wrapper scripts. - Retrieve secrets at runtime from an operating-system credential manager, protected secrets service, or another appropriately secured configuration mechanism. - If a protected configuration file is required, keep it outside the project, enforce owner-only permissions, and exclude it from source control and backups where appropriate. - Provide a secret-free wrapper template and document secure provisioning separately. - Rotate credentials if a populated wrapper has been committed, shared, backed up insecurely, or exposed to unauthorized readers. - Resolve and invoke the actual CLI using a verified absolute path or give the wrapper a distinct name to prevent recursive command resolution. - Validate the target executable's ownership and integrity before forwarding arguments. - Use `exec` with the verified binary path so the wrapper does not leave an unnecessary parent shell process. - Document the minimum OAuth scopes required and configure the application according to least privilege. ]]>

SkillSpector

Vulnerability Patterns

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

Findings (2)

Missing User Warnings

Medium

• Confidence: 95% confidence
• Finding: The skill instructs users to extract a browser cookie and store authentication material via environment variables/CLI commands, but provides no warning about the sensitivity of those secrets, their storage location, shell history exposure, or the risk of account takeover if leaked. In this context, the cookie appears sufficient for authentication, so mishandling it could directly expose the user's Dida365 account.

Missing User Warnings

Medium

• Confidence: 97% confidence
• Finding: The wrapper-script example hardcodes sensitive credentials into a shell script and tells users to place it on PATH, which can leave secrets readable by other local users, backups, repo commits, or system tooling. Embedding long-lived credentials in plaintext files materially increases the chance of credential leakage and downstream account compromise.

Static analysis

No suspicious patterns detected.