T09 · Insecure Skill Coding Practices
- Location
SKILL.md:11- Finding
Hardcoded MCP API Credential Exposed in Skill Documentation
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 11 and 41
Vulnerability Type: Hardcoded API credential in a URL query parameter
Risk Level: HighVulnerable Code
Line 11:
markdown 通过集成 MCP 工具（`https://connect.zhihuiya.com/713886/logic-mcp?apikey=sk-3F0NsY7KOt2ZyO72XkgwUIwD80xSfBjCNKp7juA92d0HWpKu`）访问智慧芽化学分子数据库Line 41:
markdown **MCP 端点**：`https://connect.zhihuiya.com/713886/logic-mcp?apikey=sk-3F0NsY7KOt2ZyO72XkgwUIwD80xSfBjCNKp7juA92d0HWpKu`Technical Analysis
A reusable MCP API credential is embedded directly in the version-controlled Skill documentation. Any party with access to the package, repository, distributed artifact, backups, or source history can recover the credential without additional privileges.
The secret is also supplied through the URL query string. Query parameters commonly appear in HTTP access logs, reverse-proxy logs, observability platforms, error reports, browser history, and other monitoring records. This creates additional disclosure paths beyond direct access to the project files.
The same credential appears twice, increasing the likelihood that partial remediation will leave one exposed copy. Although the audit cannot verify the credential's current validity or exact server-side permissions, it must be treated as compromised.
Attack Path
- An attacker obtains read access to the Skill package, a repository clone, an archived artifact, or exposed repository history.
- The attacker reads
SKILL.mdand extracts the value of theapikeyquery parameter. - The attacker submits requests to the declared MCP endpoint using the exposed key.
- If the credential remains valid, the endpoint attributes those requests to the compromised credential.
- The attacker can continue making requests within the permissions and limits assigned to that key until it is revoked, rotated, or otherwise disabled.
A secondary disclosure route exists if legitimate users invoke the URL as written: in ...[truncated 912 chars]
- Remediation
View remediation
Remediation Suggestions
-
Revoke the exposed API key immediately and issue a replacement; assume the existing key has already been copied.
-
Remove every plaintext occurrence from the current files and repository history. Confirm that both lines 11 and 41, along with prior commits, release archives, caches, and generated artifacts, are sanitized.
-
Store the replacement credential in an approved secret manager or protected runtime environment variable rather than in Skill text or source control.
-
Publish only a credential-free endpoint, for example:
text https://connect.zhihuiya.com/713886/logic-mcp -
Where supported, transmit the credential in an authorization header rather than a query parameter:
http Authorization: Bearer ${ZHIHUIYA_MCP_API_KEY} -
Restrict the replacement key to the minimum required API operations, datasets, environments, and usage limits. Apply network or tenant restrictions where supported.
-
Enable automated secret scanning in pre-commit hooks and CI pipelines to block future credential commits.
-
Review API, proxy, application, and telemetry logs for use of the exposed key. Rotate or purge credentials from logs where feasible and investigate anomalous requests.
-
Add documented credential-expiration and rotation procedures so future exposure has a limited impact window.
-