T05 · Unauthorized Access and Privilege Escalation
Error
- Location
- SKILL.md:32
- Finding
- Open Direct-Message and Group Policies Bypass Bot Access Controls## Vulnerability Details **File Location**: `SKILL.md`, lines 32-55 **Vulnerability Type**: Access-control bypass caused by insecure default configuration **Risk Level**: High The skill explicitly configures both direct-message and group access policies as `open`: ```json { "channels": { "feishu": { "enabled": true, "defaultAccount": "<first_agent_name>", "dmPolicy": "open", "connectionMode": "websocket", "domain": "feishu", "groupPolicy": "open", "accounts": { "<agent1>": { "appId": "<app_id_1>", "appSecret": "<app_secret_1>" }, "<agent2>": { "appId": "<app_id_2>", "appSecret": "<app_secret_2>" } } } } } ``` ### Technical Analysis Setting `dmPolicy` to `open` deliberately disables pairing or equivalent admission controls for direct conversations. Setting `groupPolicy` to `open` similarly allows the bot to operate in groups without an explicit group allowlist. These settings remove the trust boundary that should restrict who can submit instructions to an OpenClaw agent. Any Feishu user able to discover, add, message, or place the bot in a group may be able to interact with the associated agent. Because the configuration is applied through `gateway config.patch`, the exposure persists in the gateway configuration and affects every configured account using these policies. The package does not define compensating controls such as user allowlists, group allowlists, role validation, per-account authorization, command restrictions, or confirmation requirements for sensitive operations. The actual consequences depend on the tools and permissions available to each OpenClaw agent, but the configuration exposes those capabilities to untrusted chat participants. ### Attack Path 1. An operator follows the skill and applies the g ...[truncated 1402 chars]
- Remediation
- ## Remediation Suggestions 1. Replace `dmPolicy: "open"` with a pairing, approval, or explicit user-allowlist policy. 2. Replace `groupPolicy: "open"` with an explicit group allowlist or disable group interaction unless it is required. 3. Require the operator to supply approved Feishu user and group identifiers before applying the configuration. 4. Configure authorization independently for each bot account rather than relying on a single channel-wide open policy. 5. Apply least privilege to each underlying agent and disable sensitive tools for publicly reachable messaging agents. 6. Require explicit confirmation or secondary authorization before executing high-impact operations. 7. Add rate limiting, audit logging, abuse monitoring, and alerts for unknown users, unexpected groups, and repeated failed authorization attempts. 8. Validate the proposed patch and display a prominent warning before applying any configuration that enables unrestricted access. 9. After deployment, test both authorized and unauthorized accounts to confirm that unapproved users and groups are rejected.