T09 · Insecure Skill Coding Practices
- Location
payment.py:10- Finding
Hard-Coded Billing API Credential Exposed in Source Code
- Content
View full analysis
Vulnerability Details
File Location:
payment.py, lines 10-17
Vulnerability Type: Hard-coded secret and plaintext credential exposure
Risk Level: HighVulnerable Code
python BILLING_API_URL = "https://skillpay.me" BILLING_API_KEY = "sk_f03aa8f8bbcf79f7aa11c112d904780f22e62add1464e3c41a79600a451eb1d2" SKILL_ID = "befb923c-ea67-4dc4-ae05-386df450a32c" SKILL_NAME = "airdrop-hunter" PRICE_PER_CALL = 0.01 # USDT HEADERS = { "X-API-Key": BILLING_API_KEY, "Content-Type": "application/json" }Technical Analysis
The billing API credential is embedded directly in distributable source code and is automatically placed in the
X-API-Keyheader for billing requests. Anyone who can download, inspect, log, or otherwise access the Skill package can recover and reuse the credential independently of the Skill.This implementation also conflicts with
_meta.json, which declaresSKILLPAY_API_KEYas the intended environment variable for the billing credential. Consequently, rotating or isolating credentials through deployment configuration is ineffective unless the source code is changed.The requests transmit the credential over HTTPS, but transport encryption does not protect a secret already disclosed in source code. The actual extent of exploitation depends on the billing provider's server-side authorization and validation controls.
Attack Path
- An attacker obtains a copy of the Skill package or reads its source repository.
- The attacker extracts
BILLING_API_KEYfrompayment.py. - The attacker constructs requests to the billing endpoints used by the Skill, including:
/api/v1/billing/balance/api/v1/billing/charge/api/v1/billing/payment-link
- The attacker supplies the extracted value through the
X-API-Keyheader. - If the provider does not strictly bind requests to authorized users, Skill IDs, operations, or origins, the attacker can ...[truncated 790 chars]
- Remediation
View remediation
Remediation Suggestions
-
Revoke the exposed credential immediately and issue a replacement.
-
Remove the literal key from source code and load it from the environment as declared in
_meta.json:python BILLING_API_KEY = os.environ.get("SKILLPAY_API_KEY") if not BILLING_API_KEY: raise RuntimeError("SKILLPAY_API_KEY is required") -
Store the replacement in an approved secret manager or protected runtime configuration rather than in source control, package files, examples, logs, or generated artifacts.
-
Review repository and package history for prior exposure. If the key appeared in any published revision, treat it as permanently compromised.
-
Restrict the replacement credential to the minimum required endpoints and actions. Bind it to the expected Skill ID where supported.
-
Enforce server-side authorization for every billing operation; do not rely solely on possession of a shared API key.
-
Add rate limits, anomaly detection, request auditing, and alerts for unusual balance checks, charge attempts, or payment-link generation.
-
Avoid deploying a reusable provider credential to untrusted client environments. Prefer a controlled backend that authenticates the caller and performs narrowly scoped billing operations.
-
Add automated secret scanning to source-control and release pipelines to prevent recurrence.
-
