जमा करें #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.

• स्रोत: ⚠️ https://github.com/nextlevelbuilder/goclaw/issues/1203
• उपयोगकर्ता: Eric-b (UID 96354)
• सबमिशन: 11/06/2026 09:11 AM (1 महीना पहले)
• संयम: 13/07/2026 07:23 PM (1 month later)
• स्थिति: प्रतिलिपि
• VulDB प्रविष्टि: 378127 [nextlevelbuilder GoClaw 3.11.3 exec_approval.go ExecApprovalManager.CheckCommand अधिकार वृद्धि]
• अंक: 0