T09 · Insecure Skill Coding Practices
- Location
websearch.py:11- Finding
Hard-Coded API Signing Secret
- Content
View full analysis
Vulnerability Details
File Location:
websearch.py, lines 11–12 and 37–38
Vulnerability Type: Hard-coded cryptographic credential
Risk Level: HighVulnerable Code
python APP_ID = "100003" APP_KEY = "38d2391985e2369a5fb8227d8e6cd5e5"python timestamp = str(int(time.time())) sign_data = f"{APP_ID}&{timestamp}&{APP_KEY}" sign = hashlib.md5(sign_data.encode("utf-8")).hexdigest()The same signing credential and algorithm are also disclosed in
SKILL.md, lines 40–43:text - `X-Auth-Appid`: `100003` - `X-Auth-TimeStamp`: Current Unix timestamp in seconds - `X-Auth-Sign`: MD5(`100003 + "&" + timestamp + "&" + 38d2391985e2369a5fb8227d8e6cd5e5`)Technical Analysis
The application signing key is embedded directly in distributable source code and documentation. Anyone who can access the Skill package can recover the credential and reproduce the request-signing procedure without authorization.
Because the signature is calculated solely from the public application identifier, an attacker-controlled timestamp, and the exposed static key, possession of the source is sufficient to generate signatures for independently constructed API requests. MD5 is also a deprecated cryptographic primitive and does not provide the security expected of modern request authentication. However, the immediate defect is secret exposure: replacing MD5 alone would not provide protection while the shared key remains public.
The local bearer-token retrieval and subsequent network request are consistent with the documented web-search function. The token is read from
http://127.0.0.1:53699/get_tokenand sent only to the declared HTTPS AutoGLM endpoint in the reviewed implementation. No transmission to an unrelated destination was identified.Attack Path
- Obtain a copy of the Skill package or read its published documentation.
- Extract
APP_IDandAPP_KEYfromwebsearch.pyor ...[truncated 1092 chars]
- Remediation
View remediation
Remediation Suggestions
- Revoke and rotate the exposed signing key immediately. Assume it is compromised because it appears in both source code and documentation.
- Remove the key from the Skill package, examples, documentation, version history, build artifacts, and published distributions.
- Move request signing to a protected server-side service so clients never receive the long-lived signing key.
- If client-side credentials are unavoidable, provision short-lived, narrowly scoped credentials at runtime through an authenticated mechanism and store them using an operating-system secret manager.
- Enforce server-side restrictions such as minimal scopes, short expiration periods, rate limits, quota limits, audience validation, timestamp freshness checks, and replay prevention.
- Migrate from plain MD5 construction to HMAC-SHA-256 with a protected secret or, preferably, asymmetric request signing. This requires a coordinated API protocol change.
- Add secret-scanning checks to source-control and release pipelines to prevent credentials from being committed or packaged again.
- Review API logs for unexpected requests associated with application ID
100003, including unusual volume, origins, timestamps, and query patterns.