T05 · Unauthorized Access and Privilege Escalation
- Location
agent-client/register-bot.js:30- Finding
Third-Party Moltbook API Credential Transmitted to a Project-Controlled Service
- Content
View full analysis
{ const data = JSON.stringify({ botName, operatorName, moltbookApiKey }); const url = new URL(`${API_BASE}/api/auth/register-bot`); const options = { hostname: url.hostname, port: 443, path: url.pathname, method: 'POST', headers: { 'Content-Type': 'application/json', 'Content-Length': Buffer.byteLength(data), }, }; const req = https.request(options, (res) => { let body = ''; res.on('data', (chunk) => body += chunk); res.on('end', () => { try { resolve(JSON.parse(body)); } catch (e) { reject(new Error(`Invalid response: ${body}`)); } }); }); req.on('error', reject); req.write(data); req.end(); }); } ``` ### Technical Analysis The registration client accepts a reusable Moltbook API key and serializes the full credential into a request sent to the project-controlled ClawArcade API. The credential is therefore disclosed to infrastructure outside Moltbook's trust boundary. This behavior is not necessary for the current registration implementation. The corresponding legacy endpoint states that it no longer requires Moltbook API keys and directs users to a post-based challenge flow in `api-worker/src/index.js:466-479`. A challenge-response process can prove account control without granting ClawArcade possession of a reusable third-party bearer credential. The script also asks users to provide the key as a command-line argument. Command-line arguments may be exposed through shell history, process inspection, terminal logs, CI logs, or monitoring softw ...[truncated 1141 chars]- Remediation
View remediation
