T09 · Insecure Skill Coding Practices
Error
- Location
scripts/scan.sh:49- Finding
Hard-Coded Moltbook Bearer Credential
- Content
View full analysis
/dev/null) ``` ### Technical Analysis The script embeds a Moltbook bearer token directly in source code. Any person or system with access to the Skill package, source repository, build artifact, backup, or execution logs that reproduce the command can recover and reuse this credential. This implementation also contradicts the documented configuration in `SKILL.md`, which states that the `MOLTBOOK_API_KEY` environment variable should provide the credential. Bearer tokens generally grant access based solely on possession, so no additional authentication factor may be required. The credential is transmitted only to the declared Moltbook HTTPS endpoint in the reviewed code. No evidence was found that the script deliberately sends it to an unrelated service. Nevertheless, embedding it in a distributable artifact constitutes direct credential disclosure. ### Attack Path 1. An attacker obtains a copy of the Skill package or reads `scripts/scan.sh`. 2. The attacker extracts the bearer token from line 50. 3. The attacker submits requests to Moltbook with the copied `Authorization: Bearer` header. 4. Moltbook treats those requests as originating from the credential owner until the token is revoked, expires, or is otherwise restricted. ### Impact Assessment An attacker may impersonate the associated Moltbook account or API client within the permissions assigned to the exposed token. Potential impact includes unauthorized access to protected feed data, API quota consumption, account-level request attribution, and abuse of any additional API operations permitted by the token. Th ...[truncated 258 chars]- Remediation
View remediation
&2 exit 1 fi MOLTBOOK=$(curl --fail --silent --show-error \ "https://www.moltbook.com/api/v1/submolts/predictionmarkets/feed?sort=new&limit=5" \ -H "Authorization: Bearer ${MOLTBOOK_API_KEY}") ``` 3. Supply the secret through an approved secret manager or a protected runtime environment rather than committing it to source control. 4. Restrict the replacement token to the minimum read-only API scope required for feed scanning. 5. Review repository history, distributed artifacts, logs, and backups for copies of the exposed credential. 6. Add automated secret scanning to development and release pipelines. 7. Avoid shell tracing such as `set -x` around authenticated requests because it may disclose authorization headers. ]]>