Trust Assessment
unimarket received a trust score of 68/100, placing it in the Caution category. This skill has some security considerations that users should review before deployment.
SkillShield's automated analysis identified 6 findings: 0 critical, 1 high, 2 medium, and 3 low severity. Key findings include Unpinned npm dependency version, Hardcoded API Key in Wallet Configuration, Direct Access to Private Key from SDK Internal Field.
The analysis covered 4 layers: Manifest Analysis, Static Code Analysis, Dependency Graph, LLM Behavioral Safety. All layers scored 70 or above, reflecting consistent security practices.
Last analyzed on February 13, 2026 (commit 13146e6a). SkillShield performs automated 4-layer security analysis on AI skills and MCP servers.
Layer Breakdown
Behavioral Risk Signals
Security Findings6
| Severity | Finding | Layer | Location | |
|---|---|---|---|---|
| HIGH | Hardcoded API Key in Wallet Configuration The `lib/wallet.ts` file contains a hardcoded API key for `UNICITY_API_KEY` as a fallback if the environment variable is not set. While this might be intended for development or a public API, hardcoding API keys, even public ones, can lead to misuse, rate-limiting issues, or expose the key if it's ever upgraded to a more sensitive one. It's generally safer to always rely on environment variables or a secure configuration management system. Remove the hardcoded fallback API key. Ensure `UNICITY_API_KEY` is always provided via environment variables or a secure configuration mechanism. If the key is truly public and non-sensitive, add a comment explaining this, but prefer removing it to avoid confusion or future security risks. | LLM | lib/wallet.ts:26 | |
| MEDIUM | Unpinned npm dependency version Dependency '@noble/curves' is not pinned to an exact version ('^2.0.1'). Pin dependencies to exact versions to reduce drift and supply-chain risk. | Dependencies | skills/jvsteiner/unimarket/package.json | |
| MEDIUM | Direct Access to Private Key from SDK Internal Field The `getPrivateKeyHex` function in `lib/wallet.ts` accesses the private key directly from an internal, non-public field `_identity` of the `Sphere` SDK instance. The comment explicitly states that the public `sphere.identity` getter strips the private key, indicating this is an intentional design choice by the SDK to prevent direct exposure. Bypassing this abstraction to access the private key directly increases the risk of accidental exposure or misuse within the skill's codebase. While the skill needs the private key for signing, relying on internal SDK implementation details is fragile and potentially insecure if the SDK changes its internal structure or security mechanisms. Consult the `@unicitylabs/sphere-sdk` documentation for the officially supported and secure way to access the private key for signing operations. If no public API exists, consider requesting one from the SDK developers or encapsulating this sensitive operation more securely within the SDK itself. Avoid relying on internal, undocumented fields. | LLM | lib/wallet.ts:40 | |
| LOW | Potential Command Injection via `process.argv` in `scripts/intent.ts` The `scripts/intent.ts` file parses command-line arguments directly from `process.argv` and uses them to construct API requests. Specifically, the `desc`, `type`, `category`, `price`, and `location` arguments are taken directly from user input without explicit sanitization or validation before being sent in the API request body. While the immediate impact is limited to the API request body (which is JSON stringified), if the backend API is vulnerable to injection attacks (e.g., SQL injection, NoSQL injection, XSS if displayed unsanitized), this could be a vector. The `parseArgs` function itself is simple and doesn't directly execute shell commands, but the values are passed to `apiPost` which then JSON stringifies them. The risk is primarily on the backend, but the client-side script is passing unsanitized user input. Implement robust input validation and sanitization for all user-provided arguments (`desc`, `type`, `category`, `price`, `location`) before including them in API requests. This should include type checking, length limits, and character whitelisting where appropriate. While JSON stringification helps prevent direct command injection, it doesn't protect against logical or data-level injections if the backend is vulnerable. | LLM | scripts/intent.ts:10 | |
| LOW | Potential Command Injection via `process.argv` in `scripts/register.ts` Similar to `scripts/intent.ts`, the `scripts/register.ts` file parses command-line arguments (`name`, `nostr`) directly from `process.argv` without explicit sanitization or validation. These values are then used in the API request body. If the backend API is vulnerable to injection attacks (e.g., SQL injection, NoSQL injection, XSS if displayed unsanitized), this could be a vector. The `parseArgs` function itself is simple and doesn't directly execute shell commands, but the values are passed to `fetch` which then JSON stringifies them. The risk is primarily on the backend, but the client-side script is passing unsanitized user input. Implement robust input validation and sanitization for all user-provided arguments (`name`, `nostr`) before including them in API requests. This should include type checking, length limits, and character whitelisting where appropriate. While JSON stringification helps prevent direct command injection, it doesn't protect against logical or data-level injections if the backend is vulnerable. | LLM | scripts/register.ts:6 | |
| LOW | Potential Command Injection via `process.argv` in `scripts/search.ts` The `scripts/search.ts` file parses command-line arguments (`query`, `type`, `category`, `limit`) directly from `process.argv` without explicit sanitization or validation. These values are then used in the API request body. If the backend API is vulnerable to injection attacks (e.g., SQL injection, NoSQL injection, XSS if displayed unsanitized), this could be a vector. The `parseArgs` function itself is simple and doesn't directly execute shell commands, but the values are passed to `apiPublicPost` which then JSON stringifies them. The risk is primarily on the backend, but the client-side script is passing unsanitized user input. Implement robust input validation and sanitization for all user-provided arguments (`query`, `type`, `category`, `limit`) before including them in API requests. This should include type checking, length limits, and character whitelisting where appropriate. While JSON stringification helps prevent direct command injection, it doesn't protect against logical or data-level injections if the backend is vulnerable. | LLM | scripts/search.ts:5 |
Scan History
Embed Code
[](https://skillshield.io/report/9f89c3e3dc9c9ef2)
Powered by SkillShield