T09 · Insecure Skill Coding Practices
- Location
scripts/config.json:2- Finding
Hardcoded Meituan API Credentials
- Content
View full analysis
Vulnerability Details
File Location:
scripts/config.json, lines 2–3
Vulnerability Type: Hardcoded API credentials and plaintext sensitive data
Risk Level: HighVulnerable Code
json { "appkey": "4c6b6be3089e4715a080e3edcf60b67c", "secret": "13b92efb33c5455bb5d23e6a53ada8b4", "host": "https://media.meituan.com", "paths": { "referral_link": "/cps_open/common/api/v1/get_referral_link", "query_coupon": "/cps_open/common/api/v1/query_coupon" } }Technical Analysis
The project distributes a Meituan API application key and its corresponding HMAC secret in a plaintext configuration file. The secret is not merely sample data:
scripts/run.jsloads it fromconfig.jsonand passes it tocaSign(), where it is used as the HMAC-SHA256 key for authenticating API requests.Anyone who can download, inspect, copy, or otherwise access the Skill package can recover the credential without needing elevated local privileges. The attacker can reproduce the documented signing process and submit requests that appear to originate from the legitimate application.
Although the
configcommand masks the secret in its output, this does not protect the underlying value because the complete secret remains directly readable fromscripts/config.json.Attack Path
- Obtain a copy of the distributed Skill package or gain read access to its installation directory.
- Open
scripts/config.jsonand extract theappkeyandsecret. - Reproduce the signing algorithm implemented in
scripts/run.js, including:- JSON serialization of the request body.
- Calculation of the Base64-encoded MD5 body digest.
- Construction of the signed headers and canonical string.
- Generation of the Base64-encoded HMAC-SHA256 signature using the exposed secret.
- Send signed HTTPS requests to the configured Meituan coupon-query or referral-link API endpoints.
- Continue making req ...[truncated 909 chars]
- Remediation
View remediation
Remediation Suggestions
- Revoke and rotate the exposed credential immediately. Treat the current secret as compromised because it has been distributed in plaintext.
- Remove all credentials from the Skill package and repository history. Deleting only the current file is insufficient if the value remains in previous commits, archives, releases, build artifacts, or caches.
- Load secrets from a protected runtime source, such as:
- Environment variables supplied by the deployment platform.
- An operating-system credential store.
- A managed secret manager with access-control and audit support.
- Fail securely when credentials are unavailable. Do not fall back to embedded defaults, example production credentials, or publicly readable files.
- Apply least privilege to the replacement credential. Restrict it to only the API operations required for coupon queries and referral-link generation.
- Apply provider-side controls where available, including request quotas, rate limits, source restrictions, expiration, and anomaly monitoring.
- Review API and affiliate logs for suspicious requests made with the exposed application identity and investigate unexpected usage.
- Add automated secret scanning to source-control, packaging, and release pipelines to prevent future credentials from being committed or distributed.
- Document secure deployment requirements in
SKILL.mdwithout including real secret values.
