- Location
- SKILL.md:20
- Finding
- Overbroad OAuth Scope and Centralized Remote Tool Delegation## Vulnerability Details
**File Location**: `SKILL.md:20-22`, `SKILL.md:51-55`, and `SKILL.md:104-110`
**Vulnerability Type**: Excessive OAuth scope and broad delegation to a remote tool platform
**Risk Level**: High
### Vulnerable Code
```bash
# 1. Request a device code
curl -s -X POST https://mcpmarket.cn/oauth/device/code \
-d "client_id=skill-agent&scope=mcp:*"
```
```bash
# Step 2: Call the tool
curl -s -X POST https://mcpmarket.cn/api/uno/call-tool \
-H "Authorization: Bearer $(cat ~/.uno/token)" \
-H "Content-Type: application/json" \
-d '{"tool_name":"tonghu-weather.weatherArea","arguments":{"area":"Beijing"}}'
```
```markdown
**Downstream OAuth:** Some services (e.g. GitHub, Notion) require authorization on first call:
```json
{"auth_required": true, "auth_url": "https://...", "state_id": "..."}
```
Open `auth_url`, complete authorization, then **call again directly** — the platform links the token server-side automatically.
```
### Technical Analysis
The Skill requests the wildcard OAuth scope `mcp:*`, rather than requesting permissions limited to the specific tool or operation selected by the user. It then sends a reusable bearer token, tool identifiers, and tool arguments to a centralized remote execution endpoint.
This architecture is consistent with the Skill's advertised remote-tool functionality, so the network communication itself is not unrelated or covert. However, the wildcard authorization exceeds the minimum privilege required for many individual operations, such as querying weather data. The same platform can also hold links to downstream accounts such as GitHub or Notion, expanding the authorization boundary beyond a single MCP operation.
Tool arguments may contain source code, document contents, search terms, locations, account identifiers, or other sensitive user data. The Skill does not instruct the agent to classify arguments, redact secrets, obtain explicit con
...[truncated 1716 chars]
- Remediation
- ## Remediation Suggestions
1. Replace `mcp:*` with narrowly scoped, per-tool or per-capability OAuth permissions.
2. Request additional scopes only when the user selects a tool that requires them, using incremental authorization.
3. Require explicit user confirmation before sending secrets, private documents, source code, personal information, or account identifiers in tool arguments.
4. Add argument classification and redaction guidance, including a prohibition on transmitting credentials, session cookies, private keys, and unrelated environment data.
5. Display the selected tool, destination host, requested permissions, and data to be transmitted before invocation.
6. Maintain an allowlist of trusted tools and require additional approval for tools capable of writes, financial actions, account changes, or external publication.
7. Isolate downstream OAuth grants by service and tool, and provide clear procedures for reviewing and revoking each linked integration.
8. Document platform-side data retention, logging, subprocessors, encryption, and deletion behavior.
9. Use short-lived, audience-restricted tokens and rotate or revoke them after suspected exposure.