T09 · Insecure Skill Coding Practices
- Location
auto-deploy.js:13- Finding
Plaintext ClawHub Account Credentials Embedded and Logged
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill has a coherent wallet-monitoring purpose, but it ships exposed payment and ClawHub credentials plus deployment and billing behavior that needs review before installation.
Review this skill before installing or running it. The publisher should rotate the exposed API keys and ClawHub password, remove deployment credentials from the package, replace secrets with environment-based configuration, validate webhook destinations, and either implement or remove the advertised safety and filtering controls.
auto-deploy.js:13Plaintext ClawHub Account Credentials Embedded and Logged
index.js:16Hard-Coded SkillPay and BSCScan API Keys
index.js:457Payment Authorization Can Be Bypassed with a Caller-Controlled Boolean
index.js:254Unrestricted Webhook Destination Enables Server-Side Request Forgery
deploy.sh:29Unpinned Global Installation and Execution of a Third-Party CLI
auto-deploy.js:117Deployment Script Uploads an Unverified Archive from Outside the Project
SKILL.md:147Advertised Token Safety and Filtering Controls Are Not Implemented
The delivery report contains a concrete SkillPay API key in plaintext, which is a sensitive credential and should never be embedded in documentation. Anyone with access to this file could reuse the key to create fraudulent charges, access payment functionality, or abuse the associated account, and the skill's monitoring purpose does not justify exposing a secret at all.
This markdown publicly exposes a live-looking SkillPay API key without any warning, redaction, or safe handling guidance, increasing the likelihood that downstream users will copy, commit, or misuse it. In practice this is another manifestation of secret leakage, and because it relates to payment infrastructure it can directly enable financial abuse or service compromise.
The deployment guide directly exposes a plaintext email/password pair and instructs users to use them to access a third-party service, plus references downloading a server-hosted artifact from /root/.openclaw/workspace. This creates immediate credential compromise risk, unauthorized account access, and potential leakage of privileged server files if the document is shared or published.
Publishing a live-looking API key in an installation guide is a direct secret disclosure. Even if the key is intended for testing, readers have no warning that it is sensitive, and exposed credentials are commonly harvested automatically from public content for unauthorized API usage and account abuse.
The README includes a live-looking secret key (sk_...) in a configuration example, which is a genuine credential exposure risk. Even if it was intended as sample data, publishing realistic secrets in documentation can enable unauthorized use of the payment service, billing abuse, or compromise of linked accounts; in a paid monitoring skill, that context makes the exposure more dangerous because the key likely grants access to payment operations.
The file contains plaintext login credentials and explicit instructions to use them to access an external service. This is dangerous because anyone with access to the skill files can reuse the credentials, take over the associated account, upload malicious content, or access private deployment data.
The document not only exposes account credentials but instructs the operator to log in with them, which facilitates credential misuse and unauthorized account access. In deployment context, this is especially risky because the account may control publication, billing, or update rights for the skill.
The summary embeds a live-looking SkillPay API key directly in documentation. Hardcoded secrets in distributable files can be harvested by anyone with repository or package access, enabling unauthorized API use, fraudulent billing actions, or abuse of the linked payment account.
Publishing a secret API credential without any handling guidance is dangerous because it normalizes insecure secret management and exposes the token for immediate misuse. In a payment context, exposed credentials can lead to unauthorized payment operations, account abuse, and financial or reputational damage.
The file appears to function more as packaging/deployment/payment metadata than as a trustworthy specification for a live wallet-monitoring system, while still presenting itself as a security-aware monitoring tool. That mismatch is dangerous because it can induce users to rely on nonexistent monitoring, notification, or safety mechanisms in a fast-moving crypto environment.
The file appears to function more as packaging/deployment/payment metadata than as a trustworthy specification for a live wallet-monitoring system, while still presenting itself as a security-aware monitoring tool. That mismatch is dangerous because it can induce users to rely on nonexistent monitoring, notification, or safety mechanisms in a fast-moving crypto environment.
The file appears to function more as packaging/deployment/payment metadata than as a trustworthy specification for a live wallet-monitoring system, while still presenting itself as a security-aware monitoring tool. That mismatch is dangerous because it can induce users to rely on nonexistent monitoring, notification, or safety mechanisms in a fast-moving crypto environment.
The file appears to function more as packaging/deployment/payment metadata than as a trustworthy specification for a live wallet-monitoring system, while still presenting itself as a security-aware monitoring tool. That mismatch is dangerous because it can induce users to rely on nonexistent monitoring, notification, or safety mechanisms in a fast-moving crypto environment.
The file appears to function more as packaging/deployment/payment metadata than as a trustworthy specification for a live wallet-monitoring system, while still presenting itself as a security-aware monitoring tool. That mismatch is dangerous because it can induce users to rely on nonexistent monitoring, notification, or safety mechanisms in a fast-moving crypto environment.
The file appears to function more as packaging/deployment/payment metadata than as a trustworthy specification for a live wallet-monitoring system, while still presenting itself as a security-aware monitoring tool. That mismatch is dangerous because it can induce users to rely on nonexistent monitoring, notification, or safety mechanisms in a fast-moving crypto environment.
The script contains hardcoded login credentials and couples them with remote publishing capability, allowing immediate authenticated actions against the external platform. Hardcoded secrets are routinely leaked through source control, logs, archives, or downstream redistribution, enabling account takeover and unauthorized publishing if the code is exposed.
The code reads embedded credentials and transmits them to a remote login endpoint without any runtime warning, consent, or interactive confirmation. This is dangerous because users inspecting or executing auxiliary project scripts may unknowingly disclose valid credentials or trigger authenticated activity, and the plaintext secret exposure itself enables credential theft.
This file implements automated login and remote marketplace upload/deployment behavior that is unrelated to the advertised end-user wallet-monitoring purpose. In skill ecosystems, hidden publisher-side deployment automation increases supply-chain risk because anyone obtaining or running the repository may unintentionally transmit credentials, establish sessions, and publish artifacts to a third-party service.
The code parses ERC-20 transfer calldata and then treats the recipient address from the transfer method as the token contract address, falling back to tx.to only otherwise. For token transfers, the actual token contract is typically tx.to, while the parsed recipient is the transfer target wallet; this confusion corrupts token identification, DEV attribution, and any downstream logging or billing decisions.
The code records detections as 'charged: true' with a billing amount even though the monitoring path never verifies payment or performs a charge. This can create fraudulent or misleading billing records, enabling overbilling disputes, false accounting, and trust abuse in any downstream system that relies on these fields.
The script hardcodes a payment/API credential (api_key) and then includes it in a generated publish URL, which exposes the secret in source control, terminal output, browser history, logs, and any systems that capture URLs. This is unrelated to the wallet-monitoring function of the skill, so the embedded secret materially increases risk without operational necessity.
The file consistently presents the skill documentation in Chinese, including headings, instructions, and usage guidance, without indicating that the user can choose another language. The policy requires flagging language or locale constraints when a specific language is effectively forced without user opt-in.
The guide explicitly tells users to copy login credentials back to the server and also demonstrates token-based authentication without any warning about secure handling, storage, masking, or least-privilege use. In a deployment guide, this can normalize unsafe credential practices and increase the likelihood of token exposure through shell history, logs, screenshots, clipboard leakage, or multi-user server access.
Data is being sent to an external URL. This could be legitimate telemetry or data exfiltration. Manual review is recommended.
zip -r bsc-dev-monitor-skill.zip bsc-dev-monitor-skill/
# 2. 上传到服务器
curl -X POST https://api.clawhub.com/v1/skills \
-H "Authorization: Bearer YOUR_API_TOKEN" \
-F "file=@bsc-dev-monitor-skill.zip" \
-F "name=bsc-dev-monitor" \
This markdown file contains user-facing operational instructions only in Chinese, which can amount to a language/locale policy issue when no opt-in or alternative language is provided. The content does not indicate that the skill is region-specific or that Chinese is a required locale for compliance or audience constraints.
Detected: suspicious.exposed_secret_literal