| 标题 | 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 月前) |
|---|
| 管理 | 2026-07-13 19時23分 (1 month later) |
|---|
| 状态 | 重复 |
|---|
| VulDB条目 | 378127 [nextlevelbuilder GoClaw 3.11.3 exec_approval.go ExecApprovalManager.CheckCommand 权限提升] |
|---|
| 积分 | 0 |
|---|