T09 · Insecure Skill Coding Practices
- Location
scripts/crypto_lens.py:32- Finding
Hardcoded SkillPay API Credential Exposed in Distributed Source Code
- Content
View full analysis
Vulnerability Details
File Location:
scripts/crypto_lens.py:32-34
Vulnerability Type: Hardcoded API credential
Risk Level: HighVulnerable Code
python BILLING_URL = "https://skillpay.me/api/v1/billing" BILLING_API_KEY = "sk_fbda2cd31455722ee28f08aebbf77af5f0002f21d1832f1b2102b756e20f2981" SKILL_ID = "73d7f580-817c-4df2-a0fb-0572f93e4b97"The credential is subsequently transmitted as an authentication header:
python data = _post_json( f"{BILLING_URL}/charge", {"user_id": user_id, "skill_id": SKILL_ID}, headers={"X-API-Key": BILLING_API_KEY}, )Technical Analysis
The Skill embeds a live-looking SkillPay API key directly in a client-side Python file. Any user who downloads, installs, or otherwise obtains the Skill package can extract and reuse this credential independently of the intended program.
Although
SKILL.mdclaims that the key can only initiate charges and cannot withdraw funds, this restriction is enforced externally by SkillPay and cannot be verified from the audited source. A static credential distributed to every client also cannot reliably distinguish legitimate Skill requests from requests made by an attacker.The billing request contains a caller-controlled
user_idand a fixedskill_id. The request does not bind the API credential to a particular installation, invocation, command, or expected price. The actual price is controlled by the remote SkillPay configuration rather than included and validated by the client.Attack Path
- An attacker downloads or reads the Skill package.
- The attacker extracts
BILLING_API_KEY,SKILL_ID, and the billing endpoint fromscripts/crypto_lens.py. - The attacker constructs requests to
https://skillpay.me/api/v1/billing/charge. - The attacker supplies the exposed key in the
X-API-Keyheader and submits chosen billing identifiers in the JSON request body. - If the remote service do ...[truncated 1282 chars]
- Remediation
View remediation
Remediation Suggestions
- Revoke and rotate the exposed API key because it must be treated as compromised once distributed.
- Remove long-lived billing credentials from all client-side source code and package history.
- Route billing through a publisher-controlled server that stores the credential in a secrets manager or protected environment variable.
- Issue short-lived, narrowly scoped invocation tokens instead of distributing a reusable publisher credential.
- Bind each authorized billing operation to the user identity, Skill ID, command, exact amount, expiration time, and a unique nonce.
- Require the client to display and validate the exact charge amount returned by the billing service before performing the paid operation.
- Add replay protection, per-user and per-key rate limits, anomaly detection, and auditable request identifiers.
- Avoid relying on documentation claims about key permissions; enforce least privilege through the billing provider's server-side policy.
- Establish an automated credential-rotation and incident-response process.
