T08 · Insecure Dependencies
- Location
README_EN.md:148- Finding
Unpinned Third-Party Payment Skill Installation
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is coherent market-data tooling, but it delegates wallet/payment setup to a mutable external OKX skill and models API keys weakly, so users should review it before installing.
Install only if you are comfortable sending a CoinAnk API key to open-api.coinank.com and using OKX wallet/payment tooling for pay-per-call requests. Prefer a pinned, verified OKX skill version, keep private keys and seed phrases out of the agent environment, and independently confirm every non-zero payment amount, token, network, and recipient before authorization.
README_EN.md:148Unpinned Third-Party Payment Skill Installation
plugin.yaml:13Unexplained External Network Permission for s.cdnblock.com
The README instructs users to run npx skills add okx/onchainos-skills without pinning a version. Unpinned package execution can pull whatever version is current at install time, which creates a supply-chain risk: a compromised upstream release or breaking change could execute unintended code in the user's environment. In this skill's context, that risk is more serious because the installed package participates in wallet login and payment flows.
The README instructs users to run npx skills add okx/onchainos-skills without pinning a specific package version or commit. That creates a supply-chain risk: future package updates or a compromised upstream release could cause users to install and execute attacker-controlled code in a wallet/payment context, which is more sensitive than ordinary tooling because it may handle signing or payment flows.
This manifest-like OpenAPI file uses Chinese as the sole language for the API title, tags, summaries, and descriptions, such as the title at L004 and endpoint text at L016-L018. Under the stated policy, forcing a specific language without user opt-in is a natural-language locale violation because no alternative locale or explicit regional justification is provided.
This manifest/config file uses Chinese as the default language for the API title and most endpoint summaries/descriptions, with no indication of user opt-in or alternative locale support. Under the policy, forcing a specific language without choice is a natural-language locale violation.
The OpenAPI metadata uses Chinese-only human-readable text such as the title "默认模块" and tag name "hyperLiquid鲸鱼". This imposes a specific language on users and integrators without any indication of language selection, localization support, or documented regional limitation.
This manifest/config file contains user-facing natural language such as the API title and endpoint summaries in Chinese, beginning with "默认模块" and "两年MA乘数(API等级1)", with no indication that users can select another language. Under the policy, forcing a specific language without user opt-in is a natural-language locale violation unless the regional constraint is clearly documented and justified.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
"type": "integer"
}
},
"marketCapList": {
"type": "array",
"items": {
"oneOf": [
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
"type": "integer"
}
},
"marketCapList": {
"type": "array",
"items": {
"oneOf": [
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
"type": "integer"
}
},
"marketCapList": {
"type": "array",
"items": {
"oneOf": [
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
"type": "integer"
}
},
"marketCapList": {
"type": "array",
"items": {
"oneOf": [
This OpenAPI file uses Chinese for the title, tag names, endpoint summary, and parameter descriptions, while only small parts are in English. The policy for this audit flags language/locale constraints when a skill forces a specific language without offering user choice or documenting a justified locale restriction.
This operation requires an apikey header but declares security: [] and the document defines no securitySchemes, so tooling may treat the endpoint as unauthenticated even though credentials are required. In agent contexts, that mismatch can cause unsafe prompt-time credential collection, poor auth handling, and accidental transmission of user secrets without proper security UX or policy enforcement.
The spec requires users to provide an API key for an external service but does not clearly warn that the credential will be transmitted to open-api.coinank.com. In an agent setting, lack of explicit disclosure weakens informed consent and increases the chance users provide sensitive third-party secrets without understanding where they go.
The endpoint requires an API key header but explicitly declares no security requirements, creating a misleading contract between the spec and any consuming agent or SDK. That inconsistency can bypass security-aware tooling controls and lead to credential prompting or forwarding in ways users do not expect.
This endpoint also requires external credential transmission without an explicit warning to the user. For agent-integrated skills, that omission is security-relevant because the platform may solicit and forward secrets on the user's behalf with insufficient transparency.
This operation mixes a required sensitive header with an empty security declaration, which is a genuine security design flaw in the API description. Consumers may mishandle or under-protect the credential because the spec does not formally identify it as authentication material.
The endpoint documents mandatory API-key use but gives no clear notice that a user secret is being sent to a third-party remote service. That gap can mislead users and integrators about the sensitivity of the action and the trust boundary being crossed.
The spec requires an API key while advertising no security requirements, which can cause client generators, gateways, or agents to misclassify the endpoint as unauthenticated. In practice, this increases the chance of secrets being collected and transmitted outside standardized auth flows and audit controls.
This authenticated endpoint lacks explicit disclosure around external credential transmission, which is a real security concern in tools that may automatically request secrets from users. Without that warning, users may not realize they are authorizing third-party access using their API credentials.
This endpoint has the same auth-spec mismatch: a required API key header but no declared security requirement. Such mismatches are especially risky in agent ecosystems because policy engines often rely on formal auth metadata to decide whether secret access and user confirmation are required.
The specification requires sensitive credentials but omits a user-facing warning about sending them to an external service. In the context of an agent skill, this makes the issue more dangerous because the skill may normalize secret submission through conversational UX without adequate disclosure.
The kline endpoint requires credential submission but the spec omits formal security metadata, creating an inaccurate and unsafe contract for automated consumers. This can undermine consent prompts, secret scanning, and auth-aware middleware that depend on declared OpenAPI security semantics.
The kline endpoint requires an API key yet provides no explicit warning that the secret will be transmitted to an external API provider. This is a meaningful security and privacy issue for agent users, who need clear notice before disclosing third-party credentials.
This manifest file contains user-facing natural-language content such as the title and tags in Chinese, and the rest of the API descriptions are also largely Chinese. Under the language/locale policy, forcing a specific language without user opt-in or a documented regional justification is a policy concern.
The endpoint summary and schema describe active buy/sell count data with array items consisting of three numeric fields, but the example payload shows four numbers per entry, matching a different metric shape. This is an active documentation-to-spec contradiction that can mislead agents about what the operation actually returns.
No suspicious patterns detected.