T09 · Insecure Skill Coding Practices
- Location
scripts/moltbook-client.js:13- Finding
Hard-Coded Reusable Moltbook API Credential
- Content
View full analysis
Vulnerability Details
File Location:
scripts/moltbook-client.js:13
Vulnerability Type: Hard-coded bearer credential
Risk Level: HighVulnerable Code
javascript const MOLTBOOK_API_KEY = "moltbook_sk_oOyURnwFc5RbKKpraIUW9h0BAgM_vNI0";The credential is subsequently attached to every API request:
javascript async function mbReq(method, endpoint, body) { const opts = { method, headers: { Authorization: `Bearer ${MOLTBOOK_API_KEY}`, "Content-Type": "application/json" } }; if (body) opts.body = JSON.stringify(body); const res = await fetch(`${BASE}${endpoint}`, opts); return res.json(); }Technical Analysis
A reusable Moltbook bearer credential is embedded directly in distributed source code. Anyone who can download, inspect, log, or otherwise access the Skill package can recover the credential without needing to defeat authentication controls.
The
mbReqfunction uses this credential for all supported endpoints. The exposed client provides authenticated capabilities to publish posts, comment, upvote, edit posts, complete anti-spam verification, read the feed, access the dashboard, and retrieve agent information. Because bearer authentication proves possession rather than caller identity, copying the token is sufficient to impersonate the associated Moltbook agent.This secret exceeds secure minimum-privilege handling requirements because it is shared with every recipient and execution environment that receives the package. Although authenticated network transmission to the declared Moltbook API is necessary for the Skill’s functionality, embedding the credential itself is unnecessary and unsafe.
Attack Path
- An attacker downloads or otherwise obtains access to the Skill package.
- The attacker inspects
scripts/moltbook-client.js. - The attacker copies the bearer credential declared on line 13.
- The attacker sends independent requests to
https://www.moltbook.com/api/v1with the copied value in th ...[truncated 979 chars]
- Remediation
View remediation
Remediation Suggestions
- Immediately revoke and rotate the exposed credential. Treat it as compromised because it has been distributed in plaintext.
- Remove the credential from source code and repository history. Rewriting only the current file is insufficient if prior revisions or published archives remain accessible.
- Inject the credential at runtime through a dedicated secret manager or a narrowly scoped environment variable that is not committed, packaged, logged, or returned to users.
- Avoid storing credentials in broadly loaded agent memory or
TOOLS.md. Use a credential facility that exposes secrets only to the component and operation requiring them. - Issue a least-privilege token. Restrict the replacement credential to the minimum endpoints and actions required by the declared publish, comment, and upvote workflow. Separate read, edit, and account-information capabilities where the platform supports scoped tokens.
- Restrict the request destination. Preserve a fixed HTTPS origin and validate endpoints before attaching the
Authorizationheader. - Reduce browser-context exposure. Prefer a dedicated authenticated API client over arbitrary browser-page evaluation where possible, as page scripts, extensions, debugging facilities, or logs may expose runtime credentials.
- Add secret scanning and commit-time controls to reject Moltbook keys and similar bearer credentials before packaging or publication.
- Review Moltbook activity logs for unauthorized posts, edits, comments, votes, account reads, and unusual rate-limit usage associated with the exposed key.