Back to skill

Security audit

KashDAO CLI

Security checks for vulnerabilities and agentic risk

Overview

The skill is coherent for KashDAO trading, but it asks users to install a mutable global CLI and use sensitive trading credentials with insufficiently constrained endpoint override behavior.

Install only after you are comfortable trusting the KashDAO npm package and its update process. Prefer a pinned reviewed CLI version, use a least-privilege revocable test key first, avoid custom base URLs unless they are official Kash endpoints you control, and do not point signerKeyRef at valuable keys unless you have independently reviewed the CLI behavior.

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:22
Finding
Unpinned Executable npm Dependency<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:22` and `SKILL.md:51-53` **Vulnerability Type**: Supply-chain risk caused by a mutable dependency version **Risk Level**: Medium ### Vulnerable Code ```yaml install: node: '@kashdao/cli@latest' ``` ```sh npm install -g @kashdao/cli@latest ``` ### Technical Analysis The skill instructs users to install the executable `@kashdao/cli` package using the mutable `latest` npm tag. It does not specify an audited version, integrity hash, signature, lockfile, or other mechanism that would ensure users consistently install the same reviewed artifact. The project contains only `SKILL.md`; it does not include the CLI implementation. Consequently, the package's effective behavior—including how it handles API credentials, signer references, and financial transactions—cannot be verified from the audited project. Global installation also increases exposure because npm lifecycle scripts and the installed executable run with the installing user's privileges. This finding does not establish that the current npm package is malicious. The vulnerability is the unsafe dependency-resolution mechanism, which allows future package releases or a compromised package publication process to change the executable installed by the skill without requiring a corresponding change to the reviewed project. ### Attack Path 1. An attacker compromises the npm publisher account, package release pipeline, or another component of the package's supply chain. 2. The attacker publishes a malicious version of `@kashdao/cli` and assigns it the `latest` tag. 3. A user or agent follows the skill's installation instruction. 4. npm resolves `@latest` to the attacker-controlled release and installs it globally. 5. Malicious installation scripts or CLI code execute with the user's local privileges. 6. When the CLI is used, the compromised package may access `KASH_API_KEY`, configuration data, signer references, transaction parameters, and o ...[truncated 775 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Replace `@kashdao/cli@latest` with an exact, reviewed version, such as `@kashdao/cli@X.Y.Z`. 2. Publish and verify package integrity metadata or cryptographic signatures before installation. 3. Supply a lockfile or equivalent reproducible dependency manifest where the deployment mechanism supports it. 4. Avoid global installation where possible; install into an isolated, least-privileged environment. 5. Disable npm lifecycle scripts during installation when they are not required, or explicitly audit every required lifecycle script. 6. Establish a controlled update process in which each new dependency version is reviewed before the pinned version is changed. 7. Make auditable CLI source available alongside the skill or reference a verifiable source commit corresponding exactly to the distributed npm artifact. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
SKILL.md:16
Finding
Authenticated API Requests Can Be Redirected to an Arbitrary Base URL<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:16-18` and `SKILL.md:213` **Vulnerability Type**: Unsafe endpoint override for an authenticated client **Risk Level**: Medium ### Vulnerable Code ```yaml - name: KASH_BASE_URL required: false description: Override the auto-routed API base URL. Use only when you want to pin a specific environment regardless of the key's prefix. ``` ```markdown | `--base-url <url>` | Override the auto-routed base URL. | ``` ### Technical Analysis The skill exposes both an environment variable and a command-line option that can override the API base URL. No hostname allowlist, HTTPS-only requirement, certificate-pinning policy, or explicit approval mechanism is documented for nonstandard endpoints. The same client is expected to operate with `KASH_API_KEY`. If the implementation sends that credential to the configured base URL, an attacker who can influence `KASH_BASE_URL`, `--base-url`, a selected profile, or generated command arguments could redirect authenticated requests to an attacker-controlled service. Because the CLI implementation is not included in the audited project, it is not possible to confirm whether authorization headers are sent to arbitrary hosts or retained across redirects. The risk therefore arises from the documented unrestricted configuration surface and the absence of stated credential-binding protections. ### Attack Path 1. An attacker influences the environment, selected profile, automation configuration, or command arguments used by an agent. 2. The attacker sets `KASH_BASE_URL` or supplies `--base-url` with an attacker-controlled HTTPS endpoint. 3. The agent invokes an authenticated command such as a market, portfolio, webhook, quote, or trade operation. 4. If the CLI attaches `KASH_API_KEY` to requests sent to the configured host, the attacker-controlled server receives the credential and request data. 5. The attacker reuses the exposed c ...[truncated 847 chars]
Remediation
<![CDATA[ ## Remediation Suggestions 1. Restrict authenticated API requests to an explicit allowlist of official Kash hostnames by default. 2. Require HTTPS and reject plaintext HTTP endpoints. 3. Require an explicit, interactive trust decision before sending credentials to any custom hostname. 4. Bind credentials to their intended environment and host so that production or staging keys cannot be sent to unrelated endpoints. 5. Never forward authorization headers when an HTTP redirect changes the origin. 6. Validate URL parsing carefully and reject user-info components, malformed hosts, unexpected ports, and hostname-confusion patterns. 7. Provide a separate credential mechanism for development or custom endpoints rather than reusing production or staging API keys. 8. Document the security consequences of `KASH_BASE_URL` and `--base-url`, including a warning that untrusted values may expose credentials. 9. Add automated tests confirming that credentials are not transmitted to unapproved hosts or across cross-origin redirects. ]]>
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.