Submeter #855807: nextlevelbuilder GoClaw 3.13.3-beta.3 Authorization Bypass (CWE-863)

# Technical Details
An Authorization Bypass exists in the `CheckCommand` method in `internal/tools/exec_approval.go` of GoClaw.

The application fails to align approval decisions with actual execution when `tools.execApproval.security="allowlist"` and `tools.execApproval.ask="on-miss"` are enabled. `POST /v1/tools/invoke` accepts operator requests, the approval manager checks only the first executable token against the allowlist, and `internal/tools/shell.go` later executes the original full shell string. This allows `env sh -c '...'` to run without creating the pending approval that the inner shell command should require.

# Vulnerable Code
File: internal/tools/exec_approval.go
Method: ExecApprovalManager.CheckCommand
Why: The approval side returns `allow` when `matchesAllowlist(command)` sees `env`, but the execution side calls `executeOnHost(ctx, command, cwd)` with the unchanged command string, so the embedded `sh -c` payload still runs.

# Reproduction
1. Configure GoClaw `3.13.3-beta.3` with `tools.execApproval.security="allowlist"`, `tools.execApproval.ask="on-miss"`, and `env` in the allowlist.
2. Submit `POST /v1/tools/invoke` for `exec` using a payload like `env sh -c 'sleep 2; printf vuln > /tmp/canary'`.
3. Observe that no pending approval is created and the canary file is written by the inner shell command.

# Impact
- Authenticated operators can bypass the approval workflow and execute inner shell payloads directly.
- This weakens the operator trust boundary and can lead to unauthorized file creation, modification, and further local abuse.

• Fonte: ⚠️ https://github.com/nextlevelbuilder/goclaw/issues/1203
• Utilizador: Eric-b (UID 96354)
• Submissão: 11/06/2026 09h11 (há 1 mês)
• Moderação: 13/07/2026 19h23 (1 month later)
• Estado: Duplicado
• Entrada VulDB: 378127 [nextlevelbuilder GoClaw 3.11.3 exec_approval.go ExecApprovalManager.CheckCommand Elevação de Privilégios]
• Pontos: 0