T09 · Insecure Skill Coding Practices
- Location
auto-deploy.js:13- Finding
Plaintext ClawHub Account Credentials Embedded in Deployment Script
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill has a coherent wallet-monitoring purpose, but it ships live-looking payment and platform login secrets plus unsafe billing and deployment controls.
Do not install or run this package as-is. The publisher should revoke and rotate all exposed credentials, remove deployment account secrets from the distributed artifact, move payment operations behind a trusted server-side flow, require real payment verification, add user/tenant authorization for monitor operations, validate webhook destinations, and correct or remove unsupported safety-check claims.
auto-deploy.js:13Plaintext ClawHub Account Credentials Embedded in Deployment Script
index.js:16Hardcoded SkillPay API Key Exposed in Source, Documentation, and Payment URLs
index.js:457Payment Enforcement Can Be Bypassed with a Caller-Controlled Flag
index.js:409Monitor Operations and Detection History Lack Ownership Authorization
deploy.sh:29Deployment Script Installs an Unpinned Third-Party CLI Globally
The code embeds a plaintext email and password for platform access directly in source. Hardcoded credentials are trivially recoverable by anyone with file access, enabling account takeover, unauthorized uploads, and reuse attacks if the password is shared elsewhere.
The delivery report exposes a live-looking SkillPay API key directly in documentation, which is sensitive credential material and not necessary to publish in a public-facing report. If valid, anyone who obtains the file could abuse the payment integration, create fraudulent charges, inspect billing activity, or otherwise impersonate the skill's payment backend.
This is a direct credential exposure in markdown without any warning or handling guidance, making accidental leakage and reuse more likely. In the context of a monetized skill, exposed payment API credentials can enable unauthorized billing actions or compromise the integrity of the service's payment flow.
The guide exposes a live-looking email address and plaintext password directly in documentation, encouraging anyone with file access to reuse or misuse those credentials. Hardcoded credentials in deployment docs create immediate account-compromise risk and also normalize unsafe secret-handling practices for operators.
The document contains plaintext third-party login credentials and instructs the operator to use them to access an external site. Exposing credentials in deployment documentation creates immediate risk of unauthorized account access, account takeover, and downstream abuse unrelated to the skill’s stated monitoring functionality.
The markdown explicitly directs the operator to log in with included credentials, normalizing insecure credential sharing and handling. This increases the chance of credential leakage, unauthorized reuse, and compromise of the third-party service account.
The deployment instructions plainly expose account credentials for manual operational use, which is a direct secret disclosure. In the context of a distributable skill package, this is especially dangerous because anyone with access to the file can misuse the account or test the credentials elsewhere.
The skill extends beyond plain monitoring by integrating with an external payment service, yet the trust, privacy, and feature boundaries are not clearly declared. Combined with claimed but unverified security checks, this can cause users to overtrust the skill while their usage and payment data flows to third parties.
The skill extends beyond plain monitoring by integrating with an external payment service, yet the trust, privacy, and feature boundaries are not clearly declared. Combined with claimed but unverified security checks, this can cause users to overtrust the skill while their usage and payment data flows to third parties.
The skill extends beyond plain monitoring by integrating with an external payment service, yet the trust, privacy, and feature boundaries are not clearly declared. Combined with claimed but unverified security checks, this can cause users to overtrust the skill while their usage and payment data flows to third parties.
The skill extends beyond plain monitoring by integrating with an external payment service, yet the trust, privacy, and feature boundaries are not clearly declared. Combined with claimed but unverified security checks, this can cause users to overtrust the skill while their usage and payment data flows to third parties.
The skill extends beyond plain monitoring by integrating with an external payment service, yet the trust, privacy, and feature boundaries are not clearly declared. Combined with claimed but unverified security checks, this can cause users to overtrust the skill while their usage and payment data flows to third parties.
The skill extends beyond plain monitoring by integrating with an external payment service, yet the trust, privacy, and feature boundaries are not clearly declared. Combined with claimed but unverified security checks, this can cause users to overtrust the skill while their usage and payment data flows to third parties.
The skill extends beyond plain monitoring by integrating with an external payment service, yet the trust, privacy, and feature boundaries are not clearly declared. Combined with claimed but unverified security checks, this can cause users to overtrust the skill while their usage and payment data flows to third parties.
A live payment API key is embedded directly in the manifest, making it exposed to anyone who can read or redistribute the skill package. Exposed payment credentials can enable unauthorized charges, account abuse, impersonation of the skill, and compromise of associated billing data or funds.
The script automatically transmits embedded credentials to a remote login endpoint without any warning, prompt, or consent from the operator. This creates a high risk of unintended credential use and silent account access whenever the script is run.
The file is a deployment/publishing script that logs into a third-party platform and uploads a ZIP, which is unrelated to the advertised wallet-monitoring functionality. This mismatch is dangerous because users reviewing or executing the skill may unknowingly run code that performs account actions and publishes artifacts to a remote service.
The script contains remote login and skill-publication capabilities that are not necessary for monitoring BSC wallet transfers. Unrelated privileged functionality increases attack surface and can be abused to exfiltrate local artifacts or perform unauthorized actions against the platform account.
On login failure, the script prints the full email and password to the console as part of manual deployment instructions. Console output is often captured in terminal history, logs, CI systems, or screenshots, causing immediate credential disclosure.
The file embeds a complete third-party billing workflow, including a hardcoded API key and automatic charge logic, even though the declared skill purpose is BSC wallet monitoring. This mismatch is a strong indicator of hidden monetization behavior or unauthorized charging capability unrelated to the advertised function, making the skill materially more dangerous in context.
The charge operation directly attempts to bill the user as part of normal request handling, with no confirmation step, no visible authorization flow, and no user-facing warning. In the context of a wallet-monitoring skill, this increases the risk of unauthorized or deceptive charges and erodes any expectation of informed consent.
The manifest explicitly says the skill supports webhook notifications, and monitors accept a webhook_url field. However, during detection the code only logs results and appends them to in-memory history; it never sends an HTTP request to the configured webhook URL.
These lines send credential-bearing requests with a bearer secret to an external payment API without meaningful user disclosure or isolation. If the skill code is shared or reused, the secret can be abused to query or manipulate payment-related operations, and users may be unaware their identifiers and payment metadata are being transmitted externally.
The skill exfiltrates monitoring events to arbitrary user-supplied webhook endpoints without explicit warning, validation, or destination restrictions. This can leak wallet-monitoring activity and billing metadata to attacker-controlled servers, and can also be abused as an SSRF-like outbound request primitive to unexpected hosts.
The document introduces a billing and charging subsystem, including payment provider configuration and an API key, which materially expands the skill from passive wallet monitoring into monetized payment handling. This is dangerous because it creates undisclosed financial side effects and exposes a live-looking secret in documentation, increasing the risk of unauthorized charges or abuse if reused elsewhere.
Detected: suspicious.exposed_secret_literal