T05 · Unauthorized Access and Privilege Escalation
- Location
- scripts/zero-token-dashboard.sh:9
- Finding
- System Monitoring Data Is Sent to Hard-Coded Discord Destinations<![CDATA[ ## Vulnerability Details **File Location**: `scripts/zero-token-dashboard.sh:9-20` **Additional Locations**: `scripts/zero-token-dashboard-v2.sh:10-13,32-47`; `scripts/discord-post.js:8-13`; `scripts/discord-integration.js:214-223` **Vulnerability Type**: Hard-coded external recipient and insufficient destination authorization **Risk Level**: High ### Vulnerable Code ```bash # Configuration DASHBOARD_DIR="$HOME/.openclaw/workspace/skills/live-monitoring-dashboard" ACTIVITY_MSG_ID="1479037476805804182" HEALTH_MSG_ID="1479040445819392000" CHANNEL_ID="1479037438813802618" # Discord API function update_discord_message() { openclaw message edit \ --channel discord \ --message-id "$1" \ --target "channel:$CHANNEL_ID" \ --message "$2" >/dev/null || true } ``` The generated Discord integration also contains a fixed user recipient: ```javascript if (!process.env.LIVE_MESSAGE_ID) { const result = message({ action: 'send', target: 'user:311529658695024640', message: dashboardMessage }); } ``` ### Technical Analysis The dashboard collects information about OpenClaw processes, cron jobs, host resource utilization, and uptime. Instead of requiring the installer to provide and verify a destination, multiple scripts ship with fixed Discord user, channel, and message identifiers. Consequently, executing the default scripts can edit messages in a preselected Discord channel or send monitoring data to a preselected user. The scripts do not verify that the identifiers belong to the installer, that the installer approved the recipient, or that the destination is part of the current OpenClaw deployment. The repeated use of the same identifiers in scripts and state files makes this an operational default rather than an isolated documentation example. ### Attack Path 1. A user installs the Skill and retains the shipped configuration. 2. The dashboard runs manually or through a scheduled task. 3. ...[truncated 1018 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Remove all embedded Discord user, channel, and message identifiers from scripts, generated files, state files, and documentation examples. 2. Require the administrator to provide destination identifiers through a dedicated configuration step. 3. Fail closed when any required identifier is unset; do not silently fall back to a project-author destination. 4. During setup, resolve and display the selected Discord server, channel, and message and require explicit confirmation. 5. Validate that the authenticated Discord principal can access the destination and that the destination belongs to an administrator-approved server. 6. Maintain an allowlist of authorized channel IDs and reject all other destinations. 7. Separate local monitoring from publication so data collection does not automatically imply external transmission. 8. Avoid suppressing delivery failures with `|| true`; log failures without exposing credentials and make misconfiguration visible. 9. Rotate or remove any affected Discord resources if the shipped identifiers correspond to active destinations. ]]>
