| タイトル | 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) |
|---|
| 送信 | 2026年06月11日 09:11 (1 月 ago) |
|---|
| モデレーション | 2026年07月13日 19:23 (1 month later) |
|---|
| ステータス | 重複 |
|---|
| VulDBエントリ | 378127 [nextlevelbuilder GoClaw 3.11.3 exec_approval.go ExecApprovalManager.CheckCommand 特権昇格] |
|---|
| ポイント | 0 |
|---|