Back to skill

Security audit

Cosin

Security checks for vulnerabilities and agentic risk

Overview

The skill describes a legitimate COS CLI workflow, but it asks agents to use sensitive bearer tokens with broad authenticated and payment-backed API access in ways that need review before installation.

Review this skill before installing. Use only short-lived, least-privileged COS tokens, avoid `--base-url` except for a known trusted HTTPS COS endpoint, and prefer a pinned or locally verified cosin CLI instead of downloading and executing the latest package with a live token.

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

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:43
Finding
Bearer Token Exposed Through Command-Line Arguments## Vulnerability Details **File Location**: `SKILL.md:43-47`; vulnerable command examples appear at `SKILL.md:53-56` **Vulnerability Type**: Bearer credential exposure through process arguments and command history **Risk Level**: Medium ### Vulnerable Code ```markdown ## Protect credentials - Treat the `--key` value as sensitive - Do not print, commit, or hardcode the token - Keep the token in the command line argument, not in repo files ``` The documented command pattern is: ```sh cosin --key <token> <METHOD> <PATH> [--json '<json>'] [--header 'Name: value'] [--base-url <url>] cosin --key <token> agent [status|me] [--base-url <url>] cosin --key <token> skills ``` ### Technical Analysis The skill explicitly instructs users and agents to place a sensitive bearer token in a command-line argument. Depending on the operating environment, command-line arguments can be exposed through: - Shell history files. - Process inspection utilities and operating-system process interfaces. - Terminal transcripts and agent tool-call records. - CI/CD logs, debugging output, telemetry, or monitoring systems. - Parent processes and other local processes operating with sufficient inspection privileges. Avoiding repository files does not make command-line transmission safe. The token remains exposed to multiple local and operational logging surfaces. ### Attack Path 1. A user provides a valid COS bearer token to the agent. 2. The agent follows the documented command shape and invokes `cosin --key <token> ...`. 3. The complete command, including the token, is retained in shell history, process metadata, terminal logs, or agent execution records. 4. An attacker with access to one of those sources extracts the bearer token. 5. The attacker uses the token to authenticate to COS and issue requests as the victim. ### Impact Assessment Token theft may permit unau ...[truncated 361 chars]
Remediation
## Remediation Suggestions - Do not pass bearer tokens directly as command-line arguments. - Add support for reading the token from a protected environment variable, standard input, operating-system credential store, or permission-restricted configuration file. - Prefer an interactive hidden prompt when a human supplies the token. - Ensure the CLI and surrounding agent infrastructure redact authorization credentials from logs, errors, telemetry, and command previews. - Document shell-history protections for any unavoidable sensitive invocation. - Use short-lived, narrowly scoped tokens and provide an immediate revocation and rotation procedure.

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:59
Finding
Base URL Override Can Redirect Bearer-Authenticated Requests## Vulnerability Details **File Location**: `SKILL.md:32-39`, `SKILL.md:53-54`, and `SKILL.md:59-64` **Vulnerability Type**: Unrestricted credential destination and insufficient endpoint validation **Risk Level**: High ### Vulnerable Code ```markdown Collect these inputs before running the CLI: - A COS bearer token for `--key` - An HTTP method - A relative path starting with `/` - Optional JSON for `--json` - Optional repeatable headers for `--header` or `-H` - Optional `--base-url` override for normal COS API calls ``` ```sh cosin --key <token> <METHOD> <PATH> [--json '<json>'] [--header 'Name: value'] [--base-url <url>] ``` ```markdown Important flags: - `--key <token>` for the required bearer token - `--json <json>` for an optional JSON request body - `--header 'Name: value'` or `-H 'Name: value'` for repeatable custom headers - `--base-url <url>` to override the default COS API base URL for direct API calls ``` ### Technical Analysis The skill permits a caller to combine a required COS bearer token with an arbitrary `--base-url` override. It provides no documented HTTPS-only requirement, trusted-host allowlist, origin validation, or warning that authorization credentials must not be forwarded when the destination host changes. If the CLI attaches the bearer token to requests sent through the override, an attacker-controlled endpoint can collect the credential. The source implementation is absent from the audited project, so implementation-level safeguards could not be verified. ### Attack Path 1. An attacker causes a user or agent to use an attacker-controlled URL as the `--base-url` value. 2. The victim supplies a valid COS bearer token as required by the documented command. 3. The CLI sends a request to the override destination with the bearer credential attached. 4. The attacker records the authorization credential at the malicious serv ...[truncated 681 chars]
Remediation
## Remediation Suggestions - Restrict `--base-url` to an explicit allowlist of trusted COS HTTPS origins. - Reject plaintext HTTP, URLs containing embedded credentials, unexpected ports, redirects to different origins, and non-network schemes. - Do not attach the COS bearer token when the destination origin differs from the configured trusted COS origin. - Require explicit user confirmation for any hostname override and clearly display the final destination without displaying the token. - Validate every redirect and strip authorization headers on cross-origin redirects. - Consider removing the override from normal usage and exposing it only through a separately gated development mode. - Add tests proving that credentials are never transmitted to untrusted or redirected destinations.

T08 · Insecure Dependencies

Error
Location
SKILL.md:168
Finding
Unpinned Third-Party Package Is Downloaded and Executed with Access to Credentials## Vulnerability Details **File Location**: `SKILL.md:168-173` **Vulnerability Type**: Unpinned package execution and software supply-chain exposure **Risk Level**: High ### Vulnerable Code ```sh bun x cosin --key <token> agent bun x cosin --key <token> skills bun x cosin --key <token> GET /v1/me bun x cosin --key <token> GET /cos/crypto/price/BTC ``` ### Technical Analysis The documented `bun x cosin` command resolves and executes a third-party package without specifying an audited version or integrity digest. Its effective implementation can therefore change after this skill has been reviewed. The downloaded package executes with the privileges of the invoking user and is directly given the COS bearer token. A compromised package release, registry account, dependency, or package-resolution source could execute arbitrary code and exfiltrate the token or other accessible data. The project includes no package manifest, lockfile, vendored implementation, checksum, signature, or provenance information that would allow the executed code to be verified during this audit. ### Attack Path 1. An attacker compromises the `cosin` package, one of its transitive dependencies, its publisher account, or the package registry resolution path. 2. A malicious package version becomes the version resolved by `bun x cosin`. 3. A user or agent follows the skill and runs the unpinned command. 4. The package executes locally with the invoking user's operating-system permissions. 5. The malicious code reads the bearer token from command-line arguments and may access other files, environment variables, or network resources available to the user. 6. The attacker exfiltrates credentials or performs additional actions under the user's local and COS privileges. ### Impact Assessment Exploitation can result in arbitrary code execution with the privileges of the invoking user. Potential consequences include COS bea ...[truncated 343 chars]
Remediation
## Remediation Suggestions - Pin `cosin` to a specific audited version rather than resolving the latest available package. - Use a committed lockfile with verified integrity hashes. - Verify registry ownership, package signatures, provenance attestations, and release checksums before execution. - Prefer a locally installed, reviewed dependency over on-demand package downloading. - Execute the CLI in a sandbox with minimal filesystem, environment, and network access. - Do not provide credentials until the package identity and integrity have been verified. - Use a short-lived and least-privileged token for each invocation. - Add dependency monitoring and a controlled update process requiring security review before changing the pinned version.
Vulnerability Patterns
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep

Static analysis

No suspicious patterns detected.