T09 · Insecure Skill Coding Practices
- Location
SKILL.md:37- Finding
Long-Lived ClickUp OAuth Token Exposed and Stored in Plaintext
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 37-60
Vulnerability Type: Plaintext credential extraction and storage
Risk Level: MediumVulnerable Code
markdown **Step 2: Extract token** ```bash jq -r '.mcpOAuth | to_entries | .[] | select(.key | startswith("clickup")) | .value.accessToken' ~/.claude/.credentials.jsonStep 3: Add to environment
bash # Add to ~/.clawdbot/.env CLICKUP_TOKEN=eyJhbGciOiJkaXIi...Step 4: Configure mcporter
Add to
config/mcporter.json:json { "mcpServers": { "clickup": { "baseUrl": "https://mcp.clickup.com/mcp", "description": "Official ClickUp MCP", "headers": { "Authorization": "Bearer ${CLICKUP_TOKEN}" } } } }text ### Technical Analysis The setup procedure reads an OAuth access token directly from Claude's credential store and emits it as plaintext to standard output. It then instructs the user to copy the token into `~/.clawdbot/.env`, without requiring restrictive file permissions, output suppression, a dedicated secret manager, or token rotation. The same document states that these tokens are long-lived, approximately ten years. Consequently, accidental disclosure can provide durable access. Potential exposure sources include terminal logs, command-output capture, screen sharing, clipboard history, unencrypted backups, diagnostic bundles, and local processes or users able to read the environment file. Reading the ClickUp-specific entry is relevant to the declared integration and does not itself demonstrate access to unrelated credentials. The configured bearer token is also transmitted only to the declared official ClickUp MCP endpoint. Nevertheless, extracting an existing credential from another application's credential store and duplicating it into a plaintext file exceeds secure minimum-practice requirements. ### Attack Path 1. A user follows t ...[truncated 1657 chars]- Remediation
View remediation
Remediation Suggestions
- Prefer direct OAuth integration with secure token lifecycle management instead of extracting credentials from
~/.claude/.credentials.json. - Store access and refresh tokens in an operating-system keychain, encrypted credential store, or dedicated secret manager rather than a plaintext
.envfile. - If an environment file is unavoidable, create it with owner-only permissions, such as mode
0600, and verify that its parent directory is not accessible to other users. - Avoid printing the token to standard output. Use a mechanism that transfers the value directly into protected storage without exposing it in terminal logs or clipboard history.
- Ensure credential files are excluded from source control, backups, support bundles, telemetry, and diagnostic output.
- Document explicit token revocation and rotation procedures. Users should revoke the Claude-derived token after suspected exposure.
- Prefer short-lived and narrowly scoped credentials where ClickUp supports them, and authorize only the minimum workspace permissions required.
- Warn users not to paste real tokens into command history, chat messages, issue reports, screenshots, or configuration committed to a repository.
- Prefer direct OAuth integration with secure token lifecycle management instead of extracting credentials from
